Critical Governance Issue: cursor_sandbox and Seccomp blocking Root/Sudo kill signals (EACCES)

[Saa_Free]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Processes spawned within the cursor_sandbox (likely by AI Agent or integrated terminal) become “immortal.” Even with root / sudo privileges on the host machine, sending SIGKILL or SIGTERM results in “Permission denied” (EACCES).

The sandbox uses a Seccomp profile (Seccomp: 2) and an LSM attribute (cursor_sandbox (enforce)) that effectively locks out the host’s root user from managing the process. This leads to “ghost processes” hanging on ports (e.g., port 3000) that cannot be cleared without a hard Kernel intervention via SysRq.

Steps to Reproduce

1/ Start a long-running process (like next dev) using the Cursor AI Agent or the integrated terminal.

2/ Ensure the process is running under cursor_sandbox (enforce) (check /proc/[PID]/status).

3/ Open a standard external terminal. Or Cursor terminal.

4/ Attempt to kill the process: sudo kill -9 [PID] or sudo pkill -f “next dev”.

5/ Observe the error: bash: kill: (PID) - Permission denied.

Expected Behavior

The host machine’s root/sudo user should always maintain “Runtime Sovereignty.” Any process spawned by the IDE should be terminable by the system administrator or the owner of the hardware without requiring an IDE restart or a Kernel SysRq trigger.

Operating System

Linux

Version Information

Cursor
/usr/bin/cursor
3.1.14 (commit d8673fb56ba50fda33ad78382000b519bb8acb70, x64)

(IDE Version: 3.1.14
VSCode Version: 1.105.1
Commit: d8673fb56ba50fda33ad78382000b519bb8acb70
Date: 2026-04-14T01:39:23.679Z
Layout: editor
Build Type: Stable
Release Track: Nightly
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.14.0-28-generic)

Additional Information

OS: Linux 24.04 LTS (Ubuntu/Debian based)

Kernel Security: Seccomp enabled, AppArmor/LSM enforcing cursor_sandbox.

Impact: Critical. Prevents port reclamation and resource management in professional dev workflows.

Workaround used: Had to force a kernel-level kill using echo i > /proc/sysrq-trigger, which is highly disruptive.

Diagnostics Log:

Evidence of the lockdown:

Name: next-server
Uid: 1000 1000 1000 1000
Seccomp: 2
attr/current: cursor_sandbox (enforce)

Result of kill attempt:

root@minhlap:~# kill -9 3407703
bash: kill: (3407703) - Permission denied

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Saa_Free]

This is the log:

bash-5.2$ ss -tlnp | grep ':3000 ’ LISTEN 0 511 :3000 :* users:((“next-server (v1”,pid=3407703,fd=22))

bash-5.2$ pkill -TERM -f “next dev” pkill: killing pid 3407679 failed: Permission denied pkill: killing pid 3407680 failed: Permission denied

bash-5.2$ pkill -9 -f “next dev” pkill: killing pid 3407679 failed: Permission denied pkill: killing pid 3407680 failed: Permission denied

bash-5.2$ kill -9 3407703 bash: kill: (3407703) - Permission denied

bash-5.2$ fuser -k 3000/tcp 3000/tcp: 3407703 Could not kill process 3407703: Permission denied

bash-5.2$ pkill -9 -f “next-server” pkill: killing pid 3407703 failed: Permission denied

bash-5.2$ ss -tlnp | grep ':3000 ’ LISTEN 0 511 :3000 :* users:((“next-server (v1”,pid=3407703,fd=22))

bash-5.2$ PID=$(ss -tlnp | grep ':3000 ’ | grep -o ‘pid=[0-9]*’ | head -1 | cut -d= -f2) echo “PID=$PID” grep -E ‘^(Name|Uid|Seccomp):’ “/proc/$PID/status” cat “/proc/$PID/attr/current” PID=3407703 Name: next-server (v1 Uid: 1000 1000 1000 1000 Seccomp: 2 cursor_sandbox (enforce)

bash-5.2$ kill -0 “$PID” 2>&1 || true bash: kill: (3407703) - Permission denied

bash-5.2$

[mohitjain (Mohit)]

Hi @Saa_Free,

Thanks for the detailed report with the diagnostic logs. We’ve been able to reproduce the issue on a similar setup (Ubuntu 24.04 LTS, kernel 6.14, AppArmor enforcing) and confirmed that sandboxed processes cannot be killed from outside the sandbox, even by root.

On Ubuntu 24.04+ with newer kernel security features, the security profile applied to sandboxed processes blocks signal delivery from outside the sandbox boundary, including from root. This has been escalated to our engineering team.

To reclaim the port and kill the stuck process, try these workarounds (in order of least disruption):

1. Kill the parent sandbox wrapper (runs in the host namespace, so it’s killable):

   pkill -9 bwrap

   Or find the specific parent PID first: pgrep -a bwrap

2. Close the terminal tab in Cursor that started the process. Sandboxed processes are configured to terminate automatically when their parent dies.

3. Enter the namespace to send the signal:

   sudo nsenter -t <PID> -U -m kill -9 <PID>

4. Restart Cursor entirely. All sandboxed child processes will be cleaned up on exit.

If you want to prevent this from happening entirely, you can disable the sandbox: go to Cursor Settings > Agents and turn off Sandbox mode. This removes the isolation layer, but you’ll be able to manage processes normally from outside Cursor.

Our team is actively working on sandbox compatibility improvements for Linux, especially around Ubuntu 24.04+ and its newer security policies. Your report is helpful here.

Let me know if the bwrap workaround resolves the immediate port issue!

[Saa_Free]

@mohitjain

Let me know if the bwrap workaround resolves the immediate port issue!

Hi,

Actually, just ran into this again today.

But this time the IDE suggestion to kill the PID worked perfectly. Didn’t have to use sudo or anything, unlike my first report.

Seems like it’s behaving better for now. If I see another ‘unkillable’ ghost process I’ll try the bwrap command and let you know.
Thanks!

[v_frolov]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor starts agent shell tool calls via:
/usr/share/cursor/resources/app/resources/helpers/cursorsandbox

A tool call got stuck. The process was owned by my user, but sudo kill failed:
sudo kill
kill: (): Permission denied

Process details:

• AppArmor: cursor_sandbox (enforce)
• NoNewPrivs: 1
• Seccomp: 2
• uid_map: 0 1000 1
  /proc//attr/current:
  cursor_sandbox (enforce)

The command inside the sandbox was just:
helm show values oci://registry-1.docker.io/bitnamicharts/kube-prometheus --version 11.3.10

Workaround:
Add to /etc/apparmor.d/cursor-sandbox profiles:
signal (receive) peer=unconfined,
Then reload:
sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox

After that sudo kill works.

Steps to Reproduce

1. Use Cursor on Linux with AppArmor enabled.
2. Trigger any long-running or stuck agent shell tool call, for example a command that hangs inside Cursor’s shell tool execution.
3. Find the spawned Cursor sandbox helper process:
   ps aux | grep ‘[c]ursorsandbox’
4. Confirm it is confined by AppArmor:
   cat /proc//attr/current
   Output:
   cursor_sandbox (enforce)
5. Try to terminate it as root:
   sudo kill -TERM
6. Observe that kill fails with:
   kill: (): Permission denied

Expected Behavior

The machine owner/root user should always be able to terminate a local Cursor sandbox helper process

Operating System

Linux

Version Information

Version: 3.2.21
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
Layout: editor
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-23-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Saa_Free]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On Ubuntu 24.04 with AppArmor enforced, orphaned cursorsandbox processes accumulate over time (100–175+ in my case). They survive normal Cursor IDE exit/restart (reparented to systemd --user).

These orphans cannot be terminated with kill -9 or pkill — even as root. Kernel audit logs show AppArmor denies the signal:

apparmor=“DENIED” operation=“signal” profile=“cursor_sandbox”
signal=kill peer=“unconfined”

Profile: /etc/apparmor.d/cursor-sandbox (shipped/installed with Cursor). The profile does not allow unconfined peers (including root pkill) to send signals to cursorsandbox processes, and Cursor does not reap orphans when the IDE closes.

Impact:

• Cursor warns “agent still running” when quitting
• Process leak over multi-day sessions (oldest orphans > 1.5 days)
• No standard admin cleanup path without unloading the AppArmor profile first

This appears related to a prior sandbox fix on Linux; the orphan lifecycle + signal policy gap remains (possible regression).

Steps to Reproduce

1. Install Cursor IDE on Ubuntu 24.04 with AppArmor enabled (default).
2. Open a workspace and run Agent tasks that execute shell commands in the sandbox (especially long-running or piped commands, e.g. rg -l PATTERN | xargs sed -i ... across a large repo).
3. Let some commands hang or close Cursor IDE normally (without Force Quit).
4. Reopen Cursor and/or run: pgrep -c cursorsandbox
   → Observe high count (100+) of stale cursorsandbox --policy / --run-proxy processes.
5. Attempt cleanup as root:
   sudo pkill -9 -f ‘cursorsandbox --policy’
   → “Permission denied” on each PID.
6. Confirm AppArmor denial:
   journalctl -k | grep cursor_sandbox | tail -5
   → operation="signal" ... denied_mask="receive" ... peer="unconfined"

Workaround that works:
sudo apparmor_parser -R /etc/apparmor.d/cursor-sandbox
sudo pkill -9 -f cursorsandbox
sudo apparmor_parser -r /etc/apparmor.d/cursor-sandbox

Expected Behavior

1. When Cursor IDE exits or restarts, all child cursorsandbox processes should be reaped (no orphans under systemd --user).
2. If orphans exist, administrators should be able to terminate them with normal signals (kill/pkill), or Cursor should provide a supported cleanup command.
3. AppArmor hardening should not make orphaned sandboxes immortal — either allow controlled cleanup signals or ensure orphans never outlive their parent Cursor session.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Cursor IDE: 3.4.20
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Build date: 2026-05-15T02:26:10.351Z

OS: Ubuntu 24.04.4 LTS
Kernel: 6.14.0-28-generic
AppArmor: enforced (profile cursor_sandbox on /usr/share/cursor/resources/app/resources/helpers/cursorsandbox)

For AI issues: which model did you use?

N/A — infrastructure / sandbox / AppArmor issue, not model-specific.
(Agent used various models; bug reproduces regardless of model.)

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Observed orphan PIDs reparented to systemd --user (not Cursor main process), so IDE restart does not clear them.

Example stuck command that triggered a long-lived orphan pipeline:
rg -l ‘olce_core_41’ | xargs -r sed -i ‘s/olce_core_41/olce_core_full/g’
(rg/xargs deadlocked in sandbox proxy; wrapper processes remained for 10+ hours)

Confirmed fix on my machine (175 → 0):
Unload AppArmor profile → pkill → reload profile.

Suggested fixes for Cursor team:

• Reap all sandboxes on IDE shutdown / session end
• Detect and kill stale sandboxes on startup if parent is gone
• AppArmor: allow signal from unconfined for teardown, OR run a setuid/helper inside profile to reap orphans
• Avoid pipe deadlocks leaving zombie sandbox trees

Happy to provide full journalctl -k excerpts or test a patched build.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[Satya_Bodapati]

Cursor exited, but I had these cursor sandboxes running, and I couldn’t kill them using the above workarounds (bwrap etc). The only that worked for me:

sudo apt install apparmor-utils
sudo aa-enforce /etc/apparmor.d/cursor-sandbox

ERROR: Conflicting profiles for cursor_sandbox_remote defined in two files:

• /etc/apparmor.d/cursor-sandbox

• /etc/apparmor.d/cursor-sandbox-remote

  I renamed the /etc/apparmor.d/cursor-sandbox-remote to /etc/apparmor.d/cursor-sandbox-remote.backup

  then tried:
  sudo aa-complain /etc/apparmor.d/cursor-sandbox
  Setting /etc/apparmor.d/cursor-sandbox to complain mode.

  sudo killall -9 cursorsandbox

[mohitjain (Mohit)]

@Saa_Free — thanks for the follow-up. The orphan accumulation pattern you’re describing (100+ processes surviving IDE exit, reparented to systemd --user) is a more severe variant of the original issue. We’ve updated the bug report with your details, including the pipe-command deadlock trigger. Our team is aware.

Your workaround (unload AppArmor profile → kill → reload) is the cleanest approach that maintains security enforcement.

@Satya_Bodapati - thanks for sharing this. One important note: aa-complain switches the profile to complain mode, which logs but no longer blocks restricted operations. After killing the stuck processes, restore enforcement:

sudo aa-enforce /etc/apparmor.d/cursor-sandbox

The conflicting profiles error you hit between cursor-sandbox and cursor-sandbox-remote is useful - we’ll check whether the packaging creates this conflict on clean installs.

[Colin]

Hey @Saa_Free,
The issue with sandboxed processes being unkillable by root on Ubuntu 24.04+ was fixed in a recent Cursor update. Updating to the latest version should resolve this . Let me know if you still hit it!

cc @v_frolov @Satya_Bodapati

[shiltian (Shilei Tian)]

I still have the exact same issue, even though I’m using the latest version of Cursor IDE.