Move_agent_to_root fails for valid published git worktrees

Where does the bug appear (feature/product)?

Cursor for iOS

Describe the Bug

Cursor version: 3.19.13 (arm64)
OS: macOS 26.6.2 / Darwin 25.6.0
Model: GPT-5.6 Sol
Severity: Medium — blocks normal agent worktree migration
Request ID:

Steps to reproduce:

  1. Open a Git repository in Cursor Agent.
  2. Create a clean external Git worktree on a new branch.
  3. Push the branch and verify git fetch origin <branch> succeeds.
  4. Invoke cursor-app-control.move_agent_to_root with the worktree’s absolute path.

Expected:
Cursor moves the agent’s visible workspace root and default terminal cwd to the worktree.

Actual:
Cursor displays “Failed to move agent root”. The tool returns:
Error: Tool execution error. Aborted

Reproduction:
Reproduced consistently with two distinct, clean, published worktrees. Git status, remote tracking, fetch, and git rev-parse --show-toplevel all succeed. Creating a fresh worktree does not help.

Workaround:
Keep every command pinned to the worktree using an explicit working directory and set active-branch metadata without migrating the visible root.

Console/log evidence:
The target worktree is successfully discovered/materialized, but Cursor emits no actionable root-migration error.

Steps to Reproduce

  1. Open a Git repository in Cursor Agent.
  2. Create a clean external Git worktree on a new branch.
  3. Push the branch and verify git fetch origin <branch> succeeds.
  4. Invoke cursor-app-control.move_agent_to_root with the worktree’s absolute path.
  5. Observe the “Failed to move agent root” popup and Tool execution error. Aborted.

Operating System

MacOS

Version Information

Cursor IDE 3.19.13 (Universal, arm64), macOS 26.6.2 / Darwin 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @Baruh_Matsliah, thanks for the detailed report.

This is a known issue we’re already tracking, and I’ve added your report to it. When the agent moves into an existing worktree, the move currently tries to carry the chat’s original branch over and check it out in the destination. Git refuses that while the branch is still checked out in your primary checkout, so the move fails. Because the move also interrupts the turn that called it, the tool call itself shows up as “Aborted” rather than with the real reason.

Your workaround is the right one for now: keep the agent where it is and run commands against the worktree with an explicit working directory.

If you still have it, could you paste the full text of the “Failed to move agent root” popup? It normally includes the underlying git message, which lets us confirm it is the same case. I would expect it to read:

fatal: '<branch>' is already used by worktree at '<path>'