Agent chat freezes after move_agent_to_root (“Switched workspace root”)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Calling move_agent_to_root (Cursor app-control MCP) prints “Switched workspace root”, then the Agent chat often freezes / stops responding. Further tool calls in the same turn abort. Workaround is to avoid root switches and keep using absolute paths.

Steps to Reproduce

  1. Open Agent chat in Cursor IDE (Glass / Agent).
  2. Ask the agent to create or open a project outside the current workspace (e.g. C:\Users\<user>\Projects\family-android).
  3. Have the agent call move_agent_to_root with that path (via cursor-app-control).
  4. Observe the UI status “Switched workspace root”.
  5. Continue the same agent turn (more tool calls / reply).

Expected Behavior

Workspace root switches successfully, and the same Agent chat continues normally (tools and replies keep working).

  • UI shows “Switched workspace root”.
  • Agent turn then hangs / freezes from the user’s perspective.
  • Subsequent MCP tool calls in that flow fail with Aborted or related errors.
  • Related: create_project on Windows also failed earlier with spawn /bin/sh ENOENT during the same bootstrap flow.
  • Workaround that works: do not call move_agent_to_root; keep working with absolute paths in the original workspace.

Screenshots / Screen Recordings

cursor-forum-bundle-20260826-move-agent.zip (13.8 KB)

Operating System

Windows 10/11

Version Information

Version: 3.17.19 (user setup)
VS Code Extension API: 1.128.0
Commit: ae3a2b7231dd56194447fe4570dfdc61640b1e90
Date: 2026-08-24T06:42:14.583Z
Layout: IDE
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.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Auto

Additional Information

Extensions disabled test

  • Reproduced with extensions disabled (cursor --disable-extensions)
  • Not re-tested with extensions disabled (happened during normal Agent + MCP use)

Storage / memory notes

  • state.vscdb size: ~3.25 GiB (3493335040 bytes) at report time
  • state.vscdb.corrupted.* present: no

Log excerpts

Auto collect-cursor-logs.ps1 initially grabbed a nearly empty brand-new session folder (20260826T203922, zip ~2KB). Freeze happened earlier (~17:28–17:40 JST) in long-lived session 20260825T160215.

From MCP Logs in that session:

2026-08-25 19:02:27.278 [info] [McpLease] Removing client cursor-ide-browser, reason: mcp_provider_unregistered
2026-08-26 14:03:19.450 [info] [McpLease] Removing client cursor-ide-browser, reason: mcp_provider_unregistered
2026-08-26 14:17:08.446 [info] [McpLease] Removing client cursor-ide-browser, reason: mcp_provider_unregistered
2026-08-26 17:34:54.564 [info] [McpLease] Removing client cursor-ide-browser, reason: mcp_provider_unregistered

Agent-side errors observed in chat (not always mirrored into *.log):

create_project → Failed to initialize git repository: spawn /bin/sh ENOENT
move_agent_to_root → Tool execution error. Aborted
(UI: "Switched workspace root" then chat freezes)
cursor-ide-browser → Server not found (MCP provider did not re-register within 30000ms)

Attachment zip (manual rebuild from freeze-time session):
cursor-forum-bundle-20260826-move-agent.zip (~14KB; no secrets / no state.vscdb body)

Workarounds tried

  • Avoid move_agent_to_root entirely; use absolute paths under C:\Users\...\Projects\...
  • Continue Agent work after the freeze by sending a new user message (“つづけて”) — sometimes recovers, but root switch remains unreliable

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. The logs, version, and exact errors really help.

About move_agent_to_root. When the agent switches the workspace root in the middle of a turn, that switch interrupts the turn that triggered it, and the chat doesn’t always reliably continue in the new workspace. That matches the freeze and Aborted tool calls you’re seeing. We’re aware of this and tracking it, and I attached your report. Your workaround is correct. Keep using absolute paths and prevent the agent from calling move_agent_to_root a project rule that blocks this call works well. The fastest way to unstick a frozen chat is to send a new message.

About create_project with spawn /bin/sh ENOENT on Windows. That’s a separate issue, and you were the first to point it out. It looks like the git init step on Windows is going to the wrong shell. I’ve passed this to the team.

Let me know if the workaround doesn’t help, or if you notice anything else.