Terminal Sandbox Issue Linux

[groov]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Terminal sandbox is not working. When I open Cursor IDE I get this error on the left down part of the screen : 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.

I tried to follow documentation, but it didn’t resolve my issue. I restarted IDE, my laptop, internet etc multiple times. Deleted and installed from zero. Still same error. What is more interesting is that it was working just fine, then I switched to another folder project and it just stopped working at all in every other project as well. Nothing changed on my laptop. I will attach screenshots, when I ask in Cursor chat to run some command it doesn’t even output the command so I can run it. Whats interesting is that it doesn’t work for specific model

Steps to Reproduce

Open Cursor and try to ask agent to run some command.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Version: 2.5.25
VSCode Version: 1.105.1
Commit: 7150844152b426ed50d2b68dd6b33b5c5beb73c0
Date: 2026-02-24T07:17:49.417Z
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-14-generic

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, this is a known issue with AppArmor on newer Linux kernels (6.2+). A few things to try:

1. Check if there’s a stale AppArmor profile loaded:

sudo aa-status | grep cursor

If you see cursor_sandbox listed, unload it:

sudo apparmor_parser -R /etc/apparmor.d/cursor_sandbox
sudo rm /etc/apparmor.d/cursor_sandbox
sudo systemctl restart apparmor

2. Create a proper AppArmor profile for Cursor:

Create /etc/apparmor.d/cursor-system with this content:

abi <abi/4.0>,
include <tunables/global>
profile cursor-system "/usr/share/cursor/cursor" flags=(unconfined) {
  userns,
  include if exists <local/cursor>
}

Then load it:

sudo apparmor_parser -r /etc/apparmor.d/cursor-system

3. Make sure the sandbox binary has the right permissions:

sudo chmod 4755 /usr/share/cursor/resources/app/resources/helpers/cursorsandbox

Restart Cursor after all of this.

This has been resolved for several other Linux users with similar setups. For more context, see this thread: `cursor-sandbox` binary missing setuid bit breaks extensions and this one: Linux AppArmor regression after Cursor update: sandbox helper rename breaks Remote SSH

Also, which distro are you on? Ubuntu?

Let me know if this helps.

[Piezo]

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

[jarrett]

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.

[jarrett]

I had Claude Code run through a lot of this stuff for me, I believe all of your suggestions, and I wasn’t able to get a resolution to the problem. Full notes here: Terminal sandbox could not start - #7

[deanrie]

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.

[randunel]

Same issue here, followed your instructions and they didn’t solve the issue.

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 24.04.4 LTS
Release:	24.04
Codename:	noble

cursor --version
2.5.26
7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
x64

[DimitrisT]

Have the same issue, suggested solution didn’t help. Ubuntu 24.04.4 LTS

[Milos_D]

Same here.

[mstoute]

Hitting this issues as well!

[Aaron_Smith]

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

[roka (róka)]

same here

[MagentaX]

Same issue here on Zorin OS 18 (Ubuntu 24.04 base), kernel 6.17.0-14-generic, Cursor 2.5.25.

I spent a while debugging this and wanted to document everything for anyone else who hits it.

Diagnosis

Running sudo journalctl -xe | grep -i apparmor | grep cursor | grep DENIED revealed that the official AppArmor profile shipped in cursor-sandbox-apparmor.deb is incomplete. It is missing several rules that the sandbox actually requires. The denials I saw were:

1. capability dac_override — missing from the profile entirely
2. network unix stream / network unix dgram — no network rules at all in the profile
3. network netlink raw — also required but not included

What I tried

I progressively updated /etc/apparmor.d/cursor-sandbox to add the missing rules, reloading with sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox each time. Each fix resolved one layer of denials but revealed the next. Even after adding all of the above, the sandbox still failed to start.

The profile I ended up with (still not working):

abi <abi/4.0>,
include <tunables/global>

profile cursor_sandbox /usr/share/cursor/resources/app/resources/helpers/cursorsandbox {
  file,
  /** ix,
  network unix,
  network netlink raw,
  capability sys_admin,
  capability chown,
  capability setuid,
  capability setgid,
  capability setpcap,
  capability dac_override,
  userns,
  mount,
  remount,
  umount,
  /usr/share/cursor/resources/app/resources/helpers/cursorsandbox mr,
}

profile cursor_sandbox_remote /home/*/.cursor-server/bin/*/*/resources/helpers/{cursor-sandbox,cursorsandbox} {
  file,
  /** ix,
  network unix,
  network netlink raw,
  capability sys_admin,
  capability chown,
  capability setuid,
  capability setgid,
  capability setpcap,
  capability dac_override,
  userns,
  mount,
  remount,
  umount,
  /home/*/.cursor-server/bin/*/*/resources/helpers/{cursor-sandbox,cursorsandbox} mr,
}

Note: the install path on my system is /usr/share/cursor/ not /opt/Cursor/ as the docs suggest — worth checking yours matches.

The only workaround that actually fixes it:

echo 'kernel.apparmor_restrict_unprivileged_userns=0' | sudo tee /etc/sysctl.d/99-userns.conf
sudo sysctl --system

This disables the unprivileged user namespace restriction system-wide. Not ideal from a security standpoint but it works immediately with no Cursor restart needed.

Summary

The official AppArmor profile from Cursor is missing rules that the sandbox actually needs on Ubuntu 24.04 / Zorin OS 18. This seems to be a case of the shipped profile not being tested against this specific kernel + AppArmor configuration. The documented fix does not resolve the issue — the sysctl workaround is currently the only reliable solution on this distro.

Hope this helps the Cursor team track it down and ship a corrected profile. Thx :

[MagentaX]

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

[groov]

Hello Sir. I tried methods you suggested, but this error is still present. From what I can see a lot of other users also encounter this error message which wasn’t the case until recently. Perhaps it’s more of a AppArmor profile issue shipped with .deb package? Btw I’m on Ubuntu 24.04. I understand that this was resolved before although from the links you posted I’m not sure that this is exactly the same issue. And you can also see that a lot of users tried steps you provided and it didn’t resolve it for them either. Is there any other workaround, or we should wait for you guys to update it?

[mjryan1 (Matthew Ryan)]

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.

[Wallace_Ferreira]

This error usually means AppArmor is blocking Cursor’s terminal sandbox on Linux 6.2+

You can fix it by disabling the AppArmor restriction for unprivileged user namespaces.

Run these commands:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

To make it persistent after reboot:

echo "kernel.apparmor_restrict_unprivileged_userns=0" | sudo tee /etc/sysctl.d/99-cursor.conf

sudo sysctl --system

Then restart Cursor and open a new terminal.

If it still fails, confirm AppArmor is enabled and you’re on kernel 6.2+.

[Kyle_Nguyen]

Seeing this issue. Anyone have a fix for Amazon Linux 2023?

Edit: This seems to help on Fedora. However, I still get “stuck” at Planning next moves, Reconnecting…, Thinking, etc. regardless of model selected.

curl -fsSL https://downloads.cursor.com/lab/enterprise/cursor-sandbox-apparmor-0.2.0-1.noarch.rpm -o cursor-sandbox-apparmor.rpm
sudo rpm -i cursor-sandbox-apparmor.rpm

[Colin]

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.

[FlorinAndrei]

This issue appeared suddenly and recently.

I get the popup every time I build something on Linux. It’s not limited to some isolated machine. It’s a systemic issue.

This is a bug in Cursor.