fix(desktop-gpui): request the Instant link while the capture is built on macOS

[richiemcilroy]

With the default countdown of 0, the app builds the recording while the ~0.52 s start chime plays, and the start gate releases capture when the chime ends. For Instant, start_internal first awaited prepare_instant_upload (the server round trip that creates the shareable link) and only then built the capture. Whenever that round trip plus the build outlasted the chime, capture started late and the first words after the chime were lost. Link creation in a real app log took 0.15, 0.3, 0.5-0.6 and 1.29 s.

sequenceDiagram
  participant UI as Start
  participant S as Server
  participant C as Capture build
  Note over UI,C: before (macOS Instant)
  UI->>S: create link
  S-->>UI: link (0.15-1.3 s)
  UI->>C: build capture
  C-->>UI: ready (chime may already be over)
  Note over UI,C: after
  par
    UI->>S: create link
  and
    UI->>C: build capture
  end
  C-->>UI: ready inside the chime
  S-->>UI: link, awaited before upload setup

Loading

• apps/desktop-gpui/src/recording.rs: PendingInstantVideo spawns prepare_instant_upload before the capture build. start_attempt_with_upload awaits it after instant_recording::Actor::build and before the upload setup that needs the video id.
• If link creation fails, discard_unpublished_instant_capture cancels the built capture and deletes its project folder, and the same error is returned. If the capture fails, the created link is still deleted as before.
• Windows and Linux keep the old order (the request is awaited before the build).
• Stop pressed after the chime while the link is still pending now cancels the start: the session signals the start task (StartConfig::start_cancel), the capture is discarded at once, and the link is deleted when it arrives. The phase stays "Starting" until that cleanup is done, so quitting still waits for it. Before, Stop was ignored in this window and the recording went live once the link arrived.

Measurements

Isolated app builds, real mic, local mock server with a 0.8 s link delay, 3 runs each, M4 Max:

	main	This PR
First video frame after the chime	361-382 ms	23-32 ms
Audio start after the chime	295-306 ms	0 ms (at the chime)
Press to "recording" shown	893-911 ms	839-845 ms

• With a fast server (0.05 s) both behave the same.
• Stop 1 s after the press with a 3 s link delay (2 runs): the previous head ignored Stop and went live at 3 s; now capture stops within 1 ms of Stop, the link is deleted 3-4 ms after it is created, and the recordings folder is left empty.
• When the server returns 500, the error text is the same and the recordings folder is left empty on both. With this PR, screen capture starts and is cancelled before the error shows, so the screen-recording indicator flashes briefly and the error appears ~50-60 ms later.

Confidence Score: 5/5

The PR appears safe to merge; both previously reported cleanup problems are addressed.

Summary

The PR requests the Instant link while macOS builds capture. The latest change keeps the session busy until a cancelled start finishes cleanup.

• Instant capture builds while its shareable link is being created.
• Stop cancels a macOS Instant start while its link is pending.

_{Reviews (3) · Last reviewed commit: "fix(desktop-gpui): keep a cancelled Inst..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cap-status	Ready	Preview	Oct 20, 2026 12:39pm UTC

[capy-ai]

Capy found 1 potential issue (1 high).

View 1 other finding in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 3 other findings in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.

[richiemcilroy]

@greptileai review

[capy-ai]

Capy found no issues.