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

Support Bug Reports
, ,
1

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

5

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$

8

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!

9

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!

11

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