3.17.8: auto move_agent_to_root treats local multi-root as multi-repo cloud agent

[ArielR]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On 3.17.8 (2026-08-20 harness/cloud-agent release), a LOCAL agent in a multi-root workspace cannot switch into a git worktree.

The agent harness — not the user — auto-calls cursor-app-control move_agent_to_root after git worktree add. It fails with:

Failed to move agent root: Cannot pull a multi-repo cloud agent into a single-folder workspace

This is not a cloud agent. It is a local chat over a 9-folder .code-workspace. New _resolveMultiRepoMigrationRepoTargets treats branchesByRepo unique-repo-count > 1 as a multi-repo cloud agent, then refuses a single-folder destination. Telemetry class: workspace_shape_mismatch. MCP returns Aborted; other tools in the same turn abort too.

Did not happen on the previous build. Same auto-worktree flow worked yesterday.

Related (different error, same area):

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.f…

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

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 che…

Steps to Reproduce

1. Open a local multi-root workspace with ≥2 git repos (not Cloud Agent).
2. Start a local Agent chat.
3. Ask it to work in an isolated git worktree.
4. Harness succeeds at git worktree add, then auto-calls move_agent_to_root({ rootPath: <worktree> }).
5. Toast + MCP Aborted.

Retrying with rootPaths (keep siblings, swap one folder for the worktree) also aborts in that turn.

Expected Behavior

Local multi-root is not a cloud agent. Auto move into an existing linked git worktree should only retarget cwd/workspace — no cloud-agent migration / branchesByRepo shape check.

isMultiRepo(branchesByRepo) must not classify a local multi-root workspace as a multi-repo cloud agent.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.17.8
VSCode Version: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
Layout: glass
Build Type: Stable

WSL2 Ubuntu 24.04.4 (workspace). Windows 11 10.0.26200.9168 (Cursor host).

For AI issues: which model did you use?

Grok 4.6

For AI issues: add Request ID with privacy disabled

ff1da3f7-cd33-4ece-84c9-0614cbcfc1eb

Additional Information

User never invokes move_agent_to_root. The agent worktree skill/harness does it automatically.

Worktree itself is fine (path exists, branch checked out, pnpm install succeeded). Only the root switch fails.

Same 3.17.8 bundle also says: “Worktree chats require a single-root workspace.” So even a successful multi-root rootPaths move would still be blocked from becoming a worktree chat. Two new rules collide.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Colin]

Hey @ArielR, thanks for the report! Your read on what’s happening is right.

This is a known issue we’re already tracking (a local multi-root chat getting treated as a multi-repo cloud agent during the root move), and I’ve added your report to it.

In the meantime, two things should work around it:

• Run worktree flows from a single-folder window (open just the repo you’re working in),
• Add a rule telling the agent not to call move_agent_to_root after creating a worktree and to run its commands from the worktree directory instead. The worktree itself works fine without the root switch.