Linux: terminal sandbox preflight fails — `uid_map` EPERM after mitigations (earlier: loopback error)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Linux: terminal sandbox preflight fails — uid_map EPERM after mitigations (earlier: loopback error)

Mitigations applied from (did not resolve the issue):
Terminal sandbox fails on first start in 2.5.26: “loopback: failed to look up lo interface”
(Cursor staff reply: AppArmor profile cursor-system, remove stale cursor_sandbox, chmod 4755 on cursorsandbox.)

Summary

The terminal sandbox does not start. The UI shows: “Terminal sandbox could not start… AppArmor (kernel 6.2+)”. After applying the mitigations from the forum thread above, the problem remains; the error in the log changed from loopback to user namespace / uid_map.

Environment

  • OS: Linux (Ubuntu family), kernel: 6.17.0-19-generic
  • Cursor: .deb install under /usr/share/cursor/
  • Already verified: CONFIG_SECURITY_LANDLOCK=y, CONFIG_USER_NS=y, kernel.unprivileged_userns_clone=1, user.max_user_namespaces is non-zero
  • kernel.apparmor_restrict_unprivileged_userns=1

What we observed

1. Initially

In ~/.config/Cursor/logs/<session>/window1/exthost/exthost.log, preflight for cursorsandbox --preflight-only failed with:

Step 2.5/7 (loopback setup) failed: loopback: failed to look up lo interface

Host interface lo exists and is UP; the UI still shows the generic AppArmor hint.

2. After mitigations + Cursor restart

Same log location; new error:

Step 1-2/7 (user namespace) failed: Failed to write /proc/self/uid_map (mapping UID 0 -> 1000): Operation not permitted (os error 1) (errno 1)

Preflight no longer fails at the loopback step; it fails earlier, on writing /proc/self/uid_map.

Steps taken (no resolution)

Following the forum thread linked at the top:

  1. Added AppArmor profile /etc/apparmor.d/cursor-system for /usr/share/cursor/cursor with userns, loaded with:

    sudo apparmor_parser -r /etc/apparmor.d/cursor-system

  2. Checked for stale cursor_sandbox:

    sudo aa-status | grep cursor

    If present, removed/reloaded per forum instructions (apparmor_parser -R, rm, systemctl restart apparmor).

  3. Set setuid on the sandbox helper:

    sudo chmod 4755 /usr/share/cursor/resources/app/resources/helpers/cursorsandbox

    (cursorsandbox shows rwsr-xr-x, owned by root.)

  4. Restarted Cursor (and AppArmor where applicable).

Result: Sandbox still unsupported; preflight still fails with the uid_map / EPERM message above.

Expected

Sandbox preflight succeeds; no persistent “terminal sandbox could not start” warning.

Actual

Preflight fails; terminal sandbox does not start; only fallback behavior.

Logs

  • Path pattern: ~/.config/Cursor/logs/<session>/window1/exthost/exthost.log
  • Search for: [shell-exec:sandbox], Preflight failed

Optional (fill in when filing)

  • Cursor version: Help → About
  • Distro: e.g. Ubuntu 24.04 + exact point release

Steps to Reproduce

Launch the Cursor IDE. Error message about starting a sandbox for terminal appears.

Screenshots / Screen Recordings

Operating System

Linux

Version Information

Version: 2.6.21
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
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-19-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the detailed report. This is a known issue on Linux with kernel 6.2+ and AppArmor. It affects a lot of users on Ubuntu 24.04+. Full thread here: Terminal Sandbox Issue Linux.

First, the specific error uid_map (mapping UID 0 -> 1000) is caused by chmod 4755 on cursorsandbox. Setuid makes the binary run as root, and the kernel blocks the mapping. Set it back to normal permissions:

sudo chmod 0755 /usr/share/cursor/resources/app/resources/helpers/cursorsandbox

This will remove the current error, but it will likely bring back the previous one loopback or unshare EPERM. The sandbox itself might still not work yet.

Next depends on what exactly is being blocked on your system. Please share the output of:

sudo journalctl -k -b | grep -iE 'apparmor="DENIED".*cursor' | tail -n 30

If you see AppArmor denials, there are community workarounds that helped some users, like adding missing rules to the AppArmor profile. But to be honest, on some setups the issue is deeper, related to how Electron spawns the sandbox process, and AppArmor fixes don’t help.

As a fallback, the most reliable workaround right now is:

echo 'kernel.apparmor_restrict_unprivileged_userns=0' | sudo tee /etc/sysctl.d/99-userns.conf
sudo sysctl --system

This removes the userns restriction system-wide. It’s not ideal for security, but it’s been the most stable fix.

The team is aware of the issue, but there’s no timeline yet. Let’s start with the journalctl output, and then we can see what makes sense for your case.

5

Thank you for reply. Just changing the permissions back was enough:

sudo chmod 0755 /usr/share/cursor/resources/app/resources/helpers/cursorsandbox

The error message does not appear anymore and in the logs I can see:

2026-03-27 12:15:55.356 [info] [ExtHostShellExec] Sandbox support detected: true, platform: linux, kernelVersion: 6.17.0-19-generic
2026-03-27 12:15:55.370 [info] [ExtHostShellExec] Initializing terminal executor with userTerminalHint: /usr/bin/bash

Hopefully all is fine now, thank you for your help.

1 Like