Sandbox processes persist after Cursor exit and cannot be killed by user

Support Bug Reports
, ,
1

⛬ Where does the bug appear (feature/product)?

[x] Cursor IDE

Describe the Bug

Cursor’s cursorsandbox processes can become orphaned, holding locks on project files and preventing builds. These processes persist even after fully quitting Cursor and cannot be terminated by the user without root privileges, forcing a reboot to recover.

The sandbox processes run in a Linux user namespace with UID 0 (root) inside, mapped to the regular user outside. Due to kernel security restrictions, signals cannot cross user namespace boundaries to namespace-privileged processes. This means kill -9
returns “Permission denied” even though ps shows the process owned by the current user.

Steps to Reproduce

  1. Run sandbox tasks in Cursor (e.g., build commands)
  2. Cancel tasks or experience a hang
  3. Quit Cursor completely
  4. Attempt to build the project outside Cursor - fails due to locked files
  5. Observe orphaned cursorsandbox processes via ps aux | grep cursorsandbox
  6. Attempt kill -9 - fails with permission denied

Expected Behavior

• Sandbox processes should be terminated when Cursor exits
• Cancelled tasks should release file locks immediately
• If user namespace isolation is used, the parent process should ensure cleanup before exit

Screenshots / Screen Recordings

N/A

Operating System

[x] Linux

Ubuntu 24.04.4 LTS, kernel 6.8.0-111-generic

Version Information

IDE: 
Version: 3.2.21 
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720 
Arch: x64

For AI issues: which model did you use?

N/A - not an AI issue

Additional Information

Workaround: sudo pkill -9 -f cursorsandbox

Does this stop you from using Cursor?

[x] Yes - Cursor is unusable

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

6

⛬ Additional finding and how I fixed it without reboot:

The root cause is Cursor’s AppArmor profile (/etc/apparmor.d/cursor-sandbox) which grants capability sys_admin to the sandbox processes. This makes orphaned processes immune to kill -9 even from
root.

Workaround:

bash
sudo aa-complain /etc/apparmor.d/cursor-sandbox
sudo kill -9 $(pgrep -f cursorsandbox)
sudo aa-enforce /etc/apparmor.d/cursor-sandbox

This temporarily puts the AppArmor profile in complain mode, kills the processes, then re-enables enforcement.

Note: apparmor-utils package is required (sudo apt install apparmor-utils).

8

Hey @LailokenWork!

Thanks for the feedback! Has also been discussed over here:

And we raised a bug ticket. Will attach your report as well!