"Move to" / move_agent_to_root fails: migration runs `git checkout main`, collides with primary worktree

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment

  • macOS; Cursor
  • A git repo (~/code/mono) whose primary checkout is on branch main
  • A linked git worktree on a feature branch (created via git worktree add),
    e.g. ~/code/mono-wt-<slug> on branch feature/x

Root-cause hypothesis

The “migration” step appears to carry the SOURCE root’s branch (main, from
the primary checkout) and run git checkout main at the destination, which
collides because main is already checked out in the primary. It should
instead respect the destination worktree’s already-checked-out branch, or skip
the migration checkout entirely for an existing valid worktree — which is what
the sibling move_agent_to_cloned_root already does (“skips the migration
git fetch / ff-merge”).

Impact

Moving an agent/chat into a per-ticket worktree is a core workflow; this makes
it impossible via both the MCP tool and the UI, forcing “degraded mode”
(absolute file paths + per-command working directory) for the whole session.

Steps to Reproduce

Repro (deterministic)

  1. Primary checkout ~/code/mono is on main.
  2. Create a worktree: git worktree add ../mono-wt-x -b feature/x.
  3. From a chat rooted in the primary, move the chat’s root into the worktree,
    via EITHER:
    • the agent MCP move_agent_to_root (rootPath = the worktree), OR
    • the chat context menu → “Move to” → .

Actual

Both entry points fail with:
Failed to checkout migrated branch “main”: Command failed: git checkout main
fatal: ‘main’ is already used by worktree at ‘/Users/…/code/mono’

Expected Behavior

The move succeeds; the chat root becomes the worktree, which is already
checked out on its own branch — no git checkout should be needed.

Operating System

MacOS

Version Information

Version: 3.9.16
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

Opus 4.8

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey Nico! Thanks for the write-up and root-cause analysis.

This is a known issue we’re tracking. Moving an agent/chat into an existing user-created worktree still runs a git checkout for the source branch, which collides with git’s worktree lock. It still reproduces on current builds and isn’t fixed yet.

The reliable workaround is to skip the move entirely: open the worktree folder directly with File → Open Folder (point it at your mono-wt-<slug> path) and start a fresh chat there. Git already binds the branch to that worktree directory, so no checkout is needed and you get a normal, non-degraded session rooted in the worktree.

No timeline to share yet, but it’s on our radar and I’ll follow up here when there’s progress.

8

Got it. It’s a bit of a hassle to start a new chat, because often my workflow is like this:

  1. Start a chat to investigate some issue
  2. Decide to make a ticket and start working on it (in a new worktree)
  3. Implement the ticket in that worktree

If I have to insert a new “start a new chat in the new worktree” as step 2.5, then the new chat won’t have all the context it developed in #1. Currently, I have it write up everything it thinks is relevant during step 2, so the new chat in step 3 will hopefully have everything it needs, but I suspect that’s not quite the same as the chat just having all the context from all the research it did.

But it’s not a huge deal. And I haven’t done benchmarking, it’s possible that the new 4-step process is actually better - maybe step 1 general a bunch of irrelevant context while the agent is searching files that don’t turn out to be important, etc, and forcing it to write up only what it thinks is relevant is a good way to start off the new chat with minimal context.