Move a thread's branch and uncommitted changes into another existing worktree

[LAlex14]

Problem

I keep several worktrees of one repo. Only one of them has Docker wired up (the main checkout, or a dedicated worktree). I build a feature in a thread on worktree B, which has no Docker. When it's done I want to test it in worktree A, which does, and keep the same thread so the agent still has the full context.

Today the thread can follow a branch: if I pick a branch in the branch picker that's checked out in another worktree, the thread moves there (resolveBranchSelectionTarget in apps/web/src/components/BranchToolbar.logic.ts:266). That only moves the thread, not the code. Git won't check out the same branch in two worktrees. So the branch, its unpushed commits and the uncommitted edits all stay in B.

What I do by hand now:

# worktree B
git stash push -u && git switch --detach
# worktree A
git switch feature/x && git stash pop

Then I pick feature/x in the thread's branch picker so the thread moves to A. It works, but it's 4 manual steps and easy to get wrong (a dirty A, a stash pop conflict, forgetting to detach B).

Proposal

A "Move to worktree…" action on an existing thread. It lists the project's other worktrees. On confirm:

1. Refuse if a turn is running.
2. If the target worktree has uncommitted changes, stop before touching anything. Show a clear message that names the target and lists the changed files, so I can commit or stash them there and retry. Never mix its changes with the ones being moved.
3. In the source worktree, snapshot uncommitted and untracked changes, then detach so the branch is free.
4. If the target is on another branch, switch it to the thread's branch automatically. No extra step for me. Remember the branch it was on, so it can be shown in the result and switched back later.
5. Restore the snapshot in the target as uncommitted changes.
6. Point the thread at the target worktree. The conversation stays the same.
7. If any step fails, undo the earlier ones so both worktrees end up as they were.

The agent could get the same thing as an MCP tool, next to t3_worktree_handoff. That one only creates new worktrees today.

Why not covered already

• feat(web): start a thread in an existing worktree #3798 and feat(web): reuse existing worktrees #8517 (closed) were about picking an existing worktree. The branch picker already does that, but it moves only the thread, not the work.
• feat(server): package and apply a thread's git work #16734 / feat(server): hand a thread off to a linked environment #16751 (open) package a thread's git work, but they move it between linked environments and always into a new worktree. The pack/apply part looks reusable for a local, existing-worktree target.
• Related risk: [Bug]: Runtime-mode, instance and worktree changes detach the Claude session and kill live subagents without the background-work check #16000. Changing a thread's worktree detaches the Claude session and kills background agents without a check. This action should use the same background-work guard.

Open questions

• Should the source worktree be left detached, or switched back to its previous branch or the default branch?
• On a stash conflict in the target, roll everything back, or leave the conflict for the user to resolve?

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up! This is the same proposal as #16570 (move a worktree thread and its branch, commits, and uncommitted changes into another checkout, re-point the thread, roll back on failure), so I'm closing this one as a duplicate to keep the discussion in one place.

Your version generalizes the target from "the project checkout" to "any existing worktree", and your open questions (what to leave the source on, rollback vs. conflict on apply, reusing the background-work guard from #16000) are good additions. Please add them as a comment on #16570 so they're considered together.