Linux sandbox fails — cannot find ripgrep in mount namespace

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After fixing AppArmor profile issues that prevent the sandbox from starting (see prerequisites below), sandboxed commands fail at the pre-discovery step:

Error: Failed to apply sandbox: IO error: Step 0/7 (pre-discovery) failed: IO error: ripgrep execution failed (binary: /usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg): No such file or directory (os error 2)

The binary exists, is statically linked, and runs correctly outside the sandbox:

$ file /usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg
ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped

$ /usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg --version
ripgrep 15.1.0-cursor4 (rev 07f36110f4)

The sandbox creates a mount namespace that does not bind-mount /usr/share/cursor/, making the binary invisible from inside the namespace.

Prerequisites: related AppArmor profile issues (separate bugs, must be fixed first):

Steps to Reproduce

  1. Install Cursor 2.6.11 via .deb on Ubuntu 24.04 with kernel 6.14
  2. Install cursor-sandbox-apparmor 0.2.0
  3. Fix both AppArmor profiles as described above and reload them
  4. Restart Cursor
  5. Run commands in agent mode — some or all fail with the ripgrep error

Expected Behavior

The sandbox’s mount namespace should include /usr/share/cursor/ (or at least the ripgrep binary path) so that pre-discovery can run. The binary is Cursor’s own — the sandbox should always be able to find it.

Operating System

Linux

Version Information

  • Cursor 2.6.11 (also reproduced on 2.5.26), x64, installed via .deb
  • cursor-sandbox-apparmor 0.2.0

Additional Information

Environment:

  • Ubuntu 24.04.4 LTS
  • Kernel 6.14.0-37-generic
  • AppArmor 4.0, profiles patched and loaded (see prerequisites)
  • Unprivileged user namespaces enabled (/proc/sys/kernel/unprivileged_userns_clone = 1)

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

In my case the setup is much simpler, yet I have the same issue.

Also, the sandboxing used to work for me, with the same CLI version. I have no idea what has changed so that it stopped working.

$ agent about
About Cursor CLI

CLI Version         2026.02.27-e7d2ef6
Model               Claude 4.6 Opus
OS                  linux (x64)
Terminal            unknown
Shell               bash

Prompting the agent to run simple echo command under sandbox fails with the same error:

  $ echo "Hello, world!" exit 1 • 142ms
    Error: Failed to apply sandbox: IO error: Step 0/7 (pre-discovery) failed: IO error: ripgrep execution failed (binary: /apps/fs1/mnikl/.local/share/cursor-agent/versions/2026.02.27-e7d2ef6/rg)​: No
    such file or directory (os error 2)
5

Hey,

Thanks for the detailed report, and especially your analysis across the companion threads. The AppArmor work is really thorough.

This is a known issue. On Linux, the sandbox mount namespace does not currently bind-mount the Cursor installation directory, which makes the ripgrep binary invisible during the pre-discovery step. A related thread reports the same root cause with the same error.

The team is aware and actively working on improvements to the Linux sandbox.

Workaround (to unblock yourself): you can bypass the sandbox for now:

  1. Go to Cursor Settings → Agents → Terminal

  2. Set Auto-Run Mode to Ask Every Time or Run Everything

  3. Restart Cursor

This allows agent commands to run outside the sandbox while the mount namespace issue is being addressed.

@mnikl — for the CLI agent case, the same class of issue applies. If there’s a sandbox config option in your CLI setup, setting the sandbox policy to insecure_none should bypass it. Also noting that your non-standard home path (/apps/fs1/...) may compound the issue, since the sandbox may have assumptions about standard paths.

I’ve filed this with the engineering team so it’s tracked for the .deb install case specifically.

Best,
Mohit