When using multi-repo workspaces an error is often toasted (something about changing workspace root in a mult-repo workspace). This also causes agents to terminate their turn without completing their task. Happens across models and also inconsistently.
Steps to Reproduce
Start a conversation with a workspace that contains multiple repos (i tend to use VScode workspace files)
Expected Behavior
The agent will just stop after running one or two commands.
Hey @Andrew_Anastasiades, thanks for the report! This isn’t intended behavior and it’s nothing in your setup - in multi-repo workspaces the agent sometimes tries to switch its own workspace root mid-run, which fails and ends the turn early. It’s an issue we’re already tracking.
Two workarounds for now:
Run the affected tasks from a single-folder window (open just the repo you’re working in).
Or add a rule telling the agent not to switch the workspace root (not to call move_agent_to_root) and to run its commands from the target folder instead.
Same problem here move_agent_to_root aborts the in-flight turn and never resumes (“Switching workspace root”, then silence)
Repro
Open a multi-root .code-workspace (or any workspace whose environment.id is not the single-folder id of repo A).
Start a local Agent chat. Give it a task in repo A.
Let the agent call MCP cursor-app-control / move_agent_to_root with rootPath = repo A (even if A is already in the workspace).
Observe: “Switching workspace root” → generation ends cancelled → new workbench may open on repo A → no agent.turn.start on the new composer.
Worktree on a local-only feat/* (never pushed) → git fetch origin <branch> → Remote branch not found on origin.
Calling the tool mid-turn (the common case: the tool itself is the in-flight MCP call).
I made another issue with the full detail of the bug and some analysis of the underlying code causing it so that cursor devs can fix this
@Andrew_Anastasiades a fix for the “changing workspace root” error in multi-repo workspaces has landed and will ship in an upcoming version. Once you’re on it, give it another try. Until then the workarounds above still apply (run from a single-folder window, or a rule telling the agent not to switch the workspace root).
One caveat: if the agent still stops right after a successful root switch on the newer version, let me know here with your version, that part is tracked separately.