Repository navigation
fix(web): prepared worktrees attach to the project's mapped draft, not the invoking draft #6
Description
Activity
Triage
Verdict: Confirmed on current main (
5cebd3b8). Shared draft-opener behaviour matches the reported bug.What I checked
- In
apps/web/src/components/ChatView.tsx,openOrReuseProjectDraftThreadfirst callsgetDraftSessionByLogicalProjectKey(logicalProjectKey)and, if present, navigates to/setDraftThreadContexton that stored draft — not necessarily the draft the user started from. Only when no stored mapping exists does it fall through to the active draft session. handlePreparedPullRequestThreadalways routes through this helper, so Checkout pull request and Start-from-issue (feat: start agent work from a GitHub issue #1/feat(web): Start from issue dialog with prefilled composer #3) share the behaviour (as the issue states; Codex review on feat(web): Start from issue dialog with prefilled composer #5).- Related: feat: start agent work from a GitHub issue #1/feat(web): Start from issue dialog with prefilled composer #3/feat(web): Start from issue dialog with prefilled composer #5 (callers), fix(server): generated worktree paths collide for repositories with the same folder name #7/fix(server): setup scripts run at the worktree root for subdirectory projects #8 (other shared worktree issues). Not the same defect.
Not a duplicate of #3 (feature) or #7/#8 (server path/cwd).
Likely code:
openOrReuseProjectDraftThread+ logical-project draft mapping inChatView.tsx/ draft session stores.Fix direction: Prefer attaching prepared worktree context to the invoking draft thread ID (or explicitly create a new draft), and ensure setup-script RPC thread ID matches the draft that receives the prompt. Add a multi-retained-draft regression test.
Workaround: Keep only one retained draft per project, or start the action from the already-mapped draft.
Outcome:
ready-for-agent— clear repro shape and fix locus onmain.
Generated by Claude Code
- In
Problem
openOrReuseProjectDraftThreadinapps/web/src/components/ChatView.tsxalways reuses the draft currently mapped to the project, not the draft the user started from.When a project has more than one retained draft (for example after New thread while an older draft still has text), starting from an older draft navigates to and rewrites the other draft's worktree context and prompt.
The setup-script RPC is given the invoking draft's thread ID, so the setup script and the navigated draft can disagree.
This affects both Checkout pull request and Start work from issue; both call the same opener.
Expected
The prepared worktree attaches to the draft that started the action, or the action explicitly creates a new draft, and the setup script runs for that same thread.
Source
Raised by Codex review on #5 (comment 4182817116). Not fixed there because the behaviour is shared with the existing PR checkout flow.