Sandbox deny list grows without bound with registered git worktrees; at ~250 worktrees every Bash command fails with E2BIG
Status Open
Reported on v2.1.251
Maintainer reply None cached
Activity 0 comments · opened Aug 29, 2026
Environment
- Claude Code 2.1.251 (also reproduced on 2.1.220), Linux x86_64, bubblewrap sandbox, Node 24
- Non-interactive/automation use (headless sessions), default sandbox settings — no user-configured deny rules
What happened
We run an automation setup where each task gets its own linked git worktree of one repository. Once the repository accumulated 261 registered worktrees, every Bash tool invocation in sessions on that repo began failing at spawn — including trivial commands like sleep 5 — with:
Could not start /bin/bash: the command line plus environment exceed the OS exec
argument limit (E2BIG). At spawn: command line 130.7KB across 3 args (largest
single arg 130.7KB); environment 9.5KB across 132 vars (largest: PATH at 1.1KB).
The Bash sandbox profile adds 687 filesystem deny paths to every command, 524 of
them for registered git worktrees, which grow this list without bound. From
another terminal, remove worktrees you no longer need (git worktree remove
<path>; git worktree prune for already-deleted checkouts), then restart Claude
Code so the profile is rebuilt without them — or relax the Bash sandbox for this
session with /sandbox.
The failure mode is total and sudden: nothing degrades gradually — the moment the profile crosses Linux's MAX_ARG_STRLEN (128 KB per single argv element), every shell command in every session on that repository fails, because /bin/bash can never be spawned. Monitor/background execution fails identically.
Analysis
- The sandbox profile adds roughly two deny entries per registered worktree — the worktree admin files under
.git/worktrees/<id>/(config.worktree,config.worktree.lock,commondir). I understand these denies to be the mitigation for GHSA-7835-87q9-rgvv (CVE-2026-55607, the worktree path-confusion sandbox escape), so simply dropping them is not what this issue asks for. - The profile travels inside a single
/bin/bash -c "<bwrap …>"string (same mechanics as #51126), so the entire deny list counts against the 128 KB single-argument limit. At ~2 entries × ~250 worktrees plus the ~160 baseline entries, the string crosses the limit. - 524 / 687 deny entries came from worktree enumeration alone, with zero user deny configuration. #51126 was closed as not planned, but it was framed around large user-configured deny lists; here the unbounded growth comes from Claude Code's own worktree enumeration, so the "configure fewer denies" answer doesn't apply.
- The in-message remediation (manually remove worktrees, restart Claude Code) is a hard ceiling of ~250 worktrees per repository for any workflow that creates worktrees programmatically — including Claude Code's own
isolation: "worktree"agents (#47134), which contribute to the same list.
Reproduction
git init repro && cd repro && git commit --allow-empty -m init
for i in $(seq 1 300); do git worktree add -d "wt/$i" >/dev/null; done
claude # sandbox enabled, then run any Bash command, e.g.: date
# → Could not start /bin/bash: … E2BIG … N deny paths … for registered git worktrees
Suggested fixes (either one resolves it)
- Transport fix — stop passing the profile through one
bash -cstring: invokebwrapdirectly with an argv array (each element gets its own 128 KB budget), or feed the configuration via--args-fd/file, which removes the argv limit from the equation entirely. This fixes E2BIG generally, with no change to deny semantics, and would also resolve #51126 / #4488. - Structural fix — make the worktree mitigation O(1) instead of O(worktrees): deny the shared
.git/worktrees/directory (and the worktree container directory) as a whole, then allow back only the current session's own worktree admin directory. Same security property as the CVE mitigation, constant profile size.
Related
- #51126 — E2BIG from deny paths in the
bash -c-wrapped bwrap invocation (closed as not planned; user-configured denies) - #4488 — E2BIG in CI environments
- #17727 — Linux sandbox bwrap invocation bugs
- #26262, #80278 — sandbox vs. git worktree friction
- #47134 —
isolation: "worktree"agents (their worktrees feed the same deny list) - GHSA-7835-87q9-rgvv / CVE-2026-55607 — the escape these per-worktree denies mitigate