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

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Title: cursor-app-control MCP tool move_agent_to_root hangs indefinitely (never returns)

Summary: Calling the move_agent_to_root MCP tool from an agent consistently hangs and never returns. Two separate invocations each ran 230s+ with no response and had to be manually interrupted.

Environment:

OS: macOS (darwin 25.5.0)
Repo: git worktree-based setup
Source workspace: /Users/galkeren/Dev/matrix (branch CTD-8634/feature/fb-paid-arr)
Target root: /Users/galkeren/.cursor/worktrees/matrix/ctd8619 (existing worktree, branch kereg/feature/CTD-8619-conversion-enhanced-monitoring)
Steps to reproduce:

From an agent in workspace A, call move_agent_to_root with rootPath pointing to an existing git worktree.
Tool never returns.
Observed: Call blocks indefinitely (>230s), no error, no completion. Expected: Agent root switches to the target worktree and the tool returns promptly.

Diagnostics ruled out (target worktree was healthy):

Branch exists on origin (git ls-remote confirms it) — so it’s not the “Remote branch not found on origin” path.
Working tree clean, ahead 1 / behind 0 — ff-merge would be a no-op.
No *.lock files in the worktree’s git dir.

Steps to Reproduce

Steps to reproduce:

From an agent in workspace A, call move_agent_to_root with rootPath pointing to an existing git worktree.
Tool never returns.

Expected Behavior

Agent to move to requested worktree and not hang

Operating System

MacOS

Version Information

Version: 3.6.31 (Universal)
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
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
xterm.js: 6.1.0-beta.220
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Opus 4.8 Medium

For AI issues: add Request ID with privacy disabled

75511444-a2ed-4d19-9345-e6fbb94c981f

Does this stop you from using Cursor

No - Cursor works, but with this issue

The indefinite hang you’re seeing is a variant of the error Kevin reported earlier in this thread; on newer versions, the failure mode shifted from a fast error to a permanent hang.

The workaround: File > Open Folder on the worktree path, then start a fresh chat there.

Our team is actively working on improving worktree handling in agent migration. No timeline to share, but fixes are in progress.

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am moving from a Windows to a Mac and trying to get all of my work brought over. When trying to ensure my Databricks app is ready to updated and deployed, my workspace wants to open a project folder we created to start deploying. However, when making the switch, I am getting stuck on “Switching workspace root.” I saw there was an issue with this back in April. Is there a fix to this available yet?

Steps to Reproduce

Open a new workspace and ask Cursor to connect to a folder in order to get out of the sandbox.

Expected Behavior

Move to the new workspace folder and be ready for app updates and deployment.

Operating System

MacOS

Version Information

ersion: 3.9.8
VS Code Extension API: 1.105.1
Commit: 4aa8ff1b7877ed7bd01bcba308698f71a6735380
Date: 2026-06-25T01:39:30.490Z (4 days ago)
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.5.0

For AI issues: which model did you use?

Sonnet 4.6

Does this stop you from using Cursor

No - Cursor works, but with this issue

this is kind of a really annoying bug. would be great if the team could look into this! TY!

Thanks Mohit! Cursor’s ability to manage multiple editor windows/project roots is what makes me use it over Claude code/Codex. The editor window just being there along with every single chat makes reviewing code way easier and that’s why it’s super annoying when it doesn’t work. Would be awesome if you could bump the priority on this and get a fix out soon!

I just started using Cursor with stacked PRs, now that they’re officially supported on GH, and this triggers the bug described here all the time. The behavior is not quite the same (it’s stacked PRs and not worktrees), but the behavior is identical.