Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
I’m not sure why I’m getting this error when I try to run something in the sandbox:
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
Steps to Reproduce
Chat log
Cursor Agent v2026.01.28-fd13201
~/gitlab/vs/python-code · dead
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Hi! Can you write and run a Python script that prints numbers 1-10? │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ print_numbers.py +3 -1 │
│ │
│ - │
│ + """Print numbers 1 through 10.""" │
│ + for i in range(1, 11): │
│ + print(i) │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
🔒cd /home/jje/gitlab/vs/python-code && uv run python print_numbers.py exit 1 • 850ms
$
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
Trying plain Python:
🔒python /home/jje/gitlab/vs/python-code/print_numbers.py exit 1 • 815ms
$
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Wait, maybe run it with uv? │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
🔒cd /home/jje/gitlab/vs/python-code && uv run python print_numbers.py exit 1 • 854ms
$
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
Running with full permissions to bypass the sandbox mount limit:
$ cd /home/jje/gitlab/vs/python-code && uv run python print_numbers.py Aborted
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Ok, reading these docs, what do you think is going on: [Pasted text #1 +204 lines] │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
From the docs and the error you saw, here’s what’s going on.
The sandbox never started
The message was:
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
So the failure is at sandbox setup (step 4 of 7, in the “mount” phase), not because the sandbox blocked uv or your script. The
environment hit a mount count limit (e.g. 1000), so the sandbox couldn’t be created at all.
On Linux the Agent uses Landlock, seccomp, and user namespaces; those often involve extra mounts. If the system (or user) has
too many mounts or namespaces already (Docker, snaps, NFS, other containers, etc.), that limit can be reached and the sandbox
fails to apply.
What you can do
1. Run without sandbox when it fails
When the command fails, use Run so the same command runs outside the sandbox. Then uv run python print_numbers.py should
work.
2. Allowlist the command
Use Add to allowlist so that this command (e.g. uv run python ...) is allowed to run outside the sandbox automatically next
time, avoiding the mount limit for that command.
3. Reduce mount/namespace usage
If you want the sandbox to work again in general, free some mounts/namespaces (e.g. stop unneeded containers, unmount unused
volumes) or, if your system allows, raise the relevant limits (e.g. user.max_user_namespaces or similar, depending on your
distro).
So: the docs describe how the sandbox works and how to Run or Allowlist when it blocks or can’t start. In your case the sandbox
didn’t start because of a mount limit; using Run (or allowlisting uv) is the practical way to get uv run python print_numbers.py
to execute.
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ What's a mount limit? Is that something wrong on my machine? │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
What’s a “mount limit”?
A mount is when the system attaches a filesystem to a directory (e.g. a disk partition, network share, or a “virtual”
filesystem). The kernel keeps a list of all active mounts.
A mount limit is a cap on how many of those can exist — either:
• Globally (total mounts on the system), or
• Per user / per namespace (e.g. for unprivileged user namespaces, which the Cursor sandbox uses on Linux).
The “1000” in your error is likely either a limit used by the sandbox itself or a per‑user/per‑namespace limit on your system,
not the kernel’s global maximum.
Is something wrong on your machine?
Usually no. Common reasons to hit a limit:
1. Lots of mounts
Things like Docker, Podman, Snap, Flatpak, NFS, and other containers/desktop stuff create many mounts. That’s normal; it just
uses up the limit.
2. Limit set low
Some distros set a low limit (e.g. 1000) for user namespaces or related resources for security. Your machine is “obeying”
that limit, not broken.
3. Sandbox cleanup
If the Agent has run many sandboxed commands, it’s possible some mounts/namespaces weren’t fully released, so you gradually
approach the limit. Again, that’s an environmental/usage thing, not a sign your OS is misconfigured.
So: a mount limit is a normal, intentional safeguard. Hitting it usually means “this environment has a lot of mounts/namespaces”
or “the limit is set fairly low,” not “your machine is broken.” Using Run or the allowlist for uv is a reasonable way to keep
working without changing your system.
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Am I able to see what's been mounted since reboot? Not sure why I would hit the limit. │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Checking the mount list and count on your system:
🔒mount | wc -l && echo "---" && mount exit 1 • 1.2s
$
Error: Failed to apply sandbox: IO error: Step 4/7 (mount denies) failed: Mount count limit reached (1000)
The Agent can’t run commands on your machine right now because the sandbox still won’t start, so you’ll need to run these in
your own terminal.
1. Count how many mounts exist
mount | wc -l
or, if you have findmnt:
findmnt --output TARGET --noheadings | wc -l
2. See the full list of mounts
mount
3. See mounts in a tree (often easier to read)
findmnt
4. See only “real” filesystem mounts (exclude pseudo filesystems)
findmnt -t ext4,btrfs,xfs,nfs,fuse
5. Check user-namespace / mount-related limits (often where “1000” comes from)
cat /proc/sys/user/max_user_namespaces 2>/dev/null || echo "N/A"
and, on some setups:
cat /proc/sys/fs/mount-max 2>/dev/null || echo "N/A"
So: yes, you can see what’s been mounted since reboot with mount or findmnt; the limit you’re hitting is likely either the total
number of those mounts or a max_user_namespaces (or similar) cap, and running the commands above will show which it is.
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ [Pasted text #2 +88 lines] │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Your machine looks fine.
• 38 mounts — nowhere near 1000 or any system limit.
• max_user_namespaces = 253,719 — plenty.
• mount-max = 100,000 — kernel limit; you’re not close.
So the “Mount count limit reached (1000)” message is not from your system’s mount count or those kernel settings. You’re not
hitting a limit on the host.
That means the 1000 is almost certainly a limit inside Cursor’s Agent sandbox (its Linux Landlock/user-namespace setup), e.g.:
• An internal cap (e.g. 1000 of some resource when building the sandbox), or
• A different failure that gets reported as “mount limit 1000”.
So: nothing wrong on your side. The sandbox is failing due to its own logic/limits, not because you have too many mounts. Using
Run or Add to allowlist for those commands is the right workaround; if you want it fixed in Cursor, it’s worth reporting to them
with that error message and your kernel version (e.g. uname -r).
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ → Add a follow-up INSERT │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Auto · 13.4% · 1 file edited
/ commands · @ files · ! shell · ctrl+r to review edits
Operating System
Linux
Version Information
CLI Version 2026.01.28-fd13201
Model Auto
OS linux (x64)
Terminal alacritty
Shell fish
Does this stop you from using Cursor
No - Cursor works, but with this issue