claude desktop: add "fork into worktree" option to "fork from here"

Open 💬 0 comments Opened Jul 9, 2026 by Kizuno18

re-filing fresh since #49954 got stale-closed by the bot (which literally says "open a new issue if this is still relevant") — still very much relevant

what

in claude desktop code mode, "fork from here" branches the conversation but reuses the same working directory as the parent chat — meanwhile a brand-new chat already offers "open in worktree" that spins the session up in its own git worktree

so the worktree primitive already ships, it's just not wired into "fork from here"

please add a "fork into worktree" option to the fork action

the problem

forking from a turn is great for trying an alternate approach without losing the original thread — but since the fork shares the parent's working dir, any file edits the fork makes instantly collide with the parent (or a sibling fork)

today that forces a bad choice:

  • fork the convo, then manually git worktree add after (breaks the "fork and try something different" flow, easy to forget and pollute the parent tree)
  • start a brand-new chat in a worktree (loses all the prior context that made me want to fork in the first place)

proposed

on "fork from here", expose a toggle:

  • fork in current worktree (today's default)
  • fork into new worktree (new — mirrors the new-chat "open in worktree")

when "into new worktree" is picked:

  • create a git worktree from current HEAD (or let me pick the base branch, same UX as the new-chat flow)
  • root the forked convo in that worktree, keeping full message history up to the fork point
  • show the worktree path in the session header like worktree-based new chats already do
  • same keep/delete cleanup prompt on session end that the new-chat worktree flow uses

why it matters

  • parallel exploration with zero file collisions — fork to try an alt refactor while the original thread keeps iterating in the main worktree
  • consistency: "open in worktree" already exists for new chats, forks having no equivalent is a surprising gap
  • forking is most valuable exactly when comparing two paths, and today path two has to overwrite path one's files, which kills the point
  • low cost — both building blocks (fork a convo, open a chat in a worktree) already ship, this is composing them, not a new subsystem

supersedes #49954 (stale-closed), 3 people had pinged that one

View original on GitHub ↗