claude-code - 💡(How to fix) Fix [BUG] Sandbox fails inside Docker containers: nested user namespace in apply-seccomp causes EACCES on /proc/self/setgroups [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48304Fetched 2026-04-16 07:03:35
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
labeled ×4commented ×1

Error Message

Error Messages/Logs

  1. Observe the apply-seccomp permission denied error

Root Cause

The root cause is a nested user namespace. The sandbox call chain is:

Fix Action

Fix / Workaround

Workaround: Replace apply-seccomp with a passthrough script. This preserves bwrap's namespace isolation (network, mount, pid, session) while skipping the nested userns:

Code Example

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

---

# bwrap creates first userns
1218  unshare(CLONE_NEWUSER)            = 0

# apply-seccomp creates second (nested) userns
1222  unshare(CLONE_NEWNS|CLONE_NEWPID) = -1 EPERM (Operation not permitted)
1222  unshare(CLONE_NEWUSER)            = 0
1222  openat(AT_FDCWD, "/proc/self/setgroups", O_WRONLY) = -1 EACCES (Permission denied)

---

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

---

cap_add:
     - SYS_ADMIN
     - SYS_PTRACE
     - NET_ADMIN
   security_opt:
     - seccomp=unconfined
     - apparmor=unconfined

---

printf '#!/bin/sh\nexec "$@"\n' > /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp && \
chmod +x /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When running Claude Code inside a Docker container as a non-root user with sandbox enabled, all bash commands fail with:

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

The root cause is a nested user namespace. The sandbox call chain is:

  1. Claude Code invokes bwrap --unshare-net ...
  2. Because the container user is non-root, bwrap must call unshare(CLONE_NEWUSER) to obtain CAP_NET_ADMIN for --unshare-netuserns layer 1
  3. bwrap then execves apply-seccomp, which calls unshare(CLONE_NEWUSER) again → userns layer 2 (nested)
  4. Inside the nested userns, apply-seccomp tries to open("/proc/self/setgroups", O_WRONLY)EACCES

The kernel denies writes to /proc/self/setgroups in a nested user namespace. This is a hard kernel restriction, not configurable via sysctl or AppArmor.

Confirmed via strace:

# bwrap creates first userns
1218  unshare(CLONE_NEWUSER)            = 0

# apply-seccomp creates second (nested) userns
1222  unshare(CLONE_NEWNS|CLONE_NEWPID) = -1 EPERM (Operation not permitted)
1222  unshare(CLONE_NEWUSER)            = 0
1222  openat(AT_FDCWD, "/proc/self/setgroups", O_WRONLY) = -1 EACCES (Permission denied)

None of the following help:

  • kernel.apparmor_restrict_unprivileged_userns=0 on host
  • seccomp=unconfined, apparmor=unconfined, cap_add: SYS_ADMIN in Docker Compose
  • chmod u+s /usr/bin/bwrap (bwrap 0.11.0 still enters userns)
  • setcap cap_net_admin,cap_sys_admin+eip /usr/bin/bwrap

Running as root inside the container works (bwrap skips userns), but is undesirable for security.

What Should Happen?

Claude Code sandbox should work inside Docker containers when running as a non-root user, or gracefully degrade (e.g., skip the apply-seccomp layer when nested userns is detected) instead of failing all bash commands.

Error Messages/Logs

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

Steps to Reproduce

  1. Create a Docker Compose service running a Debian-based image with Claude Code installed
  2. Run the container as a non-root user (e.g., uid 996)
  3. Docker Compose config:
    cap_add:
      - SYS_ADMIN
      - SYS_PTRACE
      - NET_ADMIN
    security_opt:
      - seccomp=unconfined
      - apparmor=unconfined
  4. Enter the container and run Claude Code with sandbox enabled
  5. Execute any bash command (e.g., echo "hello")
  6. Observe the apply-seccomp permission denied error

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.91

Claude Code Version

2.1.108

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

Host: Ubuntu 24.04, kernel 6.8.0-100-generic Container base: Debian Trixie bubblewrap: 0.11.0

Workaround: Replace apply-seccomp with a passthrough script. This preserves bwrap's namespace isolation (network, mount, pid, session) while skipping the nested userns:

printf '#!/bin/sh\nexec "$@"\n' > /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp && \
chmod +x /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp

Suggested fixes:

  1. Detect nested userns and skip apply-seccomp automatically
  2. Merge isolation layers — have bwrap handle seccomp directly via --seccomp instead of delegating to a separate binary
  3. Add a config option (e.g., CLAUDE_SANDBOX_SECCOMP=false) to disable the apply-seccomp layer independently
  4. Skip --unshare-net when network is already restricted, avoiding the userns requirement for non-root users

extent analysis

TL;DR

The most likely fix is to detect nested userns and skip apply-seccomp automatically or use a workaround by replacing apply-seccomp with a passthrough script.

Guidance

  • To verify the issue, run Claude Code inside a Docker container as a non-root user with sandbox enabled and check for the apply-seccomp permission denied error.
  • The workaround provided in the issue body can be used to preserve bwrap's namespace isolation while skipping the nested userns.
  • To mitigate the issue, consider detecting nested userns and skipping apply-seccomp automatically or merging isolation layers to have bwrap handle seccomp directly.
  • Another option is to add a config option to disable the apply-seccomp layer independently.

Example

The provided workaround script can be used as an example:

printf '#!/bin/sh\nexec "$@"\n' > /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp && \
chmod +x /usr/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp

This script replaces apply-seccomp with a passthrough script, skipping the nested userns.

Notes

The issue is specific to running Claude Code inside a Docker container as a non-root user with sandbox enabled, and the workaround may not be applicable in other scenarios.

Recommendation

Apply the workaround by replacing apply-seccomp with a passthrough script, as it preserves bwrap's namespace isolation while skipping the nested userns. This is a temporary solution until a more permanent fix is implemented.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING