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.

[Colin]

Hey @ArielR,

A fix for the root move failing with the “multi-repo cloud agent” error when a local agent in a multi-root workspace moves into a single folder has landed and will be included in an upcoming version of Cursor. Once you’re on a version that has it, that check should no longer block the auto move into a worktree.

Moving into a git worktree from a multi-root workspace goes through a couple of other steps we’re still improving, so if the root switch still fails after updating (especially with a different error message), please post the new message and a request ID here and we’ll take a look.

Thanks again for the report.

[Egor1]

Auto-reparenting a No Repo chat without an explicit confirm is still the bug that matters — 3.21/3.22 only make move_agent_to_root fail less, there is still no opt-out, and a User Rule is not a hard off switch. People use these threads as a task tracker; when a chat jumps folders mid-work, that history is no longer where they left it. Files can go in a folder; the conversation should not move unless I say so.

[Colin]

Hey @Egor1, thanks for weighing in.

You’re describing something a bit different from what this thread is about. This thread tracks the root move failing with an error; you’re asking that the agent not move a chat at all without an explicit confirmation, or that there be a way to turn that off.

That’s a fair request and it’s one we’re tracking separately. I’ve added your note to it. If you want to make the case for it in more detail, a post in Feature Requests is the best place so others can vote on it.

For now, a rule asking the agent to stay in the current folder and run commands from the worktree path is the closest thing to an off switch, with the caveat you already noted that it isn’t a hard guarantee.