[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.