Agent Shell hangs/crashes on NFS workspaces due to hardcoded sandbox glob patterns

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Every agent shell command (even pwd) hangs for 10-30+ minutes, or fails with:

Failed to mount “…/conda//…/venv” read-only: No such file or directory

I caught the sandbox process mid-hang in D state (uninterruptible I/O sleep) and read its policy file directly from /proc. It contains two path-matching systems:

ignoreMapping — sourced from .cursorignore, works correctly.
additionalReadonlyPaths — hardcoded, not exposed anywhere in settings, includes unanchored globs **/venv/ and **/.venv/. Matching these against any depth of a workspace requires walking the entire tree on every command, no exceptions.

My workspace has .snakemake/conda with 30K+ files across 20+ materialized conda environments. Resolving **/venv/ against that tree over NFS is what’s hanging. When it does finish, it sometimes finds a broken symlink inside a conda env and crashes instead.

This is not fixable via .cursorignore — that only controls ignoreMapping, a completely separate system from additionalReadonlyPaths. I confirmed this directly: excluding the slow directory in .cursorignore had zero effect on the hang.

Also: this happens even with sandbox nominally disabled via required_permissions: [“all”] or Auto-Run Mode → “Run Everything.” I caught a real cursorsandbox process with a live policy file running under “Run Everything” mode — so that setting isn’t fully bypassing sandbox setup.

Steps to Reproduce

Open a Remote-SSH workspace on an NFS-backed filesystem.
Have a directory in the workspace containing a large number of files at depth (in my case, .snakemake/conda, 30K+ files across 20+ conda environments).
Run any trivial command through the agent’s terminal tool, e.g. pwd. It hangs for 10-30+ minutes with no output, or eventually fails with the mount error above.
Add the large directory to .cursorignore (anchored, e.g. /data/). Rerun step 3 — no change, still hangs.
Switch Auto-Run Mode to “Run Everything” (or use required_permissions: [“all”] per command) to bypass sandbox. Rerun step 3 — still hangs. Confirmed via ps that a cursorsandbox process with a real --policy file is still spawned and stuck in D state.
Physically move the large directory out of the workspace entirely. Rerun step 3 — completes in under 1 second.

Expected Behavior

additionalReadonlyPaths glob resolution (**/venv/, **/.venv/) should respect .cursorignore/ignoreMapping exclusions, so an excluded directory isn’t walked into at all.
This hardcoded path list should be exposed/documented and ideally configurable, since it’s currently invisible and can’t be worked around.
A broken/missing mount target should fail fast, not only after a full multi-minute tree walk reaches it.
“Run Everything” / required_permissions: [“all”] should either fully skip sandbox process spawning, or the docs should clarify that these only skip the permission prompt, not sandbox setup itself.

Operating System

Linux

Version Information

Version 3.12.30

For AI issues: which model did you use?

n/a (replicated across models)

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

Hey, thanks for the detailed write-up. The /proc dump of the policy file and the split between ignoreMapping vs additionalReadonlyPaths help a lot.

The hang or crash matches what we see too. Before every command, the terminal sandbox runs a discovery pass over the workspace. On NFS with large directories like your .snakemake/conda with 30K+ files, that walk can get stuck on the network filesystem or crash on a broken symlink. Your finding that .cursorignore only controls ignoreMapping and does not affect resolving additionalReadonlyPaths lines up with our behavior, that is a separate path. Also worth calling out your note that Run Everything and required_permissions: ["all"] do not disable spawning cursorsandbox, I can confirm that as well.

I logged all of this in our internal tracker under an existing issue for the same NFS scenario. I can’t share a fix timeline yet.

What unblocks you right now, and you basically already found this, is keeping the heavy .snakemake/conda outside the workspace root so the sandbox discovery pass does not walk into it. In your case, after moving it, the command ran in under 1 second. If splitting the project is annoying, you can also physically move that directory outside and not keep it under the workspace root.

If I get an update on the fix, I’ll reply in this thread. Also let me know if moving the directory is not an option in your setup and we can think through other workarounds.