[BUG] apply-seccomp fails on Linux - cannot write /proc/self/setgroups

I'm having the same issue.

To get functional again, I needed to reinstall an older version: $ claude install 2.1.91

Does Anthropic even test the sandbox?

The issue is that the built-in apply-seccomp file lacks execution permissions.

node_modules/@anthropic-ai/claude-code/vendor/seccomp/{your-arch}/apply-seccomp

For example, on macOS homebrew:
sudo chmod +x /opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/*/apply-seccomp

For Linux:
sudo chmod +x /usr/local/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/*/apply-seccomp
(or under /usr/bin/...)

Previously, ripgrep made this exact same mistake, yet here we are seeing the same error repeated.

The issue is that the built-in apply-seccomp file lacks execution permissions.

With the NPM install, it appears to be true that apply-seccomp isn't set to executable, that isn't the cause of the CAP_SYS_ADMIN error we're focused on here. Also the native install method (rather than npm) doesn't appear to have the permission issue. The apply-seccomp call is executing, but hitting an error.

I'm guessing this is because Ubuntu has extra restrictions on unprivileged user namespaces: https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#p-99950-unprivileged-user-namespace-restrictions-15

[  154.360212] audit: type=1400 audit(1775844482.839:321): apparmor="DENIED" operation="capable" class="cap" profile="unpriv_bwrap" pid=3458 comm="apply-seccomp" capability=21  capname="sys_admin"

However, the command in that thread to disable that restriction (echo 0 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns) did _not_ work for me: I get the same error after running it.

Disabling AppArmor entirely via kernel cmdline did get the sandbox to start, but that severely reduces Ubuntu's security, so I don't want to do that.

(Also, I believe the change that introduced the nested user namespaces in the sandbox was https://github.com/anthropic-experimental/sandbox-runtime/commit/7ee4ac602d18d7261c6d4db77014b2bc2617cb60)

Anthropic has now released a broken version to the "stable" channel, so I had to turn off auto-update to keep the last working version 2.1.91. I worked with claude extensively to try and find a workaround that didn't involve disabling apparmor or disabling the claude sandbox, and ultimately failed to find anything that worked.

Can you confirm it works for you if you uninstall socat? See #49018

The only real workaround that I found:
1) Install via npm: npm install -g @anthropic-ai/claude-code@latest
2) Fix executable bit: chmod +x <npm-prefix>/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp
3) Comment out capability deny in /etc/apparmor.d/bwrap-userns-restrict:
# audit deny capability,
4) Reload: sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict
5) Rename binary: mv ~/.local/bin/claude ~/.local/bin/claude-native-backup

Warning - this allows capabilities for all bwrap-sandboxed processes (Flatpak, etc.) within their user namespace

Still waiting for the real fix

Can you confirm it works for you if you uninstall socat? See #49018

The issue only seems to go away if I uninstall socat, which is equivalent to disabling the sandbox because it's a missing dependency. The /doctor command indicates sandbox disabled.

Confirmed on Ubuntu 24.04 LTS, kernel 6.17.0-20-generic (npm install)

Why 2.1.91 "works" on my system: socat is not installed. Without socat, 2.1.91 skips the sandbox entirely — Bash runs unsandboxed (Seccomp: 0, no user namespace). This is not a fix, just the sandbox being absent.

Why 2.1.92+ breaks even without socat: The new apply-seccomp helper is called regardless of socat availability. It attempts to write /proc/self/setgroups inside a user namespace, which fails with CAP_SYS_ADMIN denied because apparmor_restrict_unprivileged_userns=1 (Ubuntu 24.04 default).

So the regression is: 2.1.91 had a dependency (socat) that gracefully degraded to no sandbox. 2.1.92+ ships its own binary that fails fatally with no fallback on AppArmor-restricted systems.

Staying on 2.1.91 (unsandboxed) with auto-update disabled until this is fixed.

I seem to be hitting the same issue on 2.1.116. I set allowAllUnixSockets: true for now, which has solved it.

Please make Claude with sandbox usable again. Still stuck to 2.1.87 because of this and #43713.

ChatGPT gave me this working workaround for Claude 2.1.121 on Ubuntu 25.10, I think it weakens sandbox a bit but not sure exactly by how much:

~/.claude/settings.json

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowAllUnixSockets": true
    }
  }
}

Also getting hit by this one with: Claude Code 2.1.126, Ubuntu 25.10, kernel 6.17.0-22-generic

Check if you have other apparmor profiles interfering with the bwrap profile.

For example, unpriv_bwrap is a profile declared by Lutris:

/etc/apparmor.d/usr.bin.lutris

Its audit deny capability cannot be overridden by local/unpriv_bwrap (apparmor deny rules always take precedence over allow rules), but at least you can monkeypatch the file (and file an issue against lutris):

profile unpriv_bwrap flags=(attach_disconnected,mediate_deleted) {
  # not allow all, to allow for pix stack
  allow file rwlkm /{**,},
  allow network,
  allow unix,
  allow ptrace,
  allow signal,
  allow mqueue,
  allow io_uring,
  allow userns,
  allow mount,
  allow umount,
  allow pivot_root,
  allow dbus,

  allow pix /** -> &unpriv_bwrap,

-  audit deny capability,
+  #audit deny capability,
+
+  allow capability sys_admin,

  # the local include should not be used without understanding the userns
  # restriction.
  # Site-specific additions and overrides. See local/README for details.
  include if exists <local/unpriv_bwrap>
}

• https://github.com/lutris/lutris/blob/28cafbb2fdcc5cfec525b8d8900370e4dda46c72/debian/apparmor-profile#L62
• https://github.com/lutris/lutris/pull/5717

The upstream version is available as /usr/share/apparmor/extra-profiles/bwrap-userns-restrict.

Not sure if that's desirable, though. https://gitlab.com/apparmor/apparmor/-/work_items/382 applies.

Check if you have other apparmor profiles interfering with the bwrap profile. For example, unpriv_bwrap is a profile declared by Lutris: `` /etc/apparmor.d/usr.bin.lutris ` Its audit deny capability cannot be overridden by local/unpriv_bwrap (apparmor deny rules always take precedence over allow rules), but at least you can monkeypatch the file (and file an issue against lutris): ` rofile unpriv_bwrap flags=(attach_disconnected,mediate_deleted) { # not allow all, to allow for pix stack allow file rwlkm /{**,}, allow network, allow unix, allow ptrace, allow signal, allow mqueue, allow io_uring, allow userns, allow mount, allow umount, allow pivot_root, allow dbus, allow pix /** -> &unpriv_bwrap, - audit deny capability, + #audit deny capability, + + allow capability sys_admin, # the local include should not be used without understanding the userns # restriction. # Site-specific additions and overrides. See local/README for details. include if exists <local/unpriv_bwrap> } ` * https://github.com/lutris/lutris/blob/28cafbb2fdcc5cfec525b8d8900370e4dda46c72/debian/apparmor-profile#L62 * [Ubuntu: packaging: add AppArmor profile for bwrap lutris/lutris#5717](https://github.com/lutris/lutris/pull/5717) The [upstream version](https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/apparmor/profiles/extras/bwrap-userns-restrict) is available as /usr/share/apparmor/extra-profiles/bwrap-userns-restrict`. Not sure if that's desirable, though. https://gitlab.com/apparmor/apparmor/-/work_items/382 applies.

It helps me on Ubuntu 26.04, but my profile is called /etc/apparmor.d/bwrap-userns-restrict

Hey @egorkel-altexsoft, something seems to have gone wrong with your message.

Could you please check the formatting of your comment?

You can edit it from the "..." menu, and fix the message.

Currently, it is unintelligible.

> Check if you have other apparmor profiles interfering with the bwrap profile. > For example, unpriv_bwrap is a profile declared by Lutris: > `` > /etc/apparmor.d/usr.bin.lutris > ` > > > > > > > > > > > > Its audit deny capability cannot be overridden by local/unpriv_bwrap (apparmor deny rules always take precedence over allow rules), but at least you can monkeypatch the file (and file an issue against lutris): > ` > rofile unpriv_bwrap flags=(attach_disconnected,mediate_deleted) { > # not allow all, to allow for pix stack > allow file rwlkm /{**,}, > allow network, > allow unix, > allow ptrace, > allow signal, > allow mqueue, > allow io_uring, > allow userns, > allow mount, > allow umount, > allow pivot_root, > allow dbus, > > allow pix /** -> &unpriv_bwrap, > > - audit deny capability, > + #audit deny capability, > + > + allow capability sys_admin, > > # the local include should not be used without understanding the userns > # restriction. > # Site-specific additions and overrides. See local/README for details. > include if exists <local/unpriv_bwrap> > } > ` > > > > > > * https://github.com/lutris/lutris/blob/28cafbb2fdcc5cfec525b8d8900370e4dda46c72/debian/apparmor-profile#L62 > * [Ubuntu: packaging: add AppArmor profile for bwrap lutris/lutris#5717](https://github.com/lutris/lutris/pull/5717) > > The [upstream version](https://gitlab.com/apparmor/apparmor/-/blob/master/profiles/apparmor/profiles/extras/bwrap-userns-restrict) is available as /usr/share/apparmor/extra-profiles/bwrap-userns-restrict. > Not sure if that's desirable, though. https://gitlab.com/apparmor/apparmor/-/work_items/382 applies. It helps me on Ubuntu 26.04, but my profile is called /etc/apparmor.d/bwrap-userns-restrict`

This worked for me, and threaded the needle of turning off protections globally to get sandboxing to work, which of course wouldnt make sense.

Thanks!

Still reproduces on Ubuntu 26.04 / kernel 7.0.0-15-generic / native install 2.1.185
(~90 releases and 4 months after this was filed, on a newer kernel than #56345's 6.17).

Error (identical to #56345):

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

Key data point: kernel.apparmor_restrict_unprivileged_userns=0 does NOT fix it.
Verified =0 via /proc, sandbox still fails identically. So the userns create-gate
sysctl isn't the lever — the capability denial comes from the unpriv_bwrap child
profile in /etc/apparmor.d/bwrap-userns-restrict (audit deny capability,), which
strips caps from bwrap's sandboxed children, including the bundled apply-seccomp
helper. Matches the profile="unpriv_bwrap" comm="apply-seccomp" capname="sys_admin"
audit line reported earlier in this thread.

The OS is otherwise healthy — every primitive the sandbox needs works outside the
bundled helper:

unshare -U true # OK
unshare -rU true # OK (map-root)
unshare -rUm true # OK (+mount ns)
unshare -rU bash -c 'unshare -rU true' # OK (double-nested userns)
unshare -rUn sh -c 'ip link set lo up' # OK (netns + loopback up)
bwrap --unshare-user --unshare-net --ro-bind / / true # OK
bwrap --unshare-user --unshare-pid --proc /proc --dev /dev --ro-bind / / true # OK

So this is distinct from #55585/#14719 (the bwrap: loopback: Failed RTM_NEWADDR
netns class) — loopback-in-userns works here. /usr/bin/bwrap succeeds because it has
the permissive profile bwrap attachment; only the vendored apply-seccomp helper,
running as a cap-stripped bwrap child, fails.

For other Linux users landing here: the macOS allowAllUnixSockets workaround does not
exist on Linux (#44180), so it's not a fix. What restores function is disabling the
sandbox (sandbox.enabled: false) or relaxing unpriv_bwrap system-wide (broad — it
re-grants capabilities to every bwrap sandbox, e.g. Flatpak).

Impact: this has forced us to set sandbox.enabled: false across our multi-user
Ubuntu 26.04 dev fleet — i.e. an OS-level security feature turned off in production
because of this regression, with no per-setting workaround on Linux. A fix (or a
documented, narrowly-scoped Linux escape hatch) would be much appreciated.

Environment:

• Ubuntu 26.04 LTS, kernel 7.0.0-15-generic
• Claude Code 2.1.185 (native binary, not npm)
• distro bubblewrap at /usr/bin/bwrap
• kernel.apparmor_restrict_unprivileged_userns = 1 (also tested 0 — no change)
• kernel.unprivileged_userns_clone = 1, user.max_user_namespaces = 45325
• default AppArmor bwrap-userns-restrict profile loaded

Still reproduces on Ubuntu 26.04

Have you reported the issue to Ubuntu? This is a bug in their apparmor policy, not the sandbox runtime.

For people still having issues on Ubuntu - try re-doing the instructions in the sandbox configuration to allow bubblewrap to create user namespaces:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF

then
sudo systemctl reload apparmor

then restart Claude (and/or your machine). This worked for me.

For anyone interested, https://nono.sh intentionally runs with landlock, which means no requirement for namespaces / CAP_SYS_ADMIN. We have many linux users running fedora, ubuntu, arch, debian etc..

Just download the binary, and run nono run --profile nolabs-ai/claude -- claude --dangerously-skip-permissions and your sandboxed.

Root cause, with an isolation matrix. Short version: this is not about capabilities or nested-userns policy — it is bwrap itself setting setgroups=deny, which the kernel then makes permanent and unwritable for every descendant namespace.

Environment: Claude Code 2.1.222 · Ubuntu, kernel 7.0.0-28-generic · bubblewrap 0.11.1 · @anthropic-ai/sandbox-runtime 0.0.70 · apparmor_restrict_unprivileged_userns=0, AppArmor unconfined, unprivileged_userns_clone=1, valid /etc/subuid+/etc/subgid, not in a container, initial userns (identity uid_map).

Isolation matrix

Running the vendored apply-seccomp binary directly, varying only the surrounding bwrap invocation:

| | invocation | result |
|---|---|---|
| C | no bwrap at all | ✅ succeeds |
| A | bwrap --unshare-user --cap-drop ALL --proc /proc (current default) | ❌ EPERM |
| B | bwrap --unshare-user --bind /proc /proc (enableWeakerNestedSandbox: true) | ❌ EPERM |
| D | bwrap --unshare-user --cap-add CAP_SYS_ADMIN | ❌ EPERM |

The helper works fine on its own. It fails inside any bwrap user namespace, and --cap-add CAP_SYS_ADMIN does not help — so the error message's advice ("caller must provide CAP_SYS_ADMIN") does not actually resolve it, and capabilities are not the blocker.

The mechanism

$ cat /proc/self/setgroups                                    # top level
allow
$ bwrap --dev-bind / / --unshare-user -- cat /proc/self/setgroups
deny
$ ls -la /usr/bin/bwrap
-rwxr-xr-x 1 root root 80424 /usr/bin/bwrap                   # NOT setuid

Because bwrap is not setuid on Debian/Ubuntu, it creates its user namespace unprivileged, and the kernel requires it to write deny to /proc/self/setgroups to do so. Per user_namespaces(7), once setgroups is deny in an ancestor namespace it is permanently deny in all descendants and the file becomes unwritable:

$ bwrap --dev-bind / / --unshare-user -- unshare -U sh -c 'echo deny > /proc/self/setgroups'
sh: 1: cannot create /proc/self/setgroups: Permission denied

apply-seccomp.c fallback path (b) creates a nested userns and unconditionally writes deny to setgroups. Inside bwrap that write is both redundant (already deny, inherited) and impossible (kernel forbids it) — and it is treated as fatal.

This also explains why the bug is Linux-distro-dependent rather than kernel-version-dependent: on systems shipping bwrap setuid-root the namespace is created privileged, setgroups stays allow, and the write succeeds.

Suggested fix

In apply-seccomp.c, before the setgroups write, read /proc/self/setgroups; if it already reads deny, skip the write instead of failing. Equivalently, tolerate EPERM there when the current value is already deny — the desired end state is satisfied either way. The subsequent uid_map/gid_map writes are unaffected, since a single-entry identity mapping of the caller's own uid/gid does not require setgroups to be writable.

Failing that, the diagnostic should name the real unmet condition — setgroups is deny in an ancestor namespace — rather than pointing at CAP_SYS_ADMIN, which demonstrably does not fix it (row D).

Workaround

"allowAllUnixSockets": true skips the seccomp filter entirely, so the sandbox arms and the filesystem/network restrictions still apply — corroborating #81799, which reports the same bug on this same kernel. enableWeakerNestedSandbox: true makes no difference (row B).

Created better sandboxing solution for linux users: https://jailbee.gisgro.io/

Reproduced on the latest release (2.1.233). In an environment where user namespaces can be created but don't grant capabilities (the default AppArmor policy on newer Ubuntu, including 25.10, and many containers), every sandboxed Bash command fails during sandbox setup with an apply-seccomp: ... Permission denied error — on some kernels the failing write is setgroups, on others uid_map, but it's the same underlying failure.

This is a regression introduced in 2.1.92, when the Linux sandbox started shipping the seccomp helper (see the 2.1.92 changelog entry). The helper needs to set up a capability-bearing nested user namespace, which these environments block. 2.1.91 didn't ship the helper, so it didn't hit this.

Workarounds until a fix lands:

• sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 (weakens system hardening — see the sandboxing docs troubleshooting section)
• Note the AppArmor profile in the docs currently covers bubblewrap only, so it may not be sufficient on its own for this error
• In unprivileged containers, the enableWeakerNestedSandbox sandbox setting may help

Keeping this open as a reproduced regression.

🤖 Generated with Claude Code

Fresh measurements on 2.1.234 (Ubuntu 26.04 LTS, kernel 7.0.0-28-generic, KVM VM, bubblewrap 0.11.1 non-setuid, stock AppArmor profile set — bwrap-userns-restrict and unprivileged_userns, no custom bwrap profile — apparmor_restrict_unprivileged_userns=1, native install), following up on the confirmation above:

Still reproduces on 2.1.234, in both strict and default mode. Headless probes with --settings '{"sandbox":{"enabled":true,...}}', re-run with a scrubbed environment from a fresh $HOME directory:

| settings | result |
|---|---|
| {"enabled":true,"allowUnsandboxedCommands":false} | ❌ every command: apply-seccomp: write /proc/self/setgroups (...): Permission denied |
| {"enabled":true} (defaults) | ❌ same error on every command's first attempt; recovery relies on a model retry with dangerouslyDisableSandbox, which then runs unsandboxed |
| {"enabled":true,"allowUnsandboxedCommands":false,"network":{"allowAllUnixSockets":true}} | ✅ commands run; probe shows setgroups=deny, a non-initial userns, writes outside the workspace denied, writes in cwd allowed |

Two notes on the environment:

• @anthropic-ai/sandbox-runtime is not installed on this machine. The sandboxing docs call the seccomp filter optional ("install it with npm ... if it is missing"), but the native binary applies the bundled helper even with the package absent — so skipping the npm package is not an escape hatch, and the docs' optionality doesn't hold for native installs.
• Since my 2026-06-22 comment (kernel 7.0.0-15) this host moved to 7.0.0-28 with AppArmor userspace and profiles unchanged, and plain unshare -Ur went from working to failing at the uid_map write — consistent with "on some kernels the failing write is uid_map". The stock unprivileged_userns profile (audit deny capability, transitioned to from unconfined) is what strips the capabilities.

So network.allowAllUnixSockets: true restores a fully armed sandbox — filesystem isolation enforced, only the Unix-socket filter skipped — corroborating @luispabon and #81799 on 2.1.234. A far better interim position than sandbox.enabled: false, which is where this bug had pushed our fleet.

On workaround 1: kernel.apparmor_restrict_unprivileged_userns=0 did not resolve this when I measured it in June on 7.0.0-15, and #81799 reproduces the identical failure on 7.0.0-28 with both apparmor sysctls =0 and AppArmor unconfined end to end — consistent with @luispabon's matrix: the blocker is bwrap's inherited setgroups=deny, which no sysctl lifts once the ancestor namespace carries it. Their suggested fix — tolerate the redundant deny write when setgroups already reads deny — still looks like the cheapest correct one, and would make allowAllUnixSockets unnecessary as a workaround.

(Method note: probes ran via headless claude -p on a fleet machine whose org-managed hooks are unrelated to sandboxing; #81799 shows the same repro in a clean-room CLAUDE_CONFIG_DIR with no hooks.)

<p dir="ltr">We can reproduce this on Ubuntu 26.04, and can add data that may be useful: the same failure across <strong>three separate CLI versions over nine days on the same machine and configuration</strong>, which suggests the 2.1.91→2.1.92 regression has not self-resolved in later releases.</p>
<div dir="ltr">
Date | apt CLI version | Result
-- | -- | --
2026-08-16 | 2.1.224 | same failure
2026-08-17 | 2.1.226 | same failure
2026-08-24 | 2.1.231 | same failure

</div>
<p dir="ltr">Exact error, unchanged across all three:</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">apply-seccomp: write /proc/self/setgroups (nested userns is
capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied</code></pre></div></div>
<p dir="ltr"><strong>Environment:</strong> Ubuntu 26.04, kernel <code>7.0.0-30-generic</code>, apparmor 5.0.2-0ubuntu1~26.04.1, <code>kernel.apparmor_restrict_unprivileged_userns = 1</code> (set deliberately by us, in <code>/etc/sysctl.d/</code>), distribution-supplied <code>/etc/apparmor.d/bwrap-userns-restrict</code> unmodified (hash-verified unchanged across the whole period). <code>bubblewrap</code> installed; flatpak is not installed.</p>
<p dir="ltr">On our end we independently ruled out an AppArmor-side cause: a single-level bwrap invocation (<code>--unshare-user --cap-drop ALL</code>) runs fine on this machine; only the nested case fails, consistent with the write-before-UID-mapping order already identified in this thread. We also checked whether the profile's own local-override hooks (<code>include if exists &lt;local/...&gt;</code>) could work around it — they can't, because the blocking rule is an <code>audit deny capability</code> and in AppArmor <code>deny</code> always wins over <code>allow</code> regardless of ordering or override.</p>
<p dir="ltr">Not asking for a workaround — just flagging that this is a stable, multi-version regression rather than a one-off, in case that's useful for prioritization.</p>
<p dir="ltr"><strong>Attachment:</strong> raw output, verbatim except two unrelated warning lines removed and the home directory path replaced with <code>/home/&lt;user&gt;</code>.</p>
<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">2.1.231 (Claude Code)
apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied</code></pre></div></div>