Cursor can only access Terminal with legacy terminal tool on

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

  • Cursor IDE

Describe the Bug
When using Cursor IDE on Windows, agent shell commands fail when Legacy Terminal Tool is disabled. The shell tool returns:
The shell command returned no exit status, so its result is unknown.
If Legacy Terminal Tool is enabled, the same commands work.

Steps to Reproduce

  1. Open Cursor IDE on Windows 11.
  2. Go to Agent settings and disable Legacy Terminal Tool.
  3. In agent chat, run a simple shell command (for example echo hello).
  4. Observe failure: “no exit status / result unknown.”
  5. Re-enable Legacy Terminal Tool.
  6. Run the same command again.
  7. Command succeeds (returns output and exit code 0).

Expected Behavior
Agent shell commands should run and return normal output/exit status even when Legacy Terminal Tool is disabled.

Screenshots / Screen Recordings

  • Attached screenshot of Agent settings page showing only Legacy Terminal Tool under terminal-related settings (no visible sandbox policy setting).

    image
    image845×267 7.24 KB

Operating System

  • Windows 10/11 (Windows 11, build 10.0.26200)

Version Information

IDE:

  • Version: 3.7.27
  • VSCode Version: (from About Cursor on your machine)
  • Commit: (from About Cursor on your machine)

CLI:

  • Not applicable (issue is in IDE agent terminal tool path)

For AI issues: which model did you use?

  • Codex 5.3 (agent)

For AI issues: add Request ID with privacy disabled

  • Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1

Additional Information

  • Tried: Reload Window, full Cursor restart, new chat, and Terminal: Kill All.
  • Terminal: Kill All sometimes temporarily helps, but issue returns with legacy off.
  • Relevant log line seen during failures:
    Sandbox policy 'workspace_readwrite' is not supported on this system... Windows sandbox helper only provides network proxy, not filesystem isolation
  • Also saw occasional transport warning near failures: Received chunk for unknown stream.

Does this stop you from using Cursor?

  • no
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

7

Hi @Joseph_Nelson Thank you for the forum post! we have pretty similar last names it seems like

What you’re running into is a Windows-specific limitation of the agent’s command sandbox. On macOS and Linux, auto-run commands can execute inside a sandbox that isolates the filesystem, but on Windows that isolation isn’t available (the Windows helper only handles network proxying). On the build you’re on (3.7.27), the sandbox-backed Auto-Run option is still offered on Windows, so when the newer (non-legacy) terminal tool tries to use it, the command is rejected before it runs and the model just sees The shell command returned no exit status.... That’s also why turning Legacy Terminal Tool on makes it work: the legacy path doesn’t go through the sandbox at all.

Two ways to get this working:

  1. Update to the latest version. A recent update changes this behavior on Windows so the agent no longer tries to use the unsupported sandbox path, which removes the failure. Your 3.7.27 build predates that change, so updating is the cleanest fix. You can grab it from the in-app updater or from cursor.com.

  2. If you can’t update right away, or if anything still misbehaves afterward, adjust your Auto-Run mode: Cursor Settings > Agents > Auto-Run, and choose a mode that isn’t sandbox-backed (for example the plain “Allowlist” / “Use Allowlist” option rather than the “…with Sandbox” one). That keeps the newer terminal tool but skips the unsupported sandbox path. Leaving Legacy Terminal Tool on, as you found, is also a perfectly fine stopgap in the meantime.

Let me know how this goes!

8

updating and turning off legacy terminal did not fix the problem. Ill have to dig into it a bit more later.

9

Ok! Can you share the version you’re on and a bit more info?

10

image
image362×333 8.88 KB

11

Good afternoon. Since today’s outage, I’ve started experiencing this problem as well.

At first, I thought the issue was on my side, and I noticed that I could update the desktop app, so I did that. Afterward, I realized that the issue was not on my side and that the shell terminal problem seemed to be related to the outage.

Unfortunately, updating the app and waiting out the outage did not fix it.

As a workaround, enabling the Legacy Terminal solved the issue for me, as the author suggested.

12

Same user-facing error here (“The shell command returned no exit status…”), but I don’t think this is the Windows sandbox / Legacy Terminal case Kevin described.

I’m on macOS 26.5.1 (arm64), Cursor 3.11.2 (commit 8406a18), update.releaseTrack = “dev”.

What fails

  • Agents Window (glass) agent tools: Shell and Glob
  • Errors: spawn EBADF, and/or “shell command returned no exit status”
  • Also seeing GlassDiffService / git helpers fail with spawn EBADF in the same glass windows

What works

  • Host shell outside Cursor is fine
  • IDE Integrated Terminal is fine
  • Agent chat inside the classic IDE window (real folder open) can run Shell/Glob

So this looks specific to glass / cursor-agent-exec, not a broken macOS shell or IDE PTY.

Extra signal from diagnostics

  • Glass logs: “Extension isolation is disabled (forced disabled in glass mode)” and stacks through workbench.glass.main.js → cursor-agent-exec → child_process.spawn → EBADF
  • Ephemeral Agents Window workspaces under ~/.cursor/projects/var-folders-…/T-/ often have no terminals/ dir (only canvases/ + mcps/)
  • Retrieval extension-host also leaks FDs hard: ~22k open files almost immediately, mostly from ~/Library/Application Support/Cursor/snapshots/roots/…/objects/pack (~24k pack files / 5.3GB in one root; 18GB snapshots total). Soft restart clears processes, but the leak comes back within ~15s.

Workaround for me: use Agent in the IDE window or the CLI, Agent window is completely blocked due to lack of terminal access by the agent.

Happy to attach log dirs 20260708T212419 and 20260708T222831 if useful. If this should be a separate bug report (glass/macOS vs Windows/legacy terminal), say the word and I’ll open one.

13

I dug this down further on Windows and found that there appear to be two separate Cursor-side failures, while VSCode on the same machine does not reproduce either one.

Environment

- OS: Windows 11 / win32

- Cursor: 3.9.16

- Workspace: local folder

- Shell configured in Cursor: PowerShell 7

- VSCode on same machine: same command works fine

Minimal repro

Ask Cursor agent/composer to run:

`echo hello`

What happens

- In VSCode: returns `hello`

- In Cursor: fails depending on backend

Failure mode 1: non-legacy path

Cursor logs show the command can fail before execution with the Windows sandbox limitation:

File:

`C:\Users\jerry\AppData\Roaming\Cursor\logs\20260710T150606\window2_wb1\exthost\exthost.log`

Evidence:

`SandboxUnsupportedError: Sandbox policy ‘workspace_readwrite’ is not supported on this system`

`Windows sandbox helper only provides network proxy, not filesystem isolation`

Failure mode 2: legacy path

I enabled Legacy Terminal Tool and retried `echo hello`.

Cursor then switched to the legacy executor path, but the command still failed. The trace shows it using:

`NaiveTerminalExecutor.execute`

and timing out after ~30s on `echo hello`.

Files:

`C:\Users\jerry\AppData\Roaming\Cursor\logs\20260710T152549\window1\output_20260710T152553\cursor.requestTraces.log`

`C:\Users\jerry\AppData\Roaming\Cursor\logs\20260710T152549\window1\exthost\anysphere.cursor-agent-exec\Cursor Agent Exec.log`

Important clue

Outside Cursor, I can reproduce the exact same visible behavior with:

`cmd.exe echo hello`

That prints the Windows banner and drops to a prompt without printing `hello`.

But:

`cmd.exe /c echo hello`

works correctly.

This matches Cursor legacy screenshots very closely, so the legacy Windows executor may be invoking `cmd.exe` incorrectly (bare argument instead of `/c`, or equivalent incorrect handoff).

Also confirmed

Cursor is already resolving its default shell to pwsh, so this is not just a bad terminal profile:

File:

`C:\Users\jerry\AppData\Roaming\Cursor\logs\20260710T152549\window1\exthost\exthost.log`

Evidence:

`Default shell changed: C:\Users\jerry\AppData\Local\Microsoft\WindowsApps\pwsh.exe`

Conclusion

This looks like a Cursor-specific Windows bug in both terminal backends:

- non-legacy path fails on unsupported sandbox-backed execution

- legacy path appears to invoke cmd incorrectly and never actually executes the command text

VSCode on the same machine does not have the issue.

15

Update: found it.

The Agents Window extension-host was holding ~22k open files, almost all under ~/Library/Application Support/Cursor/snapshots (pack objects). On macOS that blows past the spawn FD limit, so child_process.spawn fails with EBADF and the agent reports “no exit status”. Classic IDE agent was fine because it wasn’t that process.

Restart alone doesn’t help. The host reopens the snapshot packs within seconds.

Fix that worked for me:

  1. Quit Cursor fully (Cmd+Q)
  2. rm -rf ~/Library/Application\ Support/Cursor/snapshots
  3. Relaunch

That only drops Cursor’s local agent checkpoints, not git history. After clearing ~18GB of snapshots, Shell/Glob in glass worked again.

So the bug is the Agents Window keeping thousands of snapshot pack FDs open.

16

Hi Fernando, thanks for coming back with this and glad to hear that it solved it

17

@Joseph_Nelson @Jerry_Jiang I think you might benefit from trying this:

Updating can hide the old Windows sandbox option without clearing its saved value. Please try this exact reset:

1. Open Cursor Settings > Agents > Auto-Run.

2. Select Auto-review, then select plain Allowlist again.

3. Keep Legacy Terminal Tool off.

4. Start a new agent chat and run `echo hello`.

This is different from simply updating. It rewrites the hidden sandbox preference. Please let me know whether that exact reset works.