How to fix Cursor's Terminal sandbox error on Linux (AppArmor)

TL;DR: Run sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0, then persist it in /etc/sysctl.d/99-cursor.conf - don't chmod the sandbox binary, that fix makes it worse.

Cursor's Terminal panel on Linux fails to start with "Terminal sandbox could not start. This may be caused by an AppArmor configuration on your Linux system (kernel 6.2+)." It hits Ubuntu 24.04 LTS, Zorin OS 18, Arch Linux, Fedora, and Amazon Linux 2023 - anywhere the kernel enforces AppArmor's unprivileged user namespace restriction. Cursor's own troubleshooting guide doesn't mention it yet, so most people either give up on the integrated terminal or apply a fix that backfires.

What causes the Cursor terminal sandbox error on Linux?

Cursor's terminal runs commands through a helper binary called cursorsandbox, which needs to create an unprivileged Linux user namespace via unshare(CLONE_NEWUSER). Ubuntu started restricting that syscall by default in 23.10 and kept it in 24.04 LTS, guarding it behind AppArmor profiles under the sysctl kernel.apparmor_restrict_unprivileged_userns. Other distros on kernel 6.2+ (Fedora, Arch, Amazon Linux 2023) ship the same kernel-level restriction through their own AppArmor or SELinux policies.

Cursor's shipped AppArmor profile doesn't grant cursorsandbox the exception it needs, so the namespace creation is denied and the terminal panel refuses to open. A user diagnosing the failure on the Cursor community forum traced it further: cursorsandbox inherits the NoNewPrivs flag from Electron's zygote process, which blocks the unshare call independent of whether AppArmor is even enforcing anything at that moment. The underlying kernel error, visible in journalctl or Cursor's Output panel, is Failed to write /proc/self/uid_map (mapping UID 0 -> 1000): Operation not permitted.

How do you fix the Cursor terminal sandbox error on Ubuntu 24.04+?

Disable the AppArmor unprivileged-namespace restriction for Cursor's sandbox process, then make it persistent:

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
echo "kernel.apparmor_restrict_unprivileged_userns=0" | sudo tee /etc/sysctl.d/99-cursor.conf
sudo sysctl --system

The first command takes effect immediately - reopen Cursor's terminal panel and it should start. The second and third commands write the setting to a config file so it survives a reboot; without them the sandbox breaks again on next login. Restart Cursor completely (not just "Reload Window") after running these so the sandbox helper re-initializes.

Why does chmod 4755 on cursorsandbox make it worse?

The most commonly repeated workaround online is running chmod 4755 on the cursorsandbox binary to set the setuid bit, on the theory that root privileges will bypass the namespace restriction. It does the opposite. Setuid makes the process start as root, and a process that's already root cannot legally remap itself to UID 1000 inside a user namespace - the same uid_map write that failed before now fails for a different reason. If you already applied this fix, undo it before trying the sysctl fix:

sudo chmod 755 $(which cursorsandbox 2>/dev/null || find / -name cursorsandbox 2>/dev/null | head -1)

Is disabling apparmor_restrict_unprivileged_userns safe?

It's a real tradeoff, not a free lunch. Ubuntu's own security documentation explains that the restriction exists specifically to reduce the attack surface unprivileged user namespaces expose - several container-escape and privilege-escalation exploits chain through unrestricted namespace creation. Disabling it system-wide re-opens that surface for every unprivileged process, not just Cursor.

If you only use the machine for local development and accept that tradeoff, the sysctl change is the documented, reversible path - flip it back to 1 and delete the sysctl.d file to restore the default. If you manage a shared or hardened machine, scope the exception to Cursor's AppArmor profile instead of a system-wide sysctl flip; that requires editing the profile under /etc/apparmor.d/ to explicitly permit cursorsandbox to create user namespaces, which is more work but doesn't loosen the restriction for every other process.

Does this affect Fedora, Arch, and other distros?

Yes. The forum reports list kernel 6.17.0-14-generic (Ubuntu) and 6.18.9-arch1-local (Arch) hitting the identical error, alongside Fedora and Amazon Linux 2023. The trigger is the kernel-level unprivileged-namespace restriction, not an Ubuntu-specific patch - any distro on kernel 6.2+ that enables the equivalent AppArmor or kernel hardening policy can reproduce it. The exact sysctl name and default value vary by distro; check with sysctl kernel.apparmor_restrict_unprivileged_userns before assuming the fix above applies verbatim.

As of early March 2026 the Cursor team had acknowledged the bug on the forum and "bumped the priority internally," with no fix ETA. Until Cursor ships a corrected AppArmor profile, the sysctl workaround is the fastest path back to a working terminal. Check the Automation Error Index for other Cursor and Linux sandboxing errors as they get documented.

FAQ

What does "Terminal sandbox could not start" mean in Cursor?

It means Cursor's cursorsandbox helper failed to create an unprivileged Linux user namespace, usually because AppArmor's kernel.apparmor_restrict_unprivileged_userns restriction is blocking it and Cursor's shipped AppArmor profile lacks the needed exception.

Is disabling the AppArmor userns restriction safe?

It removes a hardening layer that Ubuntu enabled by default specifically to reduce container-escape and privilege-escalation attack surface. It's reasonable on a personal dev machine; on a shared or hardened server, scope the exception to Cursor's AppArmor profile instead of disabling the sysctl system-wide.

Does this happen on Fedora or Arch too?

Yes - the same error has been reported on Arch Linux (kernel 6.18.9-arch1-local) and Fedora, since the root cause is the kernel 6.2+ unprivileged-namespace restriction, not an Ubuntu-only patch. The sysctl name may differ, so verify it before applying the fix.

Does chmod 4755 on cursorsandbox fix the error?

No - it makes the failure worse. Setuid forces the sandbox to start as root, and root cannot remap itself to a lower UID inside a user namespace, so the same uid_map write fails for a different reason. Revert the permission to 755 before applying the sysctl fix.

Is there an official fix from Cursor yet?

Not as of early March 2026. The Cursor team acknowledged the bug on the community forum and raised its internal priority, but hasn't shipped a corrected AppArmor profile. The sysctl workaround is the documented interim fix.

Which Cursor versions are affected?

Reports confirm Cursor 2.5.25 and 2.5.26 on kernel 6.2+ systems. The bug is tied to the sandbox binary's AppArmor profile rather than a specific Cursor release, so it likely persists across versions until Cursor patches the profile.