Linux sandbox Step 4/7 (mount denies): ENOENT on nested .vscode under a .cursorignore’d parent

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Linux, the Agent Shell sandbox fails at preflight whenever a protected .vscode directory sits under a parent ignored by .cursorignore (here: priv/).

The .vscode folder exists on the host (normal directory, e.g. with tasks.json). The sandbox still reports ENOENT and aborts setup, so every sandboxed command fails — including echo, true, or gcc. This is not an AppArmor / user-namespace failure: the sandbox starts, then dies at step 4/7 (mount denies).

Typical error:

Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed:
IO error: Failed to mount “/…/priv/someProject/.vscode” read-only:
IO error: No such file or directory (os error 2)

Cause: .cursorignore removes priv/ from the sandbox namespace (ignore mapping), then a hardcoded deny-mount of .vscode/** looks up a path that is no longer there.

Removing .vscode/ from .cursorignore while keeping priv/ does not fix it. Listing those .vscode paths in .cursor/sandbox.json additionalReadonlyPaths does not fix it either. Opening the repo via a symlink vs the real path only changes the path in the error.

Workaround: temporarily move the agent workspace root to a subdirectory that does not contain those nested .vscode trees; sandbox then starts. Restoring the repo root brings the failure back. Deleting author .vscode folders or un-ignoring priv/ is not acceptable (private/solution trees would flood agent context).

Related but not the same: WSL2 .git/hooks deny-mount ENOENT; missing additionalReadwritePaths aborting init.

Steps to Reproduce

  1. Use a git-backed folder as the Cursor workspace root.
  2. Add a directory pattern to .cursorignore, e.g. priv/.
  3. Create a real nested project dir that Cursor also treats as a protected path:
    <repo>/…/priv/someProject/.vscode/tasks.json
    (the .vscode directory must exist on disk).
  4. Keep Agent sandbox enabled (Auto-review or Allowlist with Sandbox).
  5. In Agent chat, ask the agent to run any shell command, e.g. echo ok or gcc --version.

Expected Behavior

If a hardcoded protected deny-mount (.vscode/**, etc.) is missing or unreachable after .cursorignore mapping, skip that mount and continue. The sandbox should start; ignored priv/ should hide files from the agent without blocking gcc (and other commands) in the rest of the repo.

Actual: sandbox init aborts; the agent cannot run any sandboxed command and must request unsandboxed all.

Operating System

Linux

Version Information

Cursor IDE 3.16.17 (commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0), x64
Where it appears: Cursor IDE — Agent Shell / terminal sandbox (not the user integrated terminal; CLI not tested)

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Your breakdown of what’s happening is correct.

Sandbox first hides folders from .cursorignore, in this case priv/, and then in a separate pass it tries to protect every .vscode it finds. When .vscode is inside a parent that’s already hidden, the second step can’t find the path and crashes instead of just skipping it. This is a known issue on our side that we’re tracking, and I’ve added your report to it. Also worth calling out that you’re on plain Linux, not WSL2, which is helpful.

Until we have a fix, the least painful workaround if you want to keep priv/ ignored is to run the agent’s shell commands without sandbox for this workspace:

  1. Cursor Settings > Agents > Approvals & Execution.
  2. Pick a run mode with no sandbox for shell commands, either Run Everything or Allowlist with sandboxing turned off.

Sandbox is a security layer, so only do this in repos you trust. Your approach of moving the workspace root into a subdirectory also works if you want to keep sandbox enabled. More on run modes: Run Modes | Cursor Docs

I can’t share an ETA yet, but I’ll post in the thread once there’s an update.