Sandbox "Mount count limit reached (1000)" — ~/.cursorignore file-glob patterns walk entire $HOME

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent commands fail with:

Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)

I have a ~/.cursorignore with *.log in it. The sandbox ignoreMapping keys that pattern to $HOME. The cursorsandbox binary then walks my entire home directory, finds 9,242 .log files (in ~/.zoom/, ~/.npm/, ~/.cache/, etc.), and tries to create one bind mount per file. That blows past the 1000 mount cap.

Directory patterns like .git/ get one tmpfs mount per directory (efficient). File-glob patterns like *.log, .env, .DS_Store get one mount per individual file (the bug).

Raising CURSOR_SANDBOX_MOUNT_CAP=30000 stops the error but every sandboxed command still takes ~3s extra from walking $HOME and mounting thousands of files unrelated to the workspace.

Captured ignoreMapping from production (via wrapper around cursorsandbox):

{
  "/home/user/repos/redacted-org/redacted-project": [".direnv/", ".local/"],
  "/home/user/repos/redacted-org/redacted-project-2": [],
  "/home/user/repos/redacted-org": [],
  "/home/user/repos": [],
  "/home/user": [
    "node_modules/", "dist/", "build/", "out/", "cdk.out/",
    ".env", ".env.*", ".git/", "venv/", ".venv/", ".direnv/",
    ".idea/", ".vscode/", ".DS_Store", "Thumbs.db", "*.log"
  ],
  "/home": []
}

EVERYSPHERE_SANDBOX_DEBUG=1 output:

compute_glob_deny_actions (walker): planned_total=9351 hide_dir=623 hide_file=8728
failed at step 4/7 (mount denies): Mount count limit reached (2000)

The issue goes away if the ignoreMapping keys the patterns to the workspace root instead of $HOME. In the CLI reproducer (attached), scoping *.log to the workspace = 0 matches vs scoping to $HOME = 9,000+.

Workaround — in ~/.local/share/applications/cursor.desktop:

Exec=env CURSOR_SANDBOX_MOUNT_CAP=30000 /usr/share/cursor/cursor %F

Debug env vars that helped investigate:

  • EVERYSPHERE_SANDBOX_DEBUG=1 — verbose sandbox logging to stderr
  • CURSOR_SANDBOX_MOUNT_CAP=N — override 1000 mount limit

Steps to Reproduce

  1. Have ~/.cursorignore with file-glob patterns (e.g. *.log)
  2. Have a home directory with many matching files (typical Linux desktop has thousands of .log files in ~/.zoom/, ~/.npm/, ~/.cache/, etc.)
  3. Open a workspace under $HOME
  4. Run an agent command that executes inside the sandbox (not on the allowlist — e.g. ask the agent to “run wc -l * in the sandbox”)

I could not reproduce with workspaces under /tmp. The condition that causes the ancestor walk to populate ignoreMapping is unclear — may be account-specific or tied to $HOME.

CLI reproducer attached (no sudo, no system changes, cleans up on exit):

./replicate.sh       # 1280 planned mounts -> FAILS at cap
./replicate-fix.sh   # Same files, scoped to workspace -> 0 mounts, PASSES

Also attached: capture-sandbox-policy.sh to intercept the policy the IDE sends (sudo to install/uninstall).

Expected Behavior

Sandbox starts successfully. Patterns from ancestor .cursorignore files (like ~/.cursorignore) should not cause the sandbox to walk the entire home directory.

Operating System

Linux

Version Information

Version: 2.5.26
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-105014-tuxedo

Does this stop you from using Cursor

No - Cursor works, but with this issue

cursor-sandbox-mount-limit-bug.zip (3.8 KB)

Hey, thanks for the report.

This is the second report of the same bug in the last month (the previous one is here: Linux Sandbox: Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)), but yours is the most detailed. The root cause is now clearly identified. It is file-glob patterns from ~/.cursorignore that are limited to $HOME in ignoreMapping and end up creating bind mounts for individual files instead of tmpfs mounts for directories.

I’ve passed this to the team. I don’t have an ETA yet, but having such a clear reproduction case really helps us prioritize it.

Your workaround with CURSOR_SANDBOX_MOUNT_CAP=30000 is the best option available right now. The extra ~3 s per sandboxed command is annoying, but expected, since it still has to walk through $HOME.

We’ll update this thread as soon as there’s progress on a fix.

Thank you :raising_hands: There’s some condition that makes Cursor walk up from my project root and apply global patterns, but I haven’t figured out what triggers it. Even with Hierarchical Cursor Ignore OFF it still happened.

1 Like