Exact error
Match the message before using the fix
bwrap: Can't mkdir /mnt/c/Users/.claude: Permission deniedbwrap: Can't mkdir /mnt/c/Users/.mcp.json: Permission deniedbwrap: Can't mkdir /mnt/c/.mcp.json: Permission deniedQuick answer
Start here
Do not create files under `C:\Users` or loosen that directory's permissions. In the confirmed reproduction, the failure appears when `/etc/claude-code/managed-settings.json` exists and disappears when a personally controlled test copy is moved aside. The upstream bug remains open. On managed machines, preserve the policy file and give the exact error and issue link to the administrator rather than removing organizational controls.
Diagnosis
Why it happens
- The report shows the sandbox constructing a Windows-mounted path without the username when managed settings are present.
- The reporter verified that `USERNAME` and `USERPROFILE` were correct, so changing those variables did not address the observed trigger.
- The path-construction mechanism is reporter analysis, not a maintainer-confirmed root cause.
Safest first
Fixes, in order
Confirm the exact managed-settings branch
Applies when: Before changing policy or filesystem permissions
This page applies to the unusual username-less `/mnt/c/Users/.claude` path, not every WSL permission error.
- Confirm the failing path is exactly `/mnt/c/Users/.claude`, `/mnt/c/Users/.mcp.json`, or `/mnt/c/.mcp.json`.
- Check whether `/etc/claude-code/managed-settings.json` exists.
- Record Claude Code version, WSL distribution, and the values of `USERNAME` and `USERPROFILE` without publishing personal data.
- Do not pre-create the username-less target path.
Expected: The error matches the open managed-settings reproduction rather than a normal ownership problem.
Escalate managed installations without bypassing policy
Applies when: Company, school, or administrator-managed devices
The file may enforce organizational security policy; removing it is not a safe end-user fix.
- Keep the managed settings file in place.
- Send the administrator the exact path, Claude Code version, WSL version, and upstream issue link.
- Ask the administrator to reproduce with an approved test policy and choose the permitted temporary execution environment.
- Avoid disabling the sandbox or changing permissions on `C:\Users`.
Expected: The policy owner can test or mitigate the open bug without weakening the host filesystem.
Use a reversible trigger test only on a personally controlled setup
Applies when: A local lab machine where you own and understand the managed-settings file
The reporter confirmed that moving the file out of the active path restored sandbox startup; this diagnoses the trigger but is not a permanent upstream fix.
- Back up `/etc/claude-code/managed-settings.json` with its permissions intact.
- Temporarily move it out of `/etc/claude-code`.
- Start a new Claude Code session and run a harmless sandboxed command.
- Restore the file after the test and document whether the error returns.
Expected: Removing and restoring the personally controlled test file changes the result consistently, confirming the open trigger.
Verification
Prove the fix worked
- Start a new session and run one harmless Bash command with sandboxing enabled.
- Confirm Claude Code no longer tries to create a username-less path under `/mnt/c/Users`.
- On a lab setup, restore the test file and verify whether the failure returns before reporting the reproduction.
Escalation
If it still fails
- Do not chmod `C:\Users`, create `/mnt/c/Users/.claude`, or permanently remove an administrator policy.
- Attach a minimal redacted managed-settings file only if organizational policy permits it.
- Track the open upstream issue for a fixed version; none was confirmed when this page was checked.
Scope
Environment and version notes
- The source report used Claude Code 2.1.217, WSL2 Ubuntu, and Windows 11.
- The issue remains open and the proposed path-construction cause has not been confirmed by a maintainer.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.