Preserve thread context when switching git worktrees

[artile]

Problem

When working with git worktrees, a common AI-assisted workflow is:

1. Start an agent thread in the main worktree.
2. The agent (or the user) creates a new git worktree for a feature branch via git worktree add.
3. The user wants to switch Zed to that new worktree path and continue the same agent conversation in that new working directory context.

Today this is impossible in one step. git::SwitchWorktree drops the agent panel draft and open threads when switching (WorktreeOperation::Switch sets source_for_transfer = None in crates/git_ui/src/worktree_service.rs). Transfer of workspace state — including agent threads — only happens for WorktreeOperation::Create (new worktrees created from Zed's own UI).

So the actual flow forces the user to:

1. Create/switch the worktree (2–3 clicks or a keybinding).
2. Re-open the agent panel in the new window/workspace.
3. Manually re-establish context (re-paste instructions, re-describe the task, etc.).

This breaks the continuity of AI-assisted development across worktrees.

Expected behavior

When a user (or agent) switches to a git worktree — whether via git::SwitchWorktree, the worktree picker, or a programmatic action — the active agent thread should be transferred to the new workspace/worktree context, analogous to how WorktreeOperation::Create already copies workspace state.

Ideally:

• The agent thread's message history is preserved.
• The working directory context seen by the agent updates to the new worktree root.
• Open files are remapped (this already works for SwitchWorktree).

At minimum, an opt-in flag on SwitchWorktree (e.g. transfer_agent_state: bool) would allow callers to request the transfer.

Current workaround

None that preserves thread history. Users must start a new thread after switching, duplicating context manually.

Why this matters

Git worktrees are the idiomatic way to work on multiple branches simultaneously without stashing. Agents that create worktrees as part of their workflow (e.g. "create a branch and implement this feature in isolation") leave the user stranded in the original worktree with a broken handoff. Carrying agent context across the switch would make the worktree + agent workflow fully continuous.

Related

• crates/git_ui/src/worktree_service.rs — WorktreeOperation enum and source_for_transfer logic
• crates/git_ui/src/git_ui.rs:77 — SwitchWorktree action registration
• zed_actions::SwitchWorktree struct (currently { path: PathBuf, display_name: String }, no transfer flag)

[jrolfs]

Personally, I like that most context (including agent threads) is linked to a given worktree, most of the time. However, I sometimes find myself wanting to detach, duplicate, or transfer a thread from one worktree to another, and it would be really nice to be able to do that. Personally, the ideal experience would be to include it in the contextual menu for a specific thread (while also exposing a command palette/binding item).

[code3z]

Yes! for me, I want to open some things on staging, multiple at once, start discussing with the agent, and if I decide that 1. edits are needed and 2. it's going to be more than just one or two low-risk edits, I want to create a new branch on a new worktree, leaving the other agents in staging

[code3z]

Curious what you've been able to do to try to detach a thread, my best method so far is just having one agent generate a block of text instructions to paste into the new agent. I know cursor stores agent transcripts in JSON, maybe giving that to the next agent is a better idea if Zed does the same

[HernandoR]

This feature is very important because I often have the agent start from the main branch to create several new, parallel feature branches (worktrees), which are eventually merged. In most cases, I can review them through other means, or if the feature is small, no review is needed. However, sometimes there are issues with the feature itself or the agent's implementation process, so I need to review its changes. The problem is that all thread is tied to the main branch, making it impossible to simultaneously view or continue the context while switch to a work tree to inspect the files.

[ttnghia]

Agree - this is extremely important. I feel very frustrated when switching branch/worktree and my chat/terminal disappears. I want to keep the same agent CLI open for all the worktrees so I can see diff while keep working with my agent.

[yawn]

100% agree. Applies also to agentic terminal threads which are currently somewhat unusable in slightly more advanced agentic workflows.

[Eyal-Shalev]

Can we have the building block for it be a change-root tool like in Cursor?

I'm trying to switch over from Cursor (because of the many bugs) to Zed.

My past workflow was to open a new chat in the main checkout, then (after initial research) I ask the agent to open a new worktree and switch to it. This frees me from the mechanical work of creating a worktree, before I even know its needed or what it should be called.

Note that the Cursor change-root tool is very buggy which I had to work around, and is also why I'm searching for an alternative Agentic orchestrator/harness.

[yawn]

I think automatic switching could / should also be an option. When a terminal or agentic terminal thread switches worktrees changes that I want to edit / view files there ought to be pretty high.

[Eyal-Shalev]

Agreed.

I just think that if we had that building block, even just API access that extensions/plugins could use, it would open up a lot more options.