fix(tasks): expose artifact downloads in task conversations

[tatoalo]

Problem

Cloud-task agents can upload durable output artifacts, but task conversations do not expose them. Users can be told that files exist without any way to find or download them.

Why: Generated reports, images, and other non-code deliverables need to remain accessible after the temporary task sandbox is released.

artifacts_good.mp4

[trunk-io]

😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 078738e.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/sessions/components/CloudArtifactDownloads.tsx:75-84
**Async download loses user activation**

When the preview and presigning requests outlive the click's transient user activation in the web host, `window.open` is treated as an unsolicited popup and blocked, causing the button to finish without opening the artifact or reporting an error.

_{Reviews (1): Last reviewed commit: "fix(tasks): fetch cloud artifact manifes..." | Re-trigger Greptile}

[stamphog]

Note

🤖 stamphog reviewed 078738ee95386966656bbfef66a8719436319505 — verdict: REFUSED

Greptile flagged a substantive, unresolved P1 issue: the download button awaits a network round-trip before calling window.open, so browsers can treat it as an unsolicited popup and block it, silently failing the core feature the PR adds. This is unaddressed on the current head.

• Author wrote 43% of the modified lines and has 28 merged PRs in these paths (familiarity MODERATE).
• greptile-apps[bot] reviewed the current head.
• Unresolved inline review comment from @greptile-apps on CloudArtifactDownloads.tsx (lines 75-84): async presign/preview fetch before window.open() can lose transient user activation and get blocked as a popup, causing the download to silently no-op with no error shown to the user.
• No later commit or reply addresses this concern; it remains open on the current head.

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	186L, 6F substantive, 274L/7F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1c-medium (274L, 7F, single-area, fix)
stamphog 2.0.0b3		.stamphog/policy.yml @ f4fb079 · reviewed head 078738e

[greptile-apps]

The issue is real and straightforward to fix. window.open must be called synchronously during the click handler while user activation is still alive — not after an await.

The standard fix is to open the window immediately (synchronously), then navigate it to the URL once the fetch resolves. If the fetch fails, close the window.

Here's the corrected downloadArtifact:

  const downloadArtifact = useCallback(
    async (artifact: TaskRunArtifact): Promise<void> => {
      if (!taskId || !runId || !artifact.id) return;
      setDownloadingId(artifact.id);
      // Open the window synchronously while user activation is still valid.
      // Navigating it after an await keeps the same security properties as
      // window.open(url, '_blank') but avoids popup-blocker heuristics that
      // fire when open() is called from within an async continuation.
      const win = window.open("", "_blank", "noopener,noreferrer");
      try {
        const url = await sessionService.getCloudAttachmentPreviewUrl(
          taskId,
          runId,
          artifact.id,
        );
        if (!url) {
          win?.close();
          toast.error("This file is no longer available");
          return;
        }
        if (win) {
          win.location.href = url;
        } else {
          // Fallback: activation window already closed (e.g. user closed it).
          window.open(url, "_blank", "noopener,noreferrer");
        }
      } catch {
        win?.close();
        toast.error("Couldn't download file");
      } finally {
        setDownloadingId(null);
      }
    },
    [runId, sessionService, taskId],
  );

The key change: window.open("", "_blank") fires synchronously inside the click, keeping user activation intact. The fetched URL is then assigned to win.location.href. On error the blank tab is closed so users aren't left with a dangling empty tab.