Shell Sandbox preflight fails (Exit 101)

Support Bug Reports
, ,
1

Cursor Bugreport: Shell Sandbox preflight fails (Exit 101)

Summary

After updating Cursor to 2.6.13 and restarting, Cursor shell sandbox support is no longer available on this system.

Cursor logs show sandbox detection preflight failure and set sandboxSupported=false.

Environment

  • OS: Debian 13 (trixie/testing)
  • Kernel: 6.12.73+deb13-amd64
  • Architecture: x86_64
  • Cursor version: 2.6.13 (2.6.13-1772779363)

What changed

  • Cursor was upgraded from 2.6.12-1772664362 to 2.6.13-1772779363.
  • After update + restart, sandbox detection fails.

APT history excerpt:

  • 2026-03-07 15:10:48 Upgrade cursor:amd64 (2.6.12-1772664362 -> 2.6.13-1772779363)

Expected behavior

Cursor shell sandbox support should be detected as available (sandboxSupported=true) as before.

Actual behavior

Cursor detects sandbox support as unavailable:

  • sandboxSupported=false
  • Sandbox preflight fails with exit code 101

Reproduction

  1. Start Cursor 2.6.13 on Debian 13.
  2. Open any workspace.
  3. Observe startup logs in exthost.log/renderer.log.
  4. Optional manual preflight run:
/usr/share/cursor/resources/app/resources/helpers/cursorsandbox \
  --sandbox-policy-cwd /home/alex \
  --sandbox-policy '{"type":"workspace_readwrite","cwd":"/home/alex","additionalReadwritePaths":[],"additionalReadonlyPaths":["/etc/ssl/cert.pem","/private/etc/ssl/cert.pem","/etc/ssl/certs/ca-certificates.crt","/etc/ssl/ca-bundle.pem","/etc/pki/tls/certs/ca-bundle.crt","/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem","/home/alex/.ssh"],"networkAccess":false,"disableTmpWrite":false}' \
  --preflight-only -- /bin/true
echo $?

Observed result: 101

Relevant log evidence

From ~/.config/Cursor/logs/20260307T151135/window1/exthost/exthost.log:

[shell-exec:sandbox] [isSandboxHelperSupported] Running preflight with binary:
/usr/share/cursor/resources/app/resources/helpers/cursorsandbox
[shell-exec:sandbox] [isSandboxHelperSupported] CWD: /home/alex
[shell-exec:sandbox] [isSandboxHelperSupported] Preflight failed: Command
failed: /usr/share/cursor/resources/app/resources/helpers/cursorsandbox ...
[shell-exec:sandbox] [isSandboxHelperSupported] Exit status: 101
[ExtHostShellExec] Sandbox support detected: false

From ~/.config/Cursor/logs/20260307T151135/window1/renderer.log:

[MainThreadShellExec] $updateShellExecCapabilities: ... sandboxSupported=false

Historical comparison (same machine/kernel), from ~/.config/Cursor/logs/20260301T162000/window1/renderer.log:

[MainThreadShellExec] $updateShellExecCapabilities: ... sandboxSupported=true

Additional notes

  • firejail works independently on this machine.
  • bubblewrap (/usr/bin/bwrap) is present and executable.
  • User namespaces are enabled:
    • kernel.unprivileged_userns_clone = 1
    • user.max_user_namespaces = 126950
  • Cursor Linux sandbox prerequisites from docs appear satisfied:
    • Kernel >= 6.2 is satisfied (6.12.73+deb13-amd64)
    • Unprivileged user namespaces are enabled
  • AppArmor packaging/profile state is inconsistent after updates:
    • dpkg -l shows cursor-sandbox-apparmor in state rc
    • /etc/apparmor.d/cursor-sandbox exists on disk
  • This report focuses on Cursor’s internal sandbox helper regression between versions that previously worked and current 2.6.13.

Local resolution (workaround, no downgrade)

The issue was resolved locally without downgrading Cursor by fixing AppArmor rules for Cursor sandbox helpers.

Applied steps:

sudo apt purge -y cursor-sandbox-apparmor
sudo apt install -y cursor-sandbox-apparmor
sudo rm -f /etc/apparmor.d/cursor-sandbox.bak
sudo sed -i 's/^  #userns,/  userns,/g' /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox-remote
sudo sed -i '/capability setpcap,/a\  network,' /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox-remote
sudo /usr/sbin/apparmor_parser -r /etc/apparmor.d/cursor-sandbox
sudo /usr/sbin/apparmor_parser -r /etc/apparmor.d/cursor-sandbox-remote
sudo systemctl restart apparmor

Validation after restarting Cursor:

  • Manual preflight returns 0.
  • Logs show sandboxSupported=true and Sandbox support detected: true.

Important:

  • These local profile edits may be overwritten by future package updates.
3

Hey, thanks for the thorough report. It’s really well structured and makes it easy to track the issue.

This is part of a broader set of Linux sandbox issues we’ve been tracking over the past few weeks. A couple related threads for context:

Your case is especially interesting because it’s a clean regression between 2.6.12 and 2.6.13 on the same system. One thing I noticed is you have cursor-sandbox-apparmor in rc state (removed, but config files still on disk at /etc/apparmor.d/cursor-sandbox). Could you check a couple things?

  1. Is AppArmor actually active on your Debian 13?
cat /sys/module/apparmor/parameters/enabled
sudo aa-status | grep cursor
  1. Is that leftover profile loaded?
sudo aa-status 2>/dev/null | grep -i cursor

If it’s loaded, try removing it:

sudo apparmor_parser -R /etc/apparmor.d/cursor-sandbox
sudo rm /etc/apparmor.d/cursor-sandbox

Then restart Cursor and test again.

If AppArmor is active and restricting unprivileged user namespaces, a quick (less secure) workaround is:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

I flagged this with the team as a possible regression in 2.6.13 specifically. No timeline yet, but your detailed version comparison helps with prioritization.

Let me know what AppArmor status shows.

4

Quick response! :grinning_face: I fixed it locally using the cursor agent. The agent also updated the bug report to describe the local fix that I did. So both my local fix and the bug report was mainly done by the agent. Its why I won’t try out your fix. :grin:

5

The agent says :smiley: Thanks for the detailed follow-up.

I did not run any additional changes from your latest suggestions yet. Here is the current state from my previous investigation:

  • AppArmor is active (/sys/module/apparmor/parameters/enabled = Y).
  • Cursor-related profiles are loaded in enforce mode:
    • cursor_sandbox (enforce)
    • cursor_sandbox_remote (enforce)
    • cursor_sandbox_agent_cli (enforce)
  • I initially had cursor-sandbox-apparmor in rc state, but later reinstalled it cleanly (ii, version 0.4.0).

What I observed during debugging:

  • Initial failure: user namespace step (unshare(CLONE_NEWUSER), EACCES).
  • After enabling userns in the Cursor AppArmor profiles, that error disappeared.
  • Next failure moved to loopback setup.
  • After adding network, to the same profiles, preflight succeeds:
    • cursorsandbox ... --preflight-only -- /bin/true returns 0
  • After Cursor restart:
    • logs show sandboxSupported=true
    • Sandbox support detected: true

So in my case this looks like an AppArmor profile completeness/regression issue around 2.6.13, not a generic kernel/userns absence.

If useful, I can share exact before/after profile snippets and command outputs.

7

Update with reproducible regression details (Debian 13 / AppArmor 4.1):

Environment:

  • OS: Debian 13 (trixie/testing)
  • Kernel: 6.12.73+deb13-amd64
  • AppArmor parser: 4.1.0
  • Cursor upgraded to: 2.6.14-1772985435
  • cursor-sandbox-apparmor package: 0.4.0

What happened after upgrade to 2.6.14:

  • Sandbox broke again immediately.
  • Manual preflight:
    /usr/share/cursor/resources/app/resources/helpers/cursorsandbox … --preflight-only – /bin/true
    => exit 101

Why it broke (again):

  • Upgrade reverted /etc/apparmor.d/cursor-sandbox content to defaults.
  • Specifically:
    • #userns, was commented again
    • network, was missing again
  • That reproduces the same sandbox failure pattern.

Re-applied local AppArmor fix:

  • Enable userns, in:
    • /etc/apparmor.d/cursor-sandbox
    • /etc/apparmor.d/cursor-sandbox-remote
  • Add network, in both profiles
  • Reload with apparmor_parser + restart apparmor

Result after re-apply:

  • Same preflight command returns 0
  • Sandbox works again

Conclusion:

  • This is reproducible across Cursor upgrades on this system:
    Cursor update → AppArmor profile reset/insufficient profile → sandbox fails
    → manual profile patch → sandbox works.
8

This issue reproduced again after later Cursor upgrades on the same machine:

  • Upgrade to 2.6.14 → sandbox failed again (preflight returned 101)
  • Upgrade to 2.6.18 → sandbox failed again (preflight returned 101)

In both cases, the effective trigger was the same:

  • /etc/apparmor.d/cursor-sandbox had reverted to a stricter/default state
  • #userns, was commented again
  • network, was missing in that profile

Re-applying the same AppArmor edits restored functionality each time:

sudo sed -i 's/^  #userns,/  userns,/g' /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox-remote
sudo sed -i '/capability setpcap,/a\  network,' /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox-remote
sudo /usr/sbin/apparmor_parser -r /etc/apparmor.d/cursor-sandbox
sudo /usr/sbin/apparmor_parser -r /etc/apparmor.d/cursor-sandbox-remote
sudo systemctl restart apparmor

Current status after latest re-apply:

  • Manual preflight returns 0
  • Cursor logs show sandbox support enabled again

Conclusion:

  • This is reproducible across Cursor upgrades here: upgrade → profile reset/incomplete → sandbox fails → manual profile patch → sandbox works again.
9

Thanks for the updates. It’s really helpful that you confirmed this is reproducible across three versions (2.6.13, 2.6.14, 2.6.18).

The root cause is clear. The default AppArmor profile shipped in the .deb package is incomplete (userns is commented out, and network is missing), and every update overwrites your changes.

Until this is fixed in the package, there’s a more durable workaround. Make the profile immutable after patching it:

sudo chattr +i /etc/apparmor.d/cursor-sandbox
sudo chattr +i /etc/apparmor.d/cursor-sandbox-remote

This prevents the .deb installer from overwriting the files during updates. When you need to edit them, revert it with sudo chattr -i.

Other users with the same issue described this approach here: AppArmor cursor-sandbox profile incomplete on Linux — sandbox does not work correctly (missing network, signal, userns)

I’ve shared this with the team, including the detail that the profile gets reset on every upgrade.

10

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.