Hey, thanks for the thorough report. It’s really well structured and makes it easy to track the issue.
This is part of a broader set of Linux sandbox issues we’ve been tracking over the past few weeks. A couple related threads for context:
-
Terminal sandbox could not start
Deep dive into the root cause (NoNewPrivs inherited from Electron’s zygote process blockingunshare(CLONE_NEWUSER)) -
AppArmor cursor-sandbox profile incomplete
Details on profile gaps
Your case is especially interesting because it’s a clean regression between 2.6.12 and 2.6.13 on the same system. One thing I noticed is you have cursor-sandbox-apparmor in rc state (removed, but config files still on disk at /etc/apparmor.d/cursor-sandbox). Could you check a couple things?
- Is AppArmor actually active on your Debian 13?
cat /sys/module/apparmor/parameters/enabled
sudo aa-status | grep cursor
- Is that leftover profile loaded?
sudo aa-status 2>/dev/null | grep -i cursor
If it’s loaded, try removing it:
sudo apparmor_parser -R /etc/apparmor.d/cursor-sandbox
sudo rm /etc/apparmor.d/cursor-sandbox
Then restart Cursor and test again.
If AppArmor is active and restricting unprivileged user namespaces, a quick (less secure) workaround is:
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
I flagged this with the team as a possible regression in 2.6.13 specifically. No timeline yet, but your detailed version comparison helps with prioritization.
Let me know what AppArmor status shows.