Terminal sandbox could not start

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

  • Cursor shows: “Terminal sandbox could not start. This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+).”
  • AppArmor is disabled (/sys/module/apparmor/parameters/enabled = N; not in LSM list). The cursor_sandbox profile at /etc/apparmor.d/cursor-sandbox is present (from the .deb) but never loaded.
  • exthost.log: sandbox fails at “Step 1-2/7 (user namespace): Failed to unshare namespaces: EPERM” — i.e. unshare(CLONE_NEWUSER) returns EPERM.

Steps to Reproduce

Environment

  • OS: Arch Linux
  • Kernel: 6.18.9-arch1-local
  • Cursor: cursor-bin 2.5.26-1 (AUR; repackaged official .deb)
  • LSM: capability,landlock,lockdown,yama,bpf (AppArmor not active)
  • Kernel config: CONFIG_SECURITY_LANDLOCK=y, CONFIG_USER_NS=y
  • User namespaces: enabled (unprivileged_userns_clone=1)

Steps

  • Start Cursor IDE.
  • Popups says: “Terminal sandbox could not start. This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+).”

What was tried

  • Verified kernel 6.2+, Landlock, unprivileged userns, and sandbox binary; all OK.
  • Ran checklist: no container; in the test shell NoNewPrivs and Seccomp are 0 and unshare -Ur works.
  • Ran cursorsandbox under strace -f -e unshare: main process gets unshare(CLONE_NEWUSER...) = -1 EPERM; one child got 0. So failure is per-process.
  • Checked Cursor process tree: main process has NoNewPrivs=0, Seccomp=0; zygote processes have NoNewPrivs=1, Seccomp=0. No seccomp filters found on checked PIDs.

Possible cause

The system and the shell used for checks allow unprivileged user namespaces; the same binary can succeed (child PID or Agent shell) or fail (main cursorsandbox) depending on process. That points to task-level restrictions on the process that runs the sandbox helper (e.g. inherited from Cursor/Electron) rather than kernel config or AppArmor. No further conclusion or fix is proposed here.

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.5.2
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.18.9-arch1-local

Does this stop you from using Cursor

No - Cursor works, but with this issue

2 Likes
Shell Sandbox preflight fails (Exit 101)
7

I spent some time using Claude Code to run through common suggestions and attempt to solve the error causing the message. Through this, I was not able to resolve the error, but I was able to produce the following documentation and insights. A lot of this is beyond my knowledge, but this summary from Claude might be helpful to anyone working on a fix.

Confirming: this is not an AppArmor or system configuration issue

I can reproduce this on Ubuntu with kernel 6.17.0-14-generic, Cursor 2.5.26 installed via .deb.

I went through the full set of commonly recommended fixes:

  1. Removed stale cursor_sandbox AppArmor profile
  2. Created /etc/apparmor.d/cursor-system with userns permission
  3. Set chmod 4755 on cursorsandbox
  4. Restarted AppArmor

None of these resolved the “Terminal sandbox could not start” warning.

System state confirms namespaces work fine

kernel.unprivileged_userns_clone = 1
kernel.apparmor_restrict_unprivileged_userns = 0
/proc/sys/user/max_user_namespaces = 54934

User namespaces work from a normal shell:

$ unshare --user --map-root-user echo hello
hello

The actual error from cursorsandbox

Running the preflight check directly reveals the real failure:

$ /usr/share/cursor/resources/app/resources/helpers/cursorsandbox \
    --preflight-only \
    --sandbox-policy-cwd /tmp \
    --sandbox-policy '{"type":"workspace_readwrite","cwd":"/tmp","folders":["/tmp"]}' \
    -- echo hello

Error: Failed to apply sandbox: IO error: Step 1-2/7 (user namespace) failed:
IO error: Failed to write /proc/self/uid_map (mapping UID 0 -> 1000):
Operation not permitted (os error 1) (errno 1)

The setuid bit (chmod 4755) makes it worse

The commonly recommended chmod 4755 on cursorsandbox causes the binary to run as UID 0 (root), which then tries to map UID 0 -> 1000 in the user namespace. The kernel rejects this uid_map write.

This binary is not the same as Chromium’s chrome-sandbox (which is designed to be setuid). cursorsandbox appears to be designed to run as a regular user and use unprivileged user namespaces. Setting setuid on it is counterproductive.

Likely root cause

As the OP of this thread identified, this appears to be a process-level restriction inherited from the Electron/Cursor parent process (likely NoNewPrivs or a seccomp filter) that prevents cursorsandbox from calling unshare(CLONE_NEWUSER), even though the system fully supports it. The error message blaming AppArmor is misleading in this case.

Terminal Sandbox Issue Linux
11

Hey, thanks for the detailed bug report and diagnostics, that’s really helpful.

Along with @jarrett’s investigation, the picture is pretty clear: the issue isn’t AppArmor or system config. It’s that cursorsandbox inherits restrictions from the parent Electron process (NoNewPrivs on the zygote), which blocks unshare(CLONE_NEWUSER).

The usual suggestions (an AppArmor profile, chmod 4755) don’t help here, and like you correctly noticed, setuid can even make it worse.

I’ve flagged this with the team. This needs an engineering-level fix in how cursorsandbox is spawned from the Electron process tree. No timeline yet, but your detailed analysis really helps us prioritize it.

3 Likes
13

I’m seeing similar behavior on my system running 6.17.0-14-generic on Ubuntu 25.10.

14

Getting the same popup on Zorin OS 18 (Ubuntu 24.04 base), kernel 6.17.0-14-generic, Cursor 2.5.25.

System details

  • OS: Zorin OS 18
  • Kernel: 6.17.0-14-generic
  • Cursor: 2.5.25
  • kernel.apparmor_restrict_unprivileged_userns = 0
  • unshare --user --map-root-user echo hello works fine from a normal shell

What I tried

I ran sudo journalctl -xe | grep -i apparmor | grep cursor | grep DENIED and found the official profile in cursor-sandbox-apparmor.deb was generating multiple denials that aren’t covered by the shipped rules. I progressively added the missing rules to /etc/apparmor.d/cursor-sandbox:

  • capability dac_override
  • network unix
  • network netlink raw

Profile loaded successfully each time (aa-status | grep cursor confirmed both cursor_sandbox and cursor_sandbox_remote were active), but the popup persisted after each change.

Hope these details are useful

2 Likes
15

I’m also nearly exactly the same setup (zorin os 18, 6.17.0-14-generic) on Cursor 2.5.26 and I’m also having this same reproducible issue. Trying that fix now to get around this asap, but Thank you and thank you cursor team for investigating as well.

16

Hi all!

We’ve bumped the priority of this bug internally. Thank you for your reports, and we’ll come back when we have more to share.

3 Likes
18

We have made improvements to address this in version 2.6. Please comment here or open a new thread if you’re still experiencing the issue.

19

Hi

I also see

Terminal sandbox could not start. This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+). See the documentation for how to resolve this.

every time I connect to my ssh computer.

I’ve tried to install apparmor

curl -fsSL ``https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor_0.2.0_all.deb`` -o cursor-sandbox-apparmor.deb && sudo dpkg -i cursor-sandbox-apparmor.deb

Version: 2.6.12 (Universal)
VSCode Version: 1.105.1
Commit: 1917e900a0c4b0111dc7975777cfff60853059d0
Date: 2026-03-04T21:41:18.914Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

20

I see this every time I open cursor on my ubuntu 24.04.4 LTS. Cursor details:

Version: 2.6.13
VSCode Version: 1.105.1
Commit: 60faf7b51077ed1df1db718157bbfed740d2e160
Date: 2026-03-06T06:17:49.499Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-14-generic