[Gigioxx]

After sending the first prompt of a draft in New worktree mode, Cmd+Shift+N did nothing until the server had created the thread. With a slow git fetch of the base branch that is several seconds of waiting before you can start the next thread.

Cause: the draft clears its composer on send, but was only marked promoting once the server thread showed up. Until then useNewThreadHandler saw an empty, unpromoted draft that was already open, reused it, and returned without navigating. Background sends (Mod+Enter) already marked the draft promoting at send time, so they were not affected.

Fix

• ChatView marks every local draft promoting when its send starts, not only background sends. New-thread flows then mint a fresh draft, and the store keeps the in-flight draft instead of garbage-collecting it.
• A successful send finalizes the draft once the user has left its route, as background sends already did. Otherwise ThreadRouteView finalizes it after the route swap.
• A failed send restores the draft the same way background sends already do (restoreFailedBackgroundDraftThread renamed to restoreFailedDraftThread). Foreground sends still rotate a deleted thread's id in their existing block.
• ThreadRouteView follows a draft's thread only once the client knows it exists. promotedTo is always the draft's own thread ref, so this changes nothing after creation, but avoids fetching a thread detail that 404s about once a second until the server creates it.

This is a small fix for an obvious bug in an existing shortcut, so it has no prior issue.

Verification

Reproduced in an isolated Playwright browser against vp run dev with worktree-local .t3 state. Repo with origin, workspace New worktree, From origin/main. To make setup slow, I used a 25 s remote.origin.uploadpack sleep for the fetch and a 25 s post-checkout hook for the checkout. Steps: Cmd+Shift+N, type a prompt, Enter, then Cmd+Shift+N again during "Setting up worktree…".

• Before: the URL stayed on the same /draft/<id> and the setup card stayed on screen.
• After: Cmd+Shift+N opens a new draft right away. The sent thread finishes setup and appears in the sidebar as Working. No console errors or 404s.

Recordings of the full sequence (a black pill shows each key press, "Enter: send" then "Cmd+Shift+N"):

Before: the first prompt starts worktree setup, then Cmd+Shift+N is pressed twice while "Fetch base branch" runs. Nothing changes; the draft and its setup card stay on screen.

After: same sequence. Cmd+Shift+N opens a new draft while the first thread is still fetching, and the next prompt can be typed right away.

MP4 versions: before, after

Stills:

Before: Cmd+Shift+N ignored during setup	After: sending	After: Cmd+Shift+N opens a new draft	After: sent thread keeps running

Checks:

• vp test run src/composerDraftStore.test.ts src/hooks/useHandleNewThread.test.ts src/components/ChatView.logic.test.ts (297 passed)
• apps/web typecheck
• targeted vp lint (only pre-existing warnings at untouched lines)
• vp fmt --check
• Codex review of the diff (no findings)

Not checked: mobile (separate composer and send path, unchanged) and the desktop shell (wraps the same web code). I added no new unit test. The change is wiring inside ChatView's send path, and a test there would only restate the edit.

Made by Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 4ee7dec

Macroscope's review found this PR approvable — This is a localized web bug fix that adjusts draft promotion, routing, and failure recovery while worktree setup is pending, without changing schemas, defaults, infrastructure, or sensitive code. An unresolved Medium-severity finding does identify possible stale promoted-draft metadata after successful foreground sends.

Notes:

• This verdict was updated automatically after the outstanding correctness findings were resolved. Macroscope did not re-review the code.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Note

This comment is posted by Julius' dot

The screenshots show setup and new-draft states, but not Cmd+Shift+N taking effect before setup finishes. The verification rule requires a short recording for this timing-dependent interaction. Closing for that missing evidence. Please attach before/after recordings of the sequence and request reconsideration.

[Gigioxx]

[claude-opus-5-5] Responding on behalf of Guille

Added the before/after recordings of the timing-dependent sequence to the description. They show the key presses on screen while worktree setup is still fetching the base branch.

• Before: Cmd+Shift+N, pressed twice during setup, leaves the same draft open.
• After: it opens a new draft immediately.

Requesting reconsideration. The branch also has 0e00b92, which addresses Macroscope's finding (finalize the sent draft once the user has left it). That commit landed after the close, so the PR head still shows 4ee7dec until it is reopened. I can't reopen it from my side.

[Gigioxx]

[claude-opus-5-5] Responding on behalf of Guille

Superseded by #14538. It has the same fix plus the Macroscope follow-up, with before/after recordings of the sequence in the description.