Sandboxed shell commands intermittently hang indefinitely (stuck in request_wait_answer), persists across container restart

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Sandboxed agent shell commands intermittently hang forever with zero output — even trivial commands like echo, true, pwd, whoami, kill -9, ps. Roughly 1 in 3 sandboxed invocations got stuck in this session. No error, no timeout — they simply never return unless manually terminated by the user.

Steps to Reproduce

Repro steps:

  1. Open an agent session in a Linux devcontainer running on Docker Desktop (linuxkit kernel)
  2. Run several sequential trivial shell commands via the agent (e.g. echo test, true, pwd)
  3. Observe that some fraction hang indefinitely with no output, while others succeed normally
  4. Restart the container and repeat — same behavior recurs

Expected Behavior

Trivial shell commands should return in well under a second.

Screenshots / Screen Recordings

Screenshot 2026-07-01 at 5.54.41 PM.png
Screenshot 2026-07-01 at 5.54.41 PM.png1074×586 64 KB

Operating System

Linux

Version Information

IDE version: 3.9.16 (Universal)

Additional Information

Environment: Devcontainer, kernel linux 6.12.76-linuxkit (Docker Desktop VM), container user root

Does this stop you from using Cursor

Yes - Cursor is unusable

6

This is a known issue with the terminal sandbox. Before each command, the sandbox scans the workspace filesystem to build its security policy. On Docker Desktop’s FUSE-backed mounts (how files are shared into devcontainers), that scan can hang when the FUSE layer stalls, which is why even trivial commands get stuck.

A few workarounds:

  1. Disable sandboxed execution in your auto-run settings (if your team’s admin policy allows). This removes the pre-command scan entirely and should immediately unblock you.
  2. Clone the repo onto the container’s native filesystem (a Docker named volume or clone inside the container) instead of using a host bind-mount. This avoids the FUSE layer.
  3. Try switching Docker Desktop’s file-sharing backend between VirtioFS and gRPC FUSE in Docker Desktop settings. One may be more stable for your setup.

Our team is aware of this and working on reducing the sandbox’s scanning overhead. I’ve attached your report to the tracking issue.

Let me know if any of those help!

8

Thanks for sharing the workarounds @mohitjain . Will give a shot to each.