Sandboxed Bash fails at apply-seccomp on Ubuntu 24.04 (apparmor_restrict_unprivileged_userns=1): nested userns is capability-restricted

Environment

• Claude Code: 2.1.263 (native CLI). The failing code is Claude Code's **bundled

second-stage sandbox init**: the apply-seccomp: strings below are present in
the claude binary itself, while the system bubblewrap (0.9.0-1ubuntu0.1)
contains none of them. Mount namespace construction (deny mounts, tmpfs,
/proc, ...) completes first; the in-namespace init then fails.

• OS: Ubuntu 24.04, kernel 6.8.0-139-generic
• kernel.apparmor_restrict_unprivileged_userns = 1 (Ubuntu 24.04 default

hardening; user is unconfined, no profile attaches to the claude binary)

Observed

Every sandboxed Bash command dies after mount construction, at seccomp setup:

apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN)

• Confirmed in the user's own terminal: sandboxed git status fails at

apply-seccomp, reproducibly, in every project on this machine.

• Present in 25 recorded local session transcripts across 6 independent

projects; earliest occurrence 2026-09-02. No apt/dpkg event maps to the onset
(the restriction is simply the stock 24.04 default).

• Net effect: sandboxed execution is entirely unavailable on this system.

With allowUnsandboxedCommands: true, sessions surface the error and fall
back to unsandboxed execution behind permission prompts - so it is easy to
believe sandboxing is active when it is not. With
allowUnsandboxedCommands: false, every Bash call would fail outright.

Analysis

With unprivileged user namespaces restricted by AppArmor policy, the sandbox's
user namespace is created, but the subsequent in-namespace write to
/proc/self/setgroups (part of applying Claude Code's own seccomp filter) is
denied to an unconfined, capability-less caller. Other sandboxed apps ship an
AppArmor profile attached to their binary to punch exactly this scoped hole
(Chrome/Firefox on 24.04); Claude Code currently ships no such profile.

Suggested fix

1. Ship an AppArmor profile for the claude binary that grants user

namespace creation (a userns, rule), installed and loaded at boot,
following the established Chrome/Firefox pattern on Ubuntu 24.04.

1. Detect and diagnose at startup (or first sandbox use): check

kernel.apparmor_restrict_unprivileged_userns and whether a profile
attaches to the binary, and emit one clear diagnostic - e.g.
"sandbox unavailable: AppArmor userns restriction; install profile X / see
docs" - instead of a per-command error string that is only visible when
surfaced to a model.

1. Document the requirement in the sandbox docs.

Please do not propose sysctl kernel.apparmor_restrict_unprivileged_userns=0
as the remedy - it drops the hardening machine-wide; the attached profile is
the scoped fix.

Happy to test a candidate profile.