[BUG] Under WSL2, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB forces sandbox on and bwrap fails trying to bind-mount the Windows managed-settings path

Preflight Checklist

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

What's Wrong?

Summary

On WSL2, when CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set in the environment, the bubblewrap sandbox is forced on for every Bash tool call and fails at startup with:

bwrap: Can't mkdir /mnt/c/Program Files/ClaudeCode: Permission denied

Every Bash call fails identically — the shell escape (!) fails the same way. The environment has no sandbox.enabled: true anywhere in user, project, or managed settings; the sandbox is being turned on solely by the env var.

## Environment

• OS: Linux 6.18.33.2-microsoft-standard-WSL2 (Ubuntu on WSL2)
• Claude Code versions tested: 2.1.187, 2.1.209, 2.1.217 — bug reproduces on all three
• Install method: native (per ~/.claude.json)
• No user, project, or managed sandbox settings
• Windows host does not have C:\Program Files\ClaudeCode on disk (Claude Code was never installed on the Windows side; only inside WSL)

## Root cause hypothesis

Two default-policy rules interact badly on WSL:

1. Per the sandboxing docs, setting CLAUDE_CODE_SUBPROCESS_ENV_SCRUB forces filesystem isolation on regardless of sandbox.enabled in any settings scope.
2. The sandbox's built-in "protect the managed-settings directory" deny rule includes both the Linux path (/etc/claude-code/managed-settings.json + .d) and the Windows path (C:\Program Files\ClaudeCode\managed-settings.json +

.d), regardless of the runtime platform.

Under WSL, C:\Program Files\ClaudeCode resolves to /mnt/c/Program Files/ClaudeCode. bwrap tries to bind-mount that path into the sandbox and, because the directory doesn't exist on this host, attempts to mkdir it. That fails because
/mnt/c/Program Files/ is not writable from the WSL user account.

The sandbox should not attempt to enforce a deny rule on a Windows-side path when running under Linux/WSL — the Windows managed-settings location is only meaningful for a Windows-native Claude Code install, which cannot coexist with a
Linux/WSL Claude Code install in the same process.

## Workarounds

For anyone hitting this before it's fixed:

• Unset CLAUDE_CODE_SUBPROCESS_ENV_SCRUB: removes the credential-scrubbing protection but restores Bash. (This is what I did.)
• Create the directory on the Windows side: mkdir "C:\Program Files\ClaudeCode" from a Windows admin shell — empty directory is enough to satisfy bwrap.

What Should Happen?

Successful Bash calls when CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1

Error Messages/Logs

bwrap: Can't mkdir /mnt/c/Program Files/ClaudeCode: Permission denied

Steps to Reproduce

1. Fresh WSL2 with Claude Code installed via curl -fsSL https://claude.ai/install.sh | bash (any 2.1.x tested).
2. Ensure C:\Program Files\ClaudeCode does not exist on the Windows host (default when Claude Code isn't installed on Windows).
3. Set CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 in the shell before launching claude.
4. Start a Claude Code session and ask the model to run any Bash command (e.g. pwd).

Expected: command runs (sandbox is either off, or on but tolerates a missing managed-settings directory).

Actual: every Bash tool call fails with bwrap: Can't mkdir /mnt/c/Program Files/ClaudeCode: Permission denied. The dangerouslyDisableSandbox retry path also fails identically — bwrap is still invoked.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.217

Platform

Other

Operating System

Other Linux

Terminal/Shell

Windows Terminal

Additional Information

_No response_