Agent CLI: Linux sandbox preflight fails (unshare EPERM) unless run under strace; apparmor_restrict_unprivileged_userns=1

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Hi Cursor team,

I’m reporting a reproducible Linux issue with Cursor Agent CLI sandbox preflight on a shared Ubuntu-style host. It blocks normal agent sandbox run / workspace sandboxing, but the same command succeeds when wrapped in strace -f -o /dev/null. This
looks like an interaction between cursorsandbox, user namespaces, and AppArmor’s unprivileged-userns restriction, not a simple “kernel doesn’t support namespaces” problem.

Environment

• OS: Linux (shared cluster login node), user is not in sudoers.
• Cursor Agent CLI / cursorsandbox path (example):

~/.local/share/cursor-agent/versions/2026.05.07-42ddaca/cursorsandbox

• uname / distro: Linux iwashi 6.8.0-79-generic #79-Ubuntu SMP PREEMPT_DYNAMIC Tue Aug 12 14:42:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
• Agent version: 2026.05.07-42ddaca

Kernel / AppArmor

• sysctl kernel.unprivileged_userns_clone → 1
• /proc/sys/kernel/apparmor_restrict_unprivileged_userns → 1
• sysctl kernel.unprivileged_userns_apparmor_policy → (not present / empty on this kernel)

Control tests

• Manual Bubblewrap:

bwrap --unshare-user --ro-bind / / --proc /proc --dev /dev true → OK (namespaces work in principle from this user).

• Fails (preflight EPERM):

agent sandbox run --sb-debug -- ls -la
Error (abridged): Linux preflight exit 2; Landlock + Bubblewrap paths both fail at user namespace step: Failed to unshare namespaces: EPERM.

• Succeeds:

strace -f -o /dev/null agent sandbox run --sb-debug -- ls -la
→ exit 0, sandbox debug dirs created, command runs.

• Does not fix:

/usr/bin/time -v agent sandbox run --sb-debug -- ls -la → fails (so this is not explained by “generically slower”).

Namespace / AppArmor evidence (when run succeeds under strace)

From inside the sandbox wrapper (successful run):

• Host /proc/self/attr/current: unconfined
• Inside sandbox: cursor_sandbox_agent_cli (enforce)
• Host user ns inode vs inside: different (readlink /proc/self/ns/user changes)
• uid_map inside: 0 1348 1 mapping host UID to namespace root; id shows uid=0(root) inside userns.

So the success path is a real user namespace + expected AA profile, not a spurious exit code.

Ask

  1. Please treat this as a CLI / cursorsandbox preflight bug on systems with apparmor_restrict_unprivileged_userns=1, possibly involving profile attachment order vs userns_create, or an unintended sensitivity to ptrace (timing / task context).
  2. Guidance for shared HPC / locked-down hosts: recommended AppArmor policy knobs or a supported way to run Agent with reliable sandbox when this sysctl is on.

I can provide full strace excerpts, cursorsandbox paths, and stdout/stderr from debug dirs on request.

Steps to Reproduce

  1. On a Linux host where /proc/sys/kernel/apparmor_restrict_unprivileged_userns is 1 (and kernel.unprivileged_userns_clone is 1), install/use Cursor Agent CLI so it uses the bundled helper, e.g.

    ~/.local/share/cursor-agent/versions//cursorsandbox.

  2. From your normal user shell (not under strace), run:

    agent sandbox run --sb-debug – ls -la

  3. Observe the command fail during Linux sandbox preflight with an error like:

    Failed to unshare namespaces: EPERM (Landlock and Bubblewrap paths both reporting namespace setup failure), and a non-zero exit status.

  4. Without changing AppArmor/sysctl, run the same command under strace with trace output discarded:

    strace -f -o /dev/null agent sandbox run --sb-debug – ls -la

  5. Observe this succeeds: exit code 0, sandbox debug output under /tmp/cursor-sandbox-*, and normal “command success” messaging.

  6. (Optional control) Confirm namespaces work in principle for the user:

    bwrap --unshare-user --ro-bind / / --proc /proc --dev /dev true

    and that slowing the command without ptrace does not fix it, e.g.:

    /usr/bin/time -v agent sandbox run --sb-debug – ls -la

    still fails.

Expected Behavior

• agent sandbox run should consistently pass Linux sandbox preflight when the host allows unprivileged user namespaces under policy (as verified by independent checks such as bwrap … true succeeding and unprivileged_userns_clone=1).
• Behavior should not depend on whether the process tree is run under strace/ptrace (e.g. strace -f -o /dev/null should not be required for preflight to succeed).
• When the sandbox starts, the workload should run under Cursor’s intended confinement (e.g. AppArmor shows cursor_sandbox_agent_cli (enforce) inside the sandbox, with a new user namespace and sensible uid_map, e.g. 0 <host_uid> 1 for a
single-UID map)—and that same outcome should be achievable from a plain agent sandbox run invocation, not only under strace.

Operating System

Linux

Version Information

2026.05.07-42ddaca

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the report. The analysis and the repro tests really help because they cut out all the noise.

You’re right about the root cause. The AppArmor profile for the Agent CLI cursor_sandbox_agent_cli, which matches ~/.local/share/cursor-agent/versions/*/cursorsandbox, is shipped with userns commented out, the line #userns, for compatibility with AppArmor < 4.0. On AppArmor 4.0+ with apparmor_restrict_unprivileged_userns=1, a confined process must have an explicit userns rule to call unshare(CLONE_NEWUSER). Without it, the LSM hook userns_create returns EPERM. This is a known issue, same class as AppArmor cursor-sandbox profile incomplete on Linux — sandbox does not work correctly (missing network, signal, userns) and Linux: terminal sandbox preflight fails — `uid_map` EPERM after mitigations (earlier: loopback error).

Why strace -f makes the error go away. On newer Ubuntu kernels, ptraced processes go through a relaxed path in userns_create, so the AppArmor restriction is effectively bypassed. This isn’t a strace bug, and it’s not a timing thing. It’s just a side effect of the interaction between ptrace and the AppArmor hook.

For a workaround in your environment, shared HPC with no sudo. If you can’t edit /etc/apparmor.d/... and you can’t set sysctl kernel.apparmor_restrict_unprivileged_userns=0, there’s basically no user level workaround besides the strace wrapper you’re already using. If you can, ask the cluster admin to add userns, plus network, signal, dac_override if needed to the cursor_sandbox_agent_cli profile. A ready to use template with local includes and dpkg-divert is in post #10 of this thread AppArmor cursor-sandbox profile incomplete on Linux — sandbox does not work correctly (missing network, signal, userns) - #10 by gcespedes. You can hand it to the admin as-is, it includes the Agent CLI profile.

On our side, I’ve also reported this internally, specifically the Agent CLI userns gap since the existing AppArmor profile tickets don’t directly cover this case. I can’t share an ETA yet, but we’ll post an update here when we have one.

8

Hi there, thanks for your reply on this. Do you have any updates on this bug?

9

Issue report

Same identical situation here when upgraded to the new version of cursor with Linux Ubuntu Server 24.04. The reproduction of the test above confirm the same issue: AppArmor DENIED userns_create for cursorsandbox after latest update (Extension Host unresponsive).

Advisory

Please update the AppArmor profile distribution or ensure Electron sandbox flags are compliant with modern Linux kernel security policies (e.g., Ubuntu 24.04+ restrictions), as the current workarounds (like disabling the sandbox) introduce potential security risks and privilege escalation vulnerabilities.

Bug Description

After applying the latest update, Cursor UI opens but the Extension Host is completely unresponsive. The AI Agent fails with “The agent execution provider did not respond in time” and installing/reloading extensions (like Remote - SSH) enters an infinite loading loop.

This happens due to AppArmor restricting unprivileged user namespaces on Linux, blocking `cursorsandbox`.

System Information

  • OS: Linux (Kernel log attached below)
  • Cursor Version: Latest update as of May 15, 2026
  • Workaround tested: Launching with `–no-sandbox` or setting `kernel.apparmor_restrict_unprivileged_userns=0` resolves the issue temporarily.

Logs (dmesg / kern.log)

2026-05-15T07:43:29.198365+02:00 dev kernel: audit: type=1400 audit(1778823809.196:37865): apparmor=“AUDIT” operation=“userns_create” class=“namespace” info=“Userns create - transitioning profile” profile=“unconfined” pid=1819281 comm=“cursorsandbox” requested=“userns_create” target=“unprivileged_userns” 2026-05-15T07:43:29.204342+02:00 dev kernel: audit: type=1400 audit(1778823809.202:37869): apparmor=“DENIED” operation=“capable” class=“cap” profile=“unprivileged_userns” pid=1819286 comm=“cursorsandbox” capability=21 capname=“sys_admin”

10

Hey Billy, the update is still pretty small: the bug is tracked, but I don’t have a specific ETA for the fix. As soon as we have a timeline update or the profile fix ships, we’ll post it here.

If you can nudge the cluster admins, an AppArmor profile template with userns, plus network, signal, dac_override is in post #10 here AppArmor cursor-sandbox profile incomplete on Linux — sandbox does not work correctly (missing network, signal, userns) - #10 by gcespedes. You can hand it to them as-is, it also covers the Agent CLI profile. Without that, on shared HPC without sudo, the strace wrapper is still the only user-side workaround.

@Stefano_Monti thanks for the report. From the logs it’s the same class of issue: the shipped AppArmor profile is missing the userns, rule, so on Ubuntu 24.04+ with apparmor_restrict_unprivileged_userns=1, the userns_create request falls back to the unprivileged_userns profile and fails on capable sys_admin. Since you have root, here are temporary workarounds:

  • sysctl kernel.apparmor_restrict_unprivileged_userns=0 to remove the restriction globally, as you noted this is a security regression
  • better: add a local override in /etc/apparmor.d/local/ for the cursor_sandbox* profiles with userns, and the needed network and signal rules, same template from the link above. This keeps confinement, it just closes the gap
  • --no-sandbox on the main IDE disables the sandbox entirely, I wouldn’t recommend that as a long-term solution
11

Hi there, thanks for the update. Just wanted to bump this up again to get the Cursor team’s attention on an ETA for this bug. The cluster admins are reluctant to change the apparmor profile so we are currently using it without sandbox (not ideal) or use Codex which plays a little nicer with bwrap. I’d much rather use Cursor because of various advantages it has in coding. Thanks again!

12

Hey Billy, thanks for coming back with an update from your side.

Honestly, there’s no update on the fix yet. The ticket is still in the tracker, but I can’t share a specific ETA. I don’t want to promise a timeline I don’t have.

The fact that you’re switching to --no-sandbox or Codex is a real signal of impact, and I called that out to the engineers separately.

For now, the options are still the same:

As soon as a profile with userns, uncommented ships, or we get movement on the timeline, I’ll reply in the thread.