Move_agent_to_root MCP fails in git worktrees

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor MCP tool: cursor-app-control → move_agent_to_root Repro environment: macOS, Cursor with workspace opened on a git checkout that is one of multiple linked worktrees of the same repository.

Steps to Reproduce

Repository has a primary checkout ~/repo on branch staging.

A linked worktree exists at ~/repo.feature-x on branch feature/x.

Cursor agent is rooted at ~/repo.

Call:

move_agent_to_root({"rootPath": "~/repo.feature-x"})

Expected Behavior

Agent root switches to ~/repo.feature-x. The agent’s working directory and tool context point at the new path. No git operations on the primary checkout.

Actual

Tool fails with:

Failed to move agent root: Failed to checkout migrated branch "staging": Command failed: git checkout staging
fatal: 'staging' is already used by worktree at '/Users/.../repo'

Reflog inspection shows the tool ran the following sequence in the primary checkout (not the new root):

  1. git checkout main (move primary off staging)
  2. git checkout <new-root-branch> (move primary onto the new root’s branch)
  3. git checkout staging (try to restore primary to its original branch — fails because staging is the primary’s worktree, not free to check out)

Operating System

MacOS

Version Information

Version: 3.2.16
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

claude-opus-4-7-low

Additional Information

Root cause hypothesis

move_agent_to_root assumes a single-checkout repository: it migrates the primary checkout’s branch to “follow” the agent, then attempts to restore the primary’s original branch as a finalize step. In a multi-worktree repo, the new root’s branch is already checked out at the new path (git worktree), so the migration step conflicts with the existing worktree, and the restore step fails because the primary’s original branch is now claimed by another worktree (itself).

Expected behavior in a worktree setup
When rootPath resolves to an existing linked git worktree of the same repository (detectable via git -C <rootPath> rev-parse --git-common-dir matching the current root’s), the tool should skip all branch migration and only update the agent’s workspace root. Git already maintains the branch-to-directory binding via worktrees.

Workaround
Open the new worktree path manually via File → Open Folder and start a fresh chat. The MCP tool cannot complete the move in this scenario.

Side effects observed (non-destructive)
The primary checkout’s HEAD was correctly restored to staging despite the error — the tool reported failure but the visible state ended up consistent. Reflog noise only.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

This looks like a bug.

Your workaround is correct: File > Open Folder on the worktree path, then start a fresh chat there. The MCP tool can’t complete the move in this scenario today. Our team is aware of the broader gaps around worktree support in agent migration and is actively working on improving this. We don’t have a timeline to share, but this is on our radar.

Thanks for the thorough report and root cause analysis.

Thanks will you notify when it is on the roadmap? Feels like the team is stuffing half baked features