[Feature Request] Native sandbox support for Windows (non-WSL)
Description
The /sandbox feature — the single most impactful security setting in Claude Code — is unavailable on native Windows. It uses Seatbelt on macOS and bubblewrap on Linux, but has no Windows equivalent.
Impact
Without sandbox, permission deny rules only block Claude's built-in tools. Bash commands bypass them entirely. For example, Read(~/.ssh/**) in the deny list prevents the Read tool from accessing SSH keys, but Bash(cat ~/.ssh/id_rsa) would still work. The sandbox is what enforces deny rules at the OS level — without it, deny rules are a partial mitigation at best.
Windows users currently have no path to full security enforcement.
Existing Windows sandbox issues
Current filed issues (#43840, #45072, #37371, #46354) are about sandbox breaking on Windows/WSL. This is a feature request for native Windows sandbox support that doesn't require WSL — potentially using Windows Sandbox, AppContainers, or similar OS-level isolation mechanisms.
Environment
- Claude Code 2.1.84
- Windows 10 Pro 10.0.19045
6 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate of the flagged issues.
deniedPathsbeing bypassed by the Bash tool — a permission enforcement bug on existing platforms.sandbox.filesystem.denyReadnot being enforced — another enforcement bug.This issue is a feature request for native Windows sandbox support. Currently sandbox uses Seatbelt (macOS) and bubblewrap (Linux) but has no Windows equivalent. Without sandbox, deny rules only block Claude's built-in tools — Bash commands bypass them entirely. Windows users have no path to full security enforcement.
The flagged issues are about sandbox/permissions not working correctly on platforms where they exist. This is about sandbox not existing at all on Windows (non-WSL).
Is there any progress or a timeline for when this will be adressed? The official documentation(https://code.claude.com/docs/en/sandboxing) only says that windows support ist planned, but this issue is marked as stale.
+1 on this. I've hit the same issue trying to keep Claude out of a secret-handling script on a Windows machine. I walked through a number of mitigations, but they are all very complex or add a ton of friction. Without OS-level enforcement, deny rules are brittle. On MacOS/Linux I've used tools that wrap BubbleWrap or SeatBelt and those have worked well. There's a lot of instances where WSL isn't an option like on cloud vm's where WSL isn't supported.
OpenAI recently shipped a Codex sandbox for native Windows (no WSL) using restricted tokens + ACLs + firewall, with the boundary following the process tree. It would be great if Claude could provide something similar.
https://openai.com/index/building-codex-windows-sandbox/
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
I built a first usable native sandbox for Claude on windows here: https://github.com/fmuecke/claude-win-sandbox
My usecase is "use Claude code with native windows C++ or C# toolchain (Visual Studio Pro Developer command prompt) while shielding it from me.
The scripts basically set up a low-priv local user and separate the agent's context from the real users. It also restricts the file access and limits access to regular network shares via explicit firewall rules.
The goal is not to have 100% protection but to effectively reduce the blast radius.
Feedback is highly welcome.