Sandboxed Bash intermittently fails: apply-seccomp: unshare(CLONE_NEWUSER): Invalid argument

Same issue here. Claude told me to add the following to this bug report:

----------------

Another data point, different hardware profile from the report.

• Claude Code 2.1.233, Linux 7.1.7+deb14-amd64 x86_64, 4 cores, bare metal
• Running inside a nested unprivileged bwrap userns (bubbleclaude wrapper)
• 19 failures / 151 Bash tool calls (~13%) in normal agentic work with

subagent fan-out — not a tight loop

This is a multi-core x86_64 case, which cuts against "multi-core machines rarely
see this at all" — though the nesting is the likely driver, consistent with your
20/30 bwrap userns/pidns row. Kernel 7.1 and x86_64 both still reproduce, so it's
neither arch- nor kernel-version-specific.

On your question about whether sandbox.allowUnsandboxedCommands defaulting to
true is the right default — a data point in favour of changing it. This config
sets it to false. During an audit of this sandbox, an agent did invoke
dangerouslyDisableSandbox: true, and enforcement was byte-for-byte identical
across network, raw sockets and filesystem: the flag was inert. So the failure
mode you describe (transient sandbox error → model disables the sandbox → reads
something it shouldn't) is fully prevented by that setting. Minor UX note: the
flag was silently accepted rather than rejected, so nothing signalled that it
had no effect.

Pitfall for anyone writing a reproducer: calling unshare(CLONE_NEWUSER) in a
fork()ed child won't show the bug — fork() gives a single-threaded child
regardless of the parent, so the constraint isn't exercised. The thread has to
exist in the process making the call.

Same issue here and also Claude Code 2.1.233. Atempting to run Claude inside a rootless Docker container gw0/docker-claude-code with sandboxed Bash tools turned on. Everything works fine without sandboxing (sandbox.enable=false and CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=0).

Thanks @remileduc — that's a valuable data point, and it corrects my framing. I wrote "multi-core machines rarely see this at all", but under nested userns the window evidently stays open regardless of core count, so the exposure is wider than my single-core numbers suggested — and ~13% of real-workload Bash calls is well past nuisance level.

The allowUnsandboxedCommands: false audit result (enforcement byte-for-byte identical, dangerouslyDisableSandbox inert) is exactly the field evidence the default-value question needed. The silent accept seems worth a small fix of its own: a hard error would teach the model that the flag is a dead end, instead of letting it believe the escape worked.

Good catch on the fork() pitfall too — that's why the reproducer above creates the thread with clone(CLONE_THREAD) in the same process rather than forking first.

@gw0 thanks — that makes a third independent environment shape: single-core arm64 VM with no nesting (original report), multi-core x86_64 bare metal under nested bwrap userns (@remileduc), and rootless Docker (yours). The common thread is that anything keeping the thread-reap window open gets hit; core count just changes the odds.

For anyone landing here: the proposed fix (a bounded EINVAL retry in the vendored apply-seccomp.c) is up at anthropic-experimental/sandbox-runtime#479.

I have the same issue (using claude-agent-sdk-python), it runs inside a docker container.

Environment shape #4, plus a simpler workaround.

• Claude Code 2.1.232, Linux 6.8.0 x86_64, 32 cores, bare metal desktop, no nesting beyond the stock bwrap invocation
• ~1/3 of sandboxed Bash calls failing during a heavy multi-agent session this morning; 1/200 invoking the helper in an idle loop (ARGV0=apply-seccomp <claude-binary> /bin/true); 0/200 in the same loop under full CPU load — direction consistent with the reap-window mechanism (idle machines fail more)

Workaround: MIMALLOC_PURGE_DELAY=0 in the environment. This stops mimalloc from spawning the mi-scavenger thread at all, so the helper process is genuinely single-threaded and the racy precondition can't be violated. Verified by strace (zero clone3(CLONE_THREAD) calls in helper mode with the var set) and 300/300 clean in the loop that failed 1/200 without it. It's settable via the env block in settings.json, so no wrapper binary or PATH shim is needed and it survives Claude Code updates:

{ "env": { "MIMALLOC_PURGE_DELAY": "0" } }

Caveat: the variable also reaches the main Claude Code process, where it switches mimalloc to eager purging — a marginal perf cost on frees. -1 also suppresses the thread but disables purging entirely, which would grow RSS in long-running sessions; 0 is the right value. Obviously this is a workaround leaning on an allocator implementation detail, not a fix — the bounded-EINVAL-retry in anthropic-experimental/sandbox-runtime#479 is the real thing.

Confirmed / reproduced on 2.1.234 (Linux x86_64, 4-vCPU VM, idle): running the standalone loop from the comments above as an unprivileged user with a trivial /bin/true payload, 2 of 600 back-to-back invocations failed with exactly apply-seccomp: unshare(CLONE_NEWUSER): Invalid argument (exit 1), and the identical command succeeded on the next run. The rate here is far below the single-vCPU / nested-userns numbers reported above, but the intermittent failure shows up on a stock multi-core x86_64 box too.

🤖 Generated with Claude Code

---
_Generated by Claude Code_

Independent reproduction on hardware that does not match the "single vCPU" factor noted above, and on a newer Claude Code build. Sharing because both details argue the race is broader than the original environment suggested.

Environment

| | This report | Original report |
|---|---|---|
| Claude Code | 2.1.238 | 2.1.232 to 2.1.233 |
| Distro | Ubuntu 24.04.4 LTS | Debian 12 |
| Kernel | 7.0.0-28-generic | 6.1.0-52-cloud-arm64 |
| Arch | x86_64 | aarch64 |
| CPUs | 14 (Intel Core Ultra 7 155U) | 1 vCPU |
| bubblewrap | 0.9.0 | 0.8.0 |

Two things this adds

1. Not limited to single vCPU or to aarch64. This is a 14-core x86_64 laptop under light load. The window is a thread-group reaping race, so core count narrows it but does not close it.
2. Observed failure rate was higher, not lower: roughly 1 in 6. Across a single working session I saw 8 failures in approximately 45 sandboxed Bash calls. The original report cites about 1 in 10. Small sample, so treat the exact ratio loosely, but it was not rarer here.

Confirming the diagnosis above independently

Before finding this issue I bisected it from the error string alone and landed on the same kernel constraint, which I mention only as corroboration of the check_unshare_flags explanation:

single-threaded              threads=1 rc=0  errno=0  OK
after fork (1 thread again)  threads=1 rc=0  errno=0  OK
multi-threaded (in-process)  threads=2 rc=-1 errno=22 Invalid argument

Ruled out on this machine, in case it saves anyone else the detour:

• CONFIG_USER_NS=y
• /proc/sys/user/max_user_namespaces = 114669
• /proc/sys/kernel/unprivileged_userns_clone = 1
• kernel.apparmor_restrict_unprivileged_userns = 1, which is set, but that would fail deterministically rather than intermittently, so it is not the cause here. Worth stating explicitly since #87680 covers the AppArmor path and the two get conflated.

Impact note

Failures are cheap in isolation, since re-running the identical command has succeeded on the first retry every time for me. The real cost is that the error is easy to misread as a problem with the command, which sends you debugging the wrong thing. A bounded retry on EINVAL, as suggested above, would remove that entirely.

Related, and possibly worth a separate issue: inside the sandbox the PID namespace makes kill -0, pgrep, and ss silently report host processes and listening ports as absent. That is expected behavior for a PID namespace, but it is not obvious from the tool's output, and it produced a confidently wrong conclusion for me before I checked outside the sandbox.

Still present in 2.1.237 (the runtime bundled with Claude Desktop), and on
a different platform than the reports above: Debian 13.6, Linux 6.12.101
x86_64, multi-core desktop machine.

Rate here is much lower than yours — 3 failures over two days of normal use,
on git commit, grep and git add. That fits your observation that busy
multi-core machines are hit far less often than idle single-vCPU ones.

Independently confirmed fail-closed on this platform: after each failure I
checked state before retrying, and the command had not run.

Also ruled out on this host, in case it saves someone the detour:
user/max_user_namespaces is 2147483647, kernel/unprivileged_userns_clone
is 1, and kernel/apparmor_restrict_unprivileged_userns does not exist on
Debian 13 — so none of the usual namespace/policy suspects apply here.

Confirming the MIMALLOC_PURGE_DELAY=0 workaround with a paired measurement, plus one factor I don't think anyone has reported yet: page cache state moves the failure rate by more than 10x, which I suspect is quietly behind the wide spread in the rates reported above.

Environment

| | |
|---|---|
| Claude Code | 2.1.241 (build 2026-08-22) |
| Distro | Ubuntu 26.04 LTS |
| Kernel | 7.0.0-30-generic, x86_64 |
| CPU | Intel Core Ultra 9 285H, 16 cores |
| bubblewrap | 0.11.1 |
| Nesting | none, stock bwrap invocation |

Usual suspects ruled out here too: CONFIG_USER_NS=y, kernel.unprivileged_userns_clone=1, user.max_user_namespaces=250542, kernel.apparmor_restrict_unprivileged_userns=0, and unshare --user true succeeds as an unprivileged user.

Method

Invoked the helper directly rather than going through tool calls, so the sample size is cheap:

seq N | xargs -I{} sh -c 'ARGV0=apply-seccomp <claude-binary> /bin/true 2>/dev/null || echo FAIL' | grep -c FAIL

Control used env -u MIMALLOC_PURGE_DELAY on the same line. Run order was alternated after the cold-cache effect below turned up.

The cold-cache factor

My first baseline run, on a cold page cache, gave 25/200 (12.5%). Re-running the identical control warm gave 2/200 (1%). Same machine, same binary, same command, minutes apart.

If I had stopped at my first pair I would have reported a 12.5% -> 0% win, and it would have been confounded. Worth flagging because it fits the mechanism: the race is a thread-group reap window, so anything that slows the process down while leaving it otherwise idle widens it. Cold cache does exactly that.

The practical consequence is that exposure is worst at the start of a session, before the binary and its pages are cached — which matches what I saw in real use, where the error clustered on the first few tool calls of a session and then largely stopped. It may also explain part of the 2/600 to 1/3 spread in this thread: reporters measuring during warm, busy sessions and reporters measuring cold will get very different numbers from the same defect.

Paired result, warm only

| condition | failures | rate |
|---|---|---|
| without MIMALLOC_PURGE_DELAY | 2/200 + 2/600 + 32/3000 = 36/3800 | 0.95% |
| with MIMALLOC_PURGE_DELAY=0 | 0/200 + 0/600 + 0/3000 = 0/3800 | 0% |

If the rate under the fix were still 0.95%, observing zero failures in 3800 runs has probability (1 - 0.0095)^3800 ≈ 2e-16.

Secondary signal

Wall time for 3000 invocations dropped from 12.16s to 7.92s (-35%) with the var set. That is consistent with the stated mechanism — no mi-scavenger thread being spawned and joined per invocation — and is an independent check that the var is doing what it is claimed to do, not just perturbing timing enough to hide the race.

On the reporting side

One more data point for the concern raised in the original report about the model mishandling this. In my case the agent hit the error, correctly derived the multithreaded-caller EINVAL mechanism from the kernel semantics, and then retried the same command with dangerouslyDisableSandbox: true and proceeded. It disclosed that it had done so, but the sandbox was off for that command. With sandbox.allowUnsandboxedCommands defaulting to true, a transient setup failure is a reliable trigger for exactly that escape.

Distinguishing transient setup failures from policy denials in the message surfaced to the model would help here. As it stands both read as "the sandbox stopped me", and only one of them is a reason to consider an unsandboxed retry.

---

🤖 Generated with Claude Code

Confirming MIMALLOC_PURGE_DELAY=0 on a third platform/version combination — but
the reason I'm posting is a question nobody in this thread has measured yet: does
the workaround weaken the sandbox it is meant to let succeed?

It does not, and here is the check.

Environment

| | |
|---|---|
| Claude Code | 2.1.237 (the runtime bundled with Claude Desktop) |
| Distro | Debian 13.6 |
| Kernel | 6.12.101 x86_64 |
| Machine | multi-core desktop, bare metal, no nesting |

The security check

Same helper invocation as above, but reporting from inside the sandbox it builds:

ARGV0=apply-seccomp <claude-binary> /bin/sh -c \
  'grep -E "^Seccomp|^NoNewPrivs" /proc/self/status; cat /proc/self/uid_map'

| | without the var | with MIMALLOC_PURGE_DELAY=0 |
|---|---|---|
| NoNewPrivs | 1 | 1 |
| Seccomp | 2 (filter mode) | 2 (filter mode) |
| Seccomp_filters | 2 | 2 |
| uid_map | <uid> <uid> 1 | <uid> <uid> 1 |

Line for line identical. The variable removes the reason the sandbox setup
intermittently failed; it changes nothing about what the built sandbox enforces.
Worth stating explicitly, because "set this env var and the seccomp error goes
away" reads like it could be doing the opposite.

Efficacy here

14,000 helper invocations per condition, alternating order, after a warm-up:

| condition | failures | rate |
|---|---|---|
| without | 16 / 14,000 | 0.114% |
| with MIMALLOC_PURGE_DELAY=0 | 0 / 14,000 | 0% |

All 16 carried exactly apply-seccomp: unshare(CLONE_NEWUSER): Invalid argument.
If the var were inert, zero in 14,000 would have probability
(1 - 0.00114)^14000 ≈ 1.1e-7.

One sharper number for the mechanism

@martinstuecklschwaiger reports -35% wall time. Splitting that by where it goes is
more diagnostic than the total, since thread creation and reaping is kernel work.
3,000 invocations each:

| | without | with | change |
|---|---|---|---|
| real | 10.257s | 7.774s | -24.2% |
| user | 6.659s | 5.900s | -11.4% |
| sys | 3.567s | 1.914s | -46.3% |

Kernel time nearly halves. That is consistent with the thread not being spawned at
all, rather than the race merely resolving differently — a pure timing shift would
not remove the work.

One trap when adopting it via settings.json

@StructByLightning's env block in .claude/settings.json is the route I took,
and it works — after a session restart, env | grep MIMALLOC returns
MIMALLOC_PURGE_DELAY=0 inside Bash tool calls.

That verification proves less than it looks like, though, and I got it wrong at
first. The Bash process having the variable does not establish that the
apply-seccomp helper had it — a parent can hand a child an environment via
execve that it does not carry itself, and the helper is where the race actually
happens. Checking directly is blocked by the sandbox itself: from inside, the
process chain ends at PID 1 and /proc/1/environ returns Permission denied, so
the helper sits outside that PID namespace.

So for anyone adopting this via settings.json: the only evidence that it reaches
the helper is the failures staying gone over time. At a 0.114% base rate, one
uneventful session proves nothing; a few hundred tool calls without an occurrence
does.

Not a fix for this race, but a workaround category for anyone blocked by sandbox flakiness: external sandboxes sidestep the self-re-exec helper entirely.

vetto (mine, disclosure) creates the namespaces/seccomp/Landlock setup from a separate supervisor binary before the agent's bash ever spawns — there's no re-entrant helper racing the runtime, and the kernel primitives are the same ones the embedded helper is driving. Trade-off to be clear about: it's a wrapper process around claude, not the built-in per-call sandbox, so granularity differs (whole session vs per Bash call).

Also seeing this on x86_64 / Rocky Linux 9 (kernel 5.14.0-687.26.1.el9_8), Claude Code 2.1.236, bubblewrap sandbox on a busy multi-user login node — low, intermittent rate, consistent with your load-dependence analysis. Identical command succeeds on retry.

Enterprise-managed deployment with allowUnsandboxedCommands: false, so the dangerouslyDisableSandbox fallback you observed is blocked here, but the transient failures remain user-visible.

+1 for the bounded-retry fix.

@bcherny what do we have to do to get this fixed?

@jerbob92 re "what do we have to do to get this fixed" — it may already be fixed. On the same machine as my Aug 24 comment, the race no longer reproduces on 2.1.255 and 2.1.260, while an older build still fails under identical conditions in the same run.

Environment

| | |
|---|---|
| Machine | same Debian 13 multi-core desktop as above, kernel now 6.12.107 x86_64 |
| Load | ~0.2, box up 9 days |
| Builds | 2.1.236 (apt package), 2.1.255 and 2.1.260 (Claude Desktop bundles) |

Method

Same as before — the helper invoked directly, /bin/true payload, 100 warm-up runs, stderr captured. All runs without MIMALLOC_PURGE_DELAY (env -u), since the question is whether the defect is still in the binary.

Results

| build | invocations | failures | rate |
|---|---|---|---|
| 2.1.236 | 12,000 | 18 | 0.15% |
| 2.1.255 | 4,000 | 0 | 0 |
| 2.1.260 | 18,000 | 0 | 0 |

All 18 failures carried exactly apply-seccomp: unshare(CLONE_NEWUSER): Invalid argument.

The control matters more than the zeros: 4,000 of the 2.1.236 runs and 4,000 of the 2.1.260 runs were interleaved in the same loop, 4 alternating blocks of 1,000 each — 2.1.236 failed 3 times, 2.1.260 zero times. So the difference is in the binary, not in kernel version or load.

If 2.1.260 were as prone as 2.1.236, zero failures in 18,000 would have probability (1 - 0.0015)^18000 ≈ 2e-12.

What still looks unchanged

MIMALLOC_PURGE_DELAY=0 still cuts kernel time on 2.1.260 (3,000 invocations: sys 4.595s → 3.252s, -29%; on 2.1.237 it was -46%). So the scavenger thread appears to still be spawned. My guess — and it is only a guess — is that a retry/wait around the unshare landed rather than the thread being removed. I can't find anything in CHANGELOG.md through 2.1.266 that mentions it.

Sandbox state on 2.1.260 is identical with and without the var, same check as in my earlier comment (NoNewPrivs 1, Seccomp 2, Seccomp_filters 2, uid_map unchanged).

Caveats

• I can't bisect further — no build between 2.1.236 and 2.1.255 is on this machine.
• This is a busy multi-core box, not the idle single-vCPU case from the original report where the rate was 200/200. "Doesn't reproduce here" is not "fixed".
• If a maintainer knows what changed between 2.1.236 and 2.1.255, a one-line confirmation would let everyone here stop carrying the workaround.

@Mandelbrotmenge-21 I had Claude go through the changes in CLI between those versions but it didn't see a difference in the sandbox wrapper and/or some internal retry mechanism. I haven't confirmed myself yet whether the issue is really gone.

Update on anthropics/sandbox-runtime#479: it no longer retries. unshare(CLONE_NEWUSER) implies CLONE_THREAD and is refused with EINVAL whenever the thread group is non-empty — including a thread that exited a moment ago but is not yet released, which is the race here. clone(CLONE_NEWUSER|…) has no such check, and apply-seccomp already forks its inner init right after that point, so the PR now creates the user namespace on that clone and lets the child write its own uid/gid maps (the bubblewrap/unshare -r pattern). Same host as before, in-process harness (thread joined, then apply-seccomp's main): unshare 200/200 EINVAL, clone 0/200; it also holds with the helper thread still alive, where a retry loop could never succeed.

Re the 2.1.255+ zeros reported above: the library code on main still calls unshare(CLONE_NEWUSER) and dies on EINVAL, so if those builds are clean it is because something in the bundle stopped parking a thread right before the sandbox setup, not because the race was closed. The PR removes the dependency on that.

Correction to my last update on anthropics/sandbox-runtime#479: the raw clone() version is withdrawn. It avoids the EINVAL, but a raw clone skips atfork handlers and glibc's fork-time lock reset. In a host with a live thread, the child can then hang forever in its next fork() or perror(). In an in-process harness it hung 50/50 times with a thread cycling an atfork-guarded lock and 21/50 times with a thread cycling malloc/free.

The PR now keeps the existing unshare and, only on EINVAL, forks and redoes it in the single-threaded child, with the parent relaying signals and exit status. That completed 50/50 in the just-joined, atfork and malloc cases.

On the zero-failure reports for newer builds: on 2.1.272 (arm64), strace of ARGV0=apply-seccomp shows no thread being created before the sandbox setup, so that build does not enter the race. The library code on main still dies on this EINVAL, so any multithreaded seccomp.argv0 embedder remains exposed until the PR lands.