[BUG] /sandbox reports as unsupported in Linux when run under WSL2

[ianfiske]

Preflight Checklist

• [ ] I have searched existing issues and this hasn't been reported yet (issue by another user was erroneously closed without investigation)
• [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?

> /sandbox 
  ⎿ Error: Sandboxing is currently only supported on macOS and 
    Linux

even though

$ uname -a
Linux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

What Should Happen?

/sandbox should enable sandbox mode

Error Messages/Logs

Steps to Reproduce

Start Ubuntu in WSL2 under Windows 11. start claude do /sandbox

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.28

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

I am re-opening https://github.com/anthropics/claude-code/issues/10038 because this was closed without a valid explanation.

WSL2 is Linux and all other Linux commands do work. Please confirm if sandbox functionality can be enabled in WSL2. This is a major feature for Windows users who rely on WSL to give a great developer experience inside of Windows.

[github-actions[bot]]

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/10038

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

[Konamiman]

I can confirm that the bug is present even after running sudo apt install bubblewrap in WSL (as bubblewrap is documented as being the underlying mechanism for sandboxing).

[Konamiman]

From Claude Code itself:

---

Technical Analysis of WSL2 Sandbox Detection Issue

I've done some reverse engineering of the Claude Code binary to understand why sandboxing is rejected on WSL2 despite it being functionally equivalent to native Linux.

Investigation Findings

Platform Detection Logic (from cli.js):

F0Q(A){return["macos","linux"].includes(A)}

The code checks if the platform is in the allowed list ["macos","linux"], and for Linux specifically, it verifies that bwrap and socat are available.

System Status on WSL2:

$ node -e "console.log(process.platform)"
linux  ✓

$ uname -a
Linux LAPTOP-Q5I0LUG8 6.6.87.2-microsoft-standard-WSL2 ...

$ which bwrap && which socat
/usr/bin/bwrap  ✓
/usr/bin/socat  ✓

All prerequisites are met:

• ✅ process.platform returns "linux"
• ✅ bwrap is installed and available
• ✅ socat is installed and available

Root Cause:

Despite Node.js correctly identifying WSL2 as Linux (process.platform === "linux"), Claude Code appears to have an additional check that explicitly rejects WSL environments. This is likely done by:

1. Checking /proc/version for "microsoft" or "WSL" strings, OR
2. Examining os.release() which returns "6.6.87.2-microsoft-standard-WSL2", OR
3. Some other WSL-specific detection mechanism

The platform detection function HB() must be returning something other than "linux" when it detects WSL, causing the F0Q() check to fail.

Conclusion:

This appears to be an intentional but overly restrictive check. WSL2 is a legitimate Linux environment with full system call compatibility, and the required sandboxing tools (bwrap, socat) work correctly on it.

Recommendation: Relax the platform check to allow WSL2, or at minimum provide a way for users to override this restriction with an environment variable or config flag.

[JayDoubleu]

This might be because of :

/tmp node -p "require('os').release()"
5.15.167.4-microsoft-standard-WSL2

Claude code looks at that kernel release string, sees "microsoft" or "WSL", and throws the error? It would be great to fix as WSL2 is microVM and bubblewrap should work on it without issues

[H4ST3]

Are there any updates regarding this? It seems to be a pretty large security hole for a large community of users.