[BUG] WSL2: Bash tool fails with E2BIG because Claude wraps bubblewrap in single /bin/bash -c string exceeding Linux MAX_ARG_STRLEN

[chenlundeaimi]

Preflight Checklist

• I have searched existing issues — closest related but distinct: [BUG] Github actions not running due to E2BIG argument list too long #4488, [BUG] Linux sandbox broken - bad bwrap calls and no allow permissions #17727, sandbox.enabled: false setting ignored — bwrap still wraps all Bash commands #35986
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

On WSL2, every Bash tool call fails immediately with Exit code 126 and "Request interrupted by user for tool use" (no actual user interruption occurs) when sandbox.enabled: true is set with a non-trivial filesystem.denyRead list and/or permissions.deny Read(...) patterns.

Root cause (confirmed via strace): Claude Code constructs a bubblewrap (bwrap) sandbox wrapper command and passes it as a single -c argument to /bin/bash. This single argument exceeds Linux's MAX_ARG_STRLEN = PAGE_SIZE × 32 = 128 KB limit (defined in include/uapi/linux/binfmts.h), causing posix_spawn to return E2BIG.

Important: This is NOT the ARG_MAX (2 MB) limit. The kernel enforces a separate per-argument size cap via MAX_ARG_STRLEN.

Baseline checks (all normal — ruling out environmental causes):

• getconf ARG_MAX = 2097152
• ulimit -s = 8192
• Process environ sizes are in the single-digit KB range
• Bare bash -c 'echo hello' works
• node -e "child_process.spawn('bash', ['-c', 'echo hello'])" works
• Same Claude binary, smaller workspace / smaller deny list → works

Independent verification that narrowed this to the harness/bwrap layer:

• Both the VS Code extension and the standalone CLI (claude --dangerously-skip-permissions, same underlying claude binary) reproduce the failure identically.
• VS Code window reload, full VS Code restart (process kill + relaunch), and switching permission mode across plan / default / acceptEdits / bypass all fail to resolve it.
• User-side PreToolUse Bash hooks were independently verified as NOT the cause: invoking them directly with the documented stdin JSON payload returns exit 0.
• No permission prompt appears in the VS Code UI during failure — the tool call is terminated before any permission layer is reached, consistent with a low-level posix_spawn failure.

What Should Happen?

Bash tool calls should execute regardless of how many sandbox deny/allow rules the user has configured. The bwrap invocation should not hit kernel argument length limits.

Suggested fixes (in order of preference):

1. Invoke bwrap directly with an argv array instead of wrapping it in /bin/bash -c "<string>". The current design forces the entire bwrap configuration into a single argument.
2. Pass bwrap configuration via --args-fd / --args <file> / stdin so the sandbox policy does not compete with argv space.
3. Deduplicate merged deny paths. Observed duplication: Read(//**/foo) and Read(**/foo) pattern pairs in permissions.deny appear to each expand into their own --tmpfs entries.
4. Reconsider the unconditional injection of proxy environment variables (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, FTP_PROXY, GIT_SSH_COMMAND, DOCKER_*, CLOUDSDK_PROXY_*, GRPC_PROXY, etc.) — these contribute ~25 --setenv entries per Bash call regardless of user setting.

Error Messages/Logs

Shape of the failing execve (sanitized; proxy env vars and internal mounts summarized):

execve("/bin/bash", ["/bin/bash", "-c",
  "bwrap --new-session --die-with-parent --unshare-net
   --bind <claude_http_sock> <claude_http_sock>
   --bind <claude_socks_sock> <claude_socks_sock>
   --setenv SANDBOX_RUNTIME 1
   --setenv TMPDIR <tmpdir>
   [~25 proxy-related --setenv entries omitted: HTTP_PROXY, HTTPS_PROXY,
    ALL_PROXY, FTP_PROXY, RSYNC_PROXY, DOCKER_HTTP_PROXY, DOCKER_HTTPS_PROXY,
    CLOUDSDK_PROXY_*, GRPC_PROXY, GIT_SSH_COMMAND,
    CLAUDE_CODE_HOST_HTTP_PROXY_PORT, CLAUDE_CODE_HOST_SOCKS_PROXY_PORT, ...]
   --ro-bind / /
   [several --bind entries for /tmp/claude-*, .npm/_logs, .claude/debug, workspace]
   [many --tmpfs / --ro-bind entries, one per denied path in
    sandbox.filesystem.denyRead + permissions.deny Read(...), which is the
    dominant contributor to the combined argument length]
   <user workload>"
  ], 0x... /* ~58 vars */
) = -1 E2BIG (Argument list too long)

Captured with:

strace -f -e trace=execve -s 2000 -o /tmp/claude-trace.txt -- \
  claude --dangerously-skip-permissions
# → accept warning → send "echo hello" → observe failure → Ctrl+D
grep "execve.*bash" /tmp/claude-trace.txt
grep "E2BIG" /tmp/claude-trace.txt

Steps to Reproduce

1. Use a recent WSL2 kernel on Windows.

2. In ~/.claude/settings.json, enable sandbox with a realistic deny configuration. Minimal reproducer uses roughly this shape — the total rule count across both sections matters more than specific paths:

   {
     "permissions": {
       "deny": [
         "Read(//**/.env)", "Read(**/.env)",
         "Read(//**/.env.local)", "Read(**/.env.local)",
         "Read(//**/*.pem)", "Read(**/*.pem)",
         "Read(//**/*.key)", "Read(**/*.key)",
         "Read(//**/secrets/**)", "Read(**/secrets/**)"
         // ... total ~30 patterns typical of a conservative production config
       ]
     },
     "sandbox": {
       "enabled": true,
       "filesystem": {
         "denyRead": [
           "**/.env", "**/.env.*",
           "**/secrets/**", "**/*.pem", "**/*.key"
           // ... plus typical host-level path patterns
         ],
         "allowRead": [
           "**/.env.example", "**/.git/config"
         ]
       }
     }
   }

3. Start a fresh Claude Code session (VS Code extension or CLI: claude --dangerously-skip-permissions).

4. Send any message that invokes the Bash tool, e.g. run echo hello.

5. Observe: the tool call fails immediately with Exit code 126 and [Request interrupted by user for tool use].

Minimal workaround confirmed: collapsing sandbox.filesystem.denyRead to a single broad entry (e.g. ["~/"]) with narrow allowRead carve-outs for the binaries/caches/paths actually needed reduces bwrap argv below the 128 KB threshold and restores Bash tool functionality.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.114 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment (minimal)

• Recent Microsoft WSL2 kernel (6.x series) on Ubuntu-based distro
• bubblewrap via standard distro package
• getconf PAGE_SIZE = 4096, so MAX_ARG_STRLEN ≈ 131072 bytes (128 KB)

Hypothesis on argument-length growth

The failing command string consists mostly of three categories:

1. Proxy --setenv (~25 entries) — auto-injected by Claude Code, not user-configurable. Roughly 4-6 KB.
2. Required --bind / --ro-bind (6-8 entries) — workspace + Claude's own runtime sockets / debug paths. Not user-adjustable.
3. --tmpfs per denied path — this is the dominant growth factor. Both permissions.deny Read(...) patterns and sandbox.filesystem.denyRead entries expand here, apparently without deduplication.

Users who enable a conservative sandbox with explicit denylists routinely have enough deny patterns (30+ patterns across permissions.deny and sandbox.filesystem.denyRead) to exceed the 128 KB threshold.

Related issues

• [BUG] Github actions not running due to E2BIG argument list too long #4488 — E2BIG in CI environments
• [BUG] Linux sandbox broken - bad bwrap calls and no allow permissions #17727 — Linux sandbox: bwrap invocation bug (mounts non-existent paths)
• sandbox.enabled: false setting ignored — bwrap still wraps all Bash commands #35986 — sandbox.enabled: false being ignored in 2.1.79

Other tools for comparison

• Cursor uses Landlock + seccomp directly (no bubblewrap wrapper command) — structurally immune to this failure mode. See Cursor's agent sandboxing blog post.
• OpenAI Codex uses a bubblewrap backend and reports structurally similar issues: Bubblewrap sandbox fails inside container for commands on bind-mounted host paths openai/codex#14976, Default bubblewrap sandbox is incompatible with standard unprivileged Replit workspaces and similar restricted container environments openai/codex#16018.

Severity

Medium-High. Users with realistic permissions.deny / sandbox.filesystem.denyRead configurations hit this on every Bash tool call, which blocks any shell-dependent workflow. The user-side workaround (replacing granular deny patterns with a single broad deny plus narrow allowRead carve-outs) resolves the symptom but reduces isolation granularity.

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Sandbox deny rules with mid-path globs cause E2BIG on Linux — per-file bwrap expansion instead of per-directory overlay #46461
2. [BUG] **/ glob prefix in deny rules causes massive context bloat on Linux/WSL but not macOS #46255

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[chenlundeaimi]

Thanks for the automated duplicate detection. After reviewing the two candidates, I believe this is related but not a duplicate of #46461, and unrelated to #46255 (which is about system-prompt / context bloat, not an execve failure). Leaving the distinction here so triage has the context.

Two separate Linux kernel limits apply to execve(2):

Limit	Value	Scope
ARG_MAX	2 MiB	Total size of argv + envp combined
MAX_ARG_STRLEN	PAGE_SIZE × 32 = 128 KiB	Per individual argument string length

Source: include/uapi/linux/binfmts.h.

#46461 reports ARG_MAX (2 MiB total) exceeded via per-file glob expansion producing thousands of --bind entries. Proposed fix: emit per-directory overlays instead of per-file bind-mounts (collapses many small argv entries into few).

This issue reports MAX_ARG_STRLEN (128 KiB per-argument) exceeded because Claude Code wraps the entire bwrap … invocation as a single -c string argument to /bin/bash:

execve("/bin/bash",
  ["/bin/bash", "-c", "bwrap <~40KB of flags> <user cmd>"],
  ...) = -1 E2BIG

Here total argv is well under 2 MiB, but the single argv[2] string crosses 128 KiB.

Why the distinction matters for remediation: even after #46461's per-directory overlay fix, if Claude Code keeps wrapping bwrap in bash -c "<full-command-string>", the remaining flags (~25 proxy --setenv entries, required binds, a handful of --tmpfs overlays) can still individually cross 128 KiB on configurations with moderate proxy env + moderate deny list. The two fixes are orthogonal:

1. [BUG] Sandbox deny rules with mid-path globs cause E2BIG on Linux — per-file bwrap expansion instead of per-directory overlay #46461's fix reduces the growth rate of the command string.
2. The fix proposed here (drop the bash -c wrapping — exec bwrap directly via argv array, or pass bwrap config via --args-fd / --args <file>) removes the per-argument limit entirely.

Happy to be wrong if this turns out to be a downstream symptom of #46461, but the strace in the OP shows only a single -c argument growing, not per-file --bind expansion, so the mechanism appears distinct.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[LN405Rx]

Still present in 2.1.201 — refiled per the close message as #74081