Terminal Sandbox Issue Linux

Don’t do this

That is a system-wide security relaxation for all apps, instead of fixing it specifically for this one app.

___

I hit the same “Terminal sandbox could not start…” issue, but I was able to fix it.

Here’s an AI summary of the steps to reproduce the fix that worked for me:

What I saw
Kernel audit logs showed the real blocker was AppArmor denying newuidmap:

sudo journalctl -k -b | grep -E 'apparmor="DENIED".*(cursor|unprivileged_userns)' | tail -n 50
# Example deny:
# apparmor="DENIED" operation="capable" profile="cursor_sandbox" comm="newuidmap" capname="dac_override"

Fix (minimal, profile-scoped)
The Cursor sandbox profile (cursor_sandbox) was missing the capability newuidmap needs.

  1. Locate the profile file(s):
sudo grep -R --line-number -E 'profile[[:space:]]+cursor_sandbox(_remote)?' /etc/apparmor.d

  1. Edit the relevant file(s) (e.g. /etc/apparmor.d/cursor-sandbox and/or the one defining cursor_sandbox_remote) and add this line inside the profile cursor_sandbox { ... } block:
capability dac_override,

  1. Reload the profile(s):
sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox
# If you edited another file for cursor_sandbox_remote, reload that one too

  1. Fully restart Cursor, then retry opening the Agent terminal sandbox.

After this, the newuidmap deny disappeared and the sandbox started normally.

Hope this helps — the key was fixing the AppArmor profile.

Wtf guys!!

It took me an hour to painstakingly work through this bug with chatgpt a few days ago. But lo and behold. Here’s another untested upgrade pushed out to everyone and the bug gets resurrected. Just as soon as I upgraded to -

Version: 2.6.11
VSCode Version: 1.105.1
Commit: 8c95649f251a168cc4bb34c89531fae7db4bd990
Date: 2026-03-03T18:57:48.001Z
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.8.0-101-generic

I give up. I’m downgrading and will pin my installation at least two point versions back from the latest release henceforth. I don’t think the word ‘stable’ means what you think it means.

Here’s a fix that I worked out in a chatgpt session over a couple of hours. It amalgamates elements of solutions posted by others on this forum. I do not pretend to understand all of it. So please verify and use at your own discretion.

The rest of this post was drafted by chatgpt, but I read through if carefully before posting and it does indeed reflect the fix that I implemented .


Ubuntu 24.04 (AppArmor 4.x) + kernel 6.2+ (e.g. 6.8): “Terminal sandbox could not start” / Step 2.5/7 loopback NETLINK_ROUTE bind fails

Symptoms / logs typically show:

  • Cursor popup: “Terminal sandbox could not start… AppArmor…”

  • ~/.config/Cursor/logs/.../exthost.log:
    Failed to apply sandbox: Step 2.5/7 (loopback setup) ... failed to bind NETLINK_ROUTE socket

  • kernel audit:
    apparmor="DENIED" ... profile="cursor_sandbox" ... family="netlink" sock_type="raw" ... denied="bind"

Root cause (in this failure mode): Cursor’s shipped /etc/apparmor.d/cursor-sandbox is incomplete on Ubuntu 24.04+ and blocks the helper from doing rtnetlink/loopback setup (and sometimes userns / newuidmap/newgidmap bits). See related threads:

Below is an upgrade-resistant fix that avoids global sysctl weakening and avoids “allow-all”.


0) Confirm you have this exact failure mode

grep -R "Failed to apply sandbox" -n ~/.config/Cursor/logs | tail -n 60
sudo journalctl -k -b --since "10 minutes ago" --no-pager | \
  grep -iE 'apparmor="DENIED"|cursor_sandbox|unprivileged_userns' | tail -n 200

If you see Step 2.5/7 (loopback setup) + netlink raw bind denied, proceed.


1) Make the AppArmor profile upgrade-resistant (dpkg diversion)

Rationale: Cursor updates can overwrite /etc/apparmor.d/cursor-sandbox without prompting. dpkg-divert preserves your maintained file while still letting the vendor’s new profile install alongside as .distrib for diff/merge. The .predivert.date file is your backup.

sudo cp -a /etc/apparmor.d/cursor-sandbox /etc/apparmor.d/cursor-sandbox.predivert.$(date +%F_%H%M%S)

sudo dpkg-divert --local --rename --add \
  --divert /etc/apparmor.d/cursor-sandbox.distrib \
  /etc/apparmor.d/cursor-sandbox

Then base your maintained file on the vendor profile:

sudo cp -a /etc/apparmor.d/cursor-sandbox.distrib /etc/apparmor.d/cursor-sandbox

2) Patch /etc/apparmor.d/cursor-sandbox structurally (minimal edits)

Rationale: keep the vendor file mostly intact, add only what’s needed for Ubuntu 24.04/AppArmor 4.x and future helper renames, and delegate permissions to a local include.

Edit:

sudoedit /etc/apparmor.d/cursor-sandbox

Make these changes:

(a) Add at top (AppArmor 4.x compatibility)

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

(b) Attach profiles to both helper names (rename-proof)

Change the profile lines to:

profile cursor_sandbox /usr/share/cursor/resources/app/resources/helpers/{cursor-sandbox,cursorsandbox} {
...
}

profile cursor_sandbox_remote /home/*/.cursor-server/bin/*/*/resources/helpers/{cursor-sandbox,cursorsandbox} {
...
}

(c) Ensure userns, is enabled inside both blocks

Uncomment/add the following line to both blocks:

  userns,

(d) Make the mr rule match the brace path in both blocks

  /usr/share/cursor/resources/app/resources/helpers/{cursor-sandbox,cursorsandbox} mr,

and

  /home/*/.cursor-server/bin/*/*/resources/helpers/{cursor-sandbox,cursorsandbox} mr,

(e) Add a local include in both blocks

Rationale: keep your policy deltas in one place.

  #include if exists <local/cursor-sandbox>

Note: #include is an AppArmor preprocessor directive (not a comment).

(f) If you see capname="net_admin" denials in journalctl, add the following line to both profile blocks; otherwise you can omit it.

capability net_admin,

3) Put the actual missing permissions in /etc/apparmor.d/local/cursor-sandbox

Rationale: fix Step 2.5/7 (netlink) and common userns/newuidmap IPC needs without “allow all”.

sudo install -d -m 0755 /etc/apparmor.d/local

sudo tee /etc/apparmor.d/local/cursor-sandbox >/dev/null <<'EOF'
  # Required on Ubuntu 24.04+ restricted userns
  userns,

  # Required for Step 2.5/7 loopback/rtnetlink setup
  network netlink raw,
  network netlink dgram,

  # Commonly required for sandbox IPC
  network unix stream,
  network unix dgram,

  # newuidmap/newgidmap may need this
  capability dac_override,

  # If you create cursor-system profile below:
  signal (send, receive) peer=cursor-system,
EOF

4) Optional: add cursor-system to avoid disabling Ubuntu’s userns restriction globally

Rationale: some setups hit Ubuntu’s unprivileged_userns mediation; this avoids turning off kernel.apparmor_restrict_unprivileged_userns system-wide. This is “unconfined” for Cursor itself (which is typically unconfined anyway), but explicitly allows userns while keeping the global hardening on.

sudo tee /etc/apparmor.d/cursor-system >/dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile cursor-system "/usr/share/cursor/cursor" flags=(unconfined) {
  userns,
}
EOF

5) Reload AppArmor profiles

sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox
sudo apparmor_parser -r /etc/apparmor.d/cursor-system
sudo aa-status | grep -i cursor

Restart Cursor.


6) Validate (no new denials)

sudo journalctl -k -b --since "2 minutes ago" --no-pager | \
  grep -iE 'cursor_sandbox|apparmor="DENIED"|unprivileged_userns'

If clean and popup is gone, you’re done.


7) After each Cursor upgrade: diff & merge safely

Rationale: vendor may add new required rules in future; diversion keeps both versions available.

diff -u /etc/apparmor.d/cursor-sandbox.distrib /etc/apparmor.d/cursor-sandbox | less

Avoid the chattr +i /etc/apparmor.d/cursor-sandbox approach: it can cause apt/dpkg upgrade failures or leave the package half-configured. dpkg-divert is the packaging-native way to prevent overwrites while still receiving upstream changes for review.

Thanks to guys above, I was finally able to resolve this issue in my case. But still, this is deeper and needs to be resolved from Cursor team itself so users won’t find themselves searching for answers in critical moments. Below I will attach what helped in my case specifically, the main thing is to understand your particular error from the logs, I used this command :

grep -R "Failed to apply sandbox" -n ~/.config/Cursor/logs | tail -n 60
sudo journalctl -k -b --since "10 minutes ago" --no-pager | \
  grep -iE 'apparmor="DENIED"|cursor_sandbox|unprivileged_userns' | tail -n 200

With output :

/.config/Cursor/logs/20260303T120028/window2/exthost/exthost.log:19:2026-03-03 12:00:32.346 [error] [shell-exec:sandbox] [isSandboxHelperSupported] Stderr: Error: Failed to apply sandbox: IO error: Step 1-2/7 (user namespace) failed: Failed to unshare namespaces: EPERM: Operation not permitted
kernel: audit: type=1400 audit(1772663751.240:251): apparmor=“DENIED” operation=“create” class=“net” info=“failed af match” error=-13 profile=“cursor_sandbox” pid=6157 comm=“newuidmap” family=“unix” sock_type=“stream” protocol=0 requested=“create” denied=“create” addr=none


:white_check_mark: Working Fix for “Terminal sandbox could not start” on Ubuntu 24.04 (AppArmor 4.x, kernel 6.8) — Step 1-2/7

I’m posting this in case it helps others (and the Cursor team).

Environment

  • Ubuntu 24.04
  • Kernel 6.8
  • AppArmor 4.0.1
  • Cursor installed from official package

Symptoms

Cursor shows:

“Terminal sandbox could not start… This may be caused by an AppArmor configuration…”

Logs:

Failed to apply sandbox: Step 1-2/7 (user namespace) failed

Kernel audit log:

apparmor="DENIED"
profile="cursor_sandbox"
operation="create"
class="net"
family="unix"
sock_type="dgram"

Also similar DENIED entries for:

  • newuidmap
  • newgidmap
  • cursorsandbox

:magnifying_glass_tilted_right: Root Cause

On Ubuntu 24.04 with AppArmor 4.x, the shipped /etc/apparmor.d/cursor-sandbox profile is incomplete.

Specifically:

  • userns, alone is NOT sufficient
  • the profile does NOT allow creation of UNIX domain sockets
  • newuidmap / newgidmap require network unix stream
  • sandbox helper requires network unix dgram

So the sandbox fails at Step 1-2/7 because AppArmor blocks UNIX socket creation.


:white_check_mark: Minimal Fix (clean and safe)

Instead of disabling AppArmor or weakening global sysctl settings, I added a local override.

:one: Create local override file

sudo mkdir -p /etc/apparmor.d/local
sudo nano /etc/apparmor.d/local/cursor-sandbox

Add:

network unix stream,
network unix dgram,

:two: Ensure the main profile includes local override

Edit:

/etc/apparmor.d/cursor-sandbox

Inside BOTH profile blocks (cursor_sandbox and cursor_sandbox_remote), add:

#include if exists <local/cursor-sandbox>

:three: Reload profile

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

Restart Cursor.

:check_mark: Sandbox works immediately.
:check_mark: No more DENIED entries in journalctl.
:check_mark: No need to disable AppArmor.
:check_mark: No need to set kernel.apparmor_restrict_unprivileged_userns=0.


:pushpin: Suggestion for Cursor Team

The shipped AppArmor profile should probably include:

network unix stream,
network unix dgram,

inside the cursor_sandbox profile by default.

Ubuntu 24.04 + AppArmor 4.x enforces stricter mediation, and without these rules the sandbox helper cannot function properly.

This seems to be reproducible on a clean Ubuntu 24.04 install.


Hope this helps someone :raising_hands:

thanks, that helped

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.

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

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

In Ubuntu 22.04 I fixed it like this:

Fixed the terminal sandbox (AppArmor issue)

The root cause was that Cursor loads its own cursor_sandbox AppArmor profile dynamically at runtime, which was blocking netlink socket binding. We went through several dead ends:

  • AppArmor 3.0.4 on Ubuntu 22.04 doesn’t support the userns rule (requires 4.0+)

  • kernel.unprivileged_userns_clone=1 and kernel.apparmor_restrict_unprivileged_userns=0 didn’t help because the block was coming from Cursor’s own profile, not system settings

The actual fix was creating a manual AppArmor profile in complain mode (logs but doesn’t block):

bash

sudo tee /etc/apparmor.d/cursor_sandbox << 'EOF'
include <tunables/global>

profile cursor_sandbox flags=(complain) {
  include <abstractions/base>
  network netlink raw,
  capability,
  file,
  unix,
}

profile cursor_sandbox_remote flags=(complain) {
  include <abstractions/base>
  network netlink raw,
  capability,
  file,
  unix,
}
EOF

sudo apparmor_parser -r /etc/apparmor.d/cursor_sandbox

This overrides Cursor’s in-memory profile with a permissive one that survives reboots.

Then restart Cursor:

pkill -f cursor && sleep 2 && cursor

I have the same issue on a fresh install of Debian Trixie:

Version: 2.6.14
VSCode Version: 1.105.1
Commit: eb1c4e0702d201d1226d2a7afb25c501c2e56080
Date: 2026-03-08T15:36:54.709Z
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.12.73+deb13-amd64

I’m experiencing this on Linux Mint:

Version: 2.6.14
VSCode Version: 1.105.1
Commit: eb1c4e0702d201d1226d2a7afb25c501c2e56080
Date: 2026-03-08T15:36:54.709Z
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

I met this issue in the latest version as well:
Version: 2.6.18
VSCode Version: 1.105.1
Commit: 68fbec5aed9da587d1c6a64172792f505bafa250
Date: 2026-03-10T02:01:17.430Z
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

I’m experiencing this on ubuntu 24.4

I just upgraded 2.6.14→2.6.18 and the issue is still present.

Version: 2.6.18
VSCode Version: 1.105.1
Commit: 68fbec5aed9da587d1c6a64172792f505bafa250
Date: 2026-03-10T02:01:17.430Z
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.12.73+deb13-amd64

I asked ChatGPT for help, and it gave me a perfect answer. I ran the following commands:

sudo apt install apparmor-utils
sudo aa-complain /etc/apparmor.d/cursor-sandbox
sudo aa-complain /etc/apparmor.d/cursor-sandbox_remote
sudo aa-complain /etc/apparmor.d/cursor-sandbox_agent_cli
sudo systemctl reload apparmor

After this, the alert box never showed up again.

This has not been fixed upstream by Cursor yet? Wtf seriously

This is disappointing for someone who just installed Cursor for the first time today. Obviously, disabling the sandbox per @billdc is not an acceptable workaround. Is Ubuntu such a small subset of users that they can be overlooked? Will this problem be resolved before my 7-day trial period expires?

Same issue on Ubuntu 24.04

Version: 2.6.20
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-14-generic

Pretty dissapointing as a few versions ago it was working fine, so this seems like a regression. The latest fixes I kept downloading, hopeful that they may fix the issue, have not fixed it at all.

Encountering this on Arch Linux as well, same behaviour.

For Ubuntu, I’ve managed to fix it with some help from this other post (added the /etc/apparmor.d/cursor profile from that post) as well as ChatGPT to figure out what other permissions it was missing and ended up with this:

@@ -1,3 +1,5 @@
+abi <abi/4.0>,
+
 profile cursor_sandbox /usr/share/cursor/resources/app/resources/helpers/cursorsandbox {
   file,
   /** ix,
@@ -8,15 +10,21 @@
   capability setuid,
   capability setgid,
   capability setpcap,
+  capability dac_override,
 
   ## Uncomment this on AppArmor 4.0
-  #userns,
+  userns,
 
   mount,
   remount,
   umount,
 
   /usr/share/cursor/resources/app/resources/helpers/cursorsandbox mr,
+  network unix,
+  network inet stream,
+  network netlink raw,
+  signal send peer=cursor_sandbox,
+  signal receive peer=cursor_sandbox,
 }
 
 profile cursor_sandbox_remote /home/*/.cursor-server/bin/*/*/resources/helpers/cursorsandbox {
@@ -29,13 +37,19 @@
   capability setuid,
   capability setgid,
   capability setpcap,
+  capability dac_override,
 
   ## Uncomment this on AppArmor 4.0
-  #userns,
+  userns,
 
   mount,
   remount,
   umount,
 
   /home/*/.cursor-server/bin/*/*/resources/helpers/cursorsandbox mr,
+  network unix,
+  network inet stream,
+  network netlink raw,
+  signal send peer=cursor_sandbox_remote,
+  signal receive peer=cursor_sandbox_remote,
 }

Hey everyone, quick update: the fix should already be out. Just run apt update or reinstall the Cursor package, and it should be fixed automatically.

Not solved for me on Ubuntu 24.04, using the 0.5.0 Cursor apparmor file (after updating via apt, and restarting the server to be sure). Using latest Cursor nightly.