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
- Install Cursor IDE on Ubuntu 24.04 with AppArmor enabled (default).
- 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). - Let some commands hang or close Cursor IDE normally (without Force Quit).
- Reopen Cursor and/or run:
pgrep -c cursorsandbox
→ Observe high count (100+) of stalecursorsandbox --policy/--run-proxyprocesses. - Attempt cleanup as root:
sudo pkill -9 -f ‘cursorsandbox --policy’
→ “Permission denied” on each PID. - 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
- When Cursor IDE exits or restarts, all child
cursorsandboxprocesses should be reaped (no orphans under systemd --user). - If orphans exist, administrators should be able to terminate them with normal signals (kill/pkill), or Cursor should provide a supported cleanup command.
- 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