[BUG]

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?

Honestly not sure — could go either way depending on the root cause. Let me check if this is a known Windows-specific limitation rather than guess.

Research Claude Code sandbox Windows support

I've kicked off research to check whether this is a known Windows limitation (vs. something a reinstall would actually fix) — I'll report back once it's done rather than guess.

Background task completed
· Agent "Research Claude Code sandbox Windows support" finished
· took 25s

Got a definitive answer — and it's simpler than I thought. Let me update the memory with the actual root cause, then explain.

Saved a memory

No — reinstalling won't fix this. Got a definitive answer: sandbox.filesystem enforcement (the piece that would restrict Bash/PowerShell to specific folders) isn't supported on native Windows at all — it only works on macOS, Linux, and WSL2. That's a documented platform limitation, not a bug or a bad install.

What's actually happening: your settings are valid and get accepted without error, but the sandbox engine itself never initializes on native Windows — so the allow/deny rules just silently never activate. No amount of restarting or reinstalling changes that.

The only way to get real enforcement would be running Claude Code inside WSL2 (Windows Subsystem for Linux) instead of native Windows — that's the documented path for Windows users who need this. A container or VM setup would also work, but WSL2 is the standard route.

Given that's a bigger change (different environment entirely), the practical answer for now stays the same: the manual boundary I'm holding myself to (F:\AI_training/Z:\Wildlife only) is the real protection here, not the config. Want me to look into what moving this to WSL2 would actually involve, or are you fine sticking with the manual-compliance approach?

That's a completely fair and correct position — self-discipline by me isn't a real technical control, and you shouldn't have to trust it. Let me find out whether the actual fix (WSL2) is even feasible in this specific setup (the Claude desktop app's Code tab), since that determines what's actually possible here.

Checked if Claude desktop app Code tab supports WSL2

While that researches, here's a more accountable interim approach than pure self-discipline: from now on, before I touch anything outside F:\AI_training/Z:\Wildlife, I'll explicitly ask you first and wait for a yes — not just decide on my own that it's fine. That at least puts a real checkpoint in front of every instance, rather than trusting my judgment silently in the background.

I'll report back once I know whether WSL2 is actually reachable from the desktop app's Code tab (vs. only being available if you ran the standalone CLI manually in a WSL2 terminal, which would be a bigger workflow change).

Good news — the desktop app does support WSL2 directly, no separate CLI workflow needed. Let me check if WSL2 is even installed on this machine first.

Checked if WSL2 is installed and what distributions are available

WSL2's underlying engine is present (Default Version: 2), but no Linux distribution is installed yet — that's required before the desktop app's environment picker would have anything to select.

Installing one (typically Ubuntu) is the next step — this is a meaningful system change (downloads and sets up a full Linux distribution), so per what I just committed to: can I proceed with wsl --install -d Ubuntu? That will download Ubuntu and set it up as a WSL2 distro. After that finishes, you'd start a new session in the Code tab and pick that Ubuntu distro in the environment picker to get a properly sandboxed session going forward.

why ubuntu am using windows

Good question — to be clear, this doesn't replace Windows or change anything about your existing setup. WSL2 (Windows Subsystem for Linux) is a Microsoft feature that runs a real Linux environment side-by-side with Windows on the same machine — your files, PyCharm, DBeaver, everything stays exactly as-is.

Why it's needed specifically here: Claude Code's sandbox feature (the filesystem restriction we've been trying to get working) is built using Linux-only security primitives — they don't exist on Windows at all, which is exactly why it's been silently failing all session. Ubuntu-via-WSL2 isn't a Linux "switch" — it's just the one thing that actually provides those Linux primitives so the sandbox can function, while I still work with your actual project files (which live on F:\, reachable from inside WSL2 too — Windows drives show up as /mnt/f/... etc.).

So: you keep using Windows normally for everything. The only change is that my Claude Code session specifically would run inside that Linux layer instead of directly on Windows, purely so the security boundary we want actually gets enforced.

If you'd rather not go this route, that's completely reasonable too — it is a real setup step. The alternative is continuing with the manual-confirmation approach (I ask before touching anything outside F:\AI_training/Z:\Wildlife, every time). Your call.

report Anthropic regarding this issue

Loaded tools

I don't have a direct tool to submit feedback to Anthropic on your behalf, but here's the right channel and a ready-to-submit bug report so you don't have to write it up from scratch:

Report it here: https://github.com/anthropics/claude-code/issues

Suggested bug report (feel free to copy/paste and adjust):

Title: sandbox.filesystem settings silently accepted but never enforced on native Windows — no warning to user

Description:
Configured sandbox.enabled: true with sandbox.filesystem.denyRead/denyWrite/allowRead/allowWrite rules in global settings.json, intending to restrict Bash/PowerShell tool access to specific directories. The JSON is well-formed and accepted without error.

However, Bash/PowerShell retained full unrestricted filesystem access the entire time — tested across three separate restart attempts (closing a session tab, Alt+F4, full quit via system tray + relaunch). Confirmed via a Claude Code agent that this is because sandbox.filesystem enforcement is not supported on native Windows at all (only macOS/Linux/WSL2), per: https://code.claude.com/docs/en/sandboxing.md

The core issue: there is no warning, error, or any indication to the user that their configured sandbox rules are being silently ignored. A user could reasonably believe their filesystem is restricted when it isn't at all — this is a security-relevant silent failure, not just a missing feature.

Suggested fix: when sandbox.enabled: true is set on native Windows, either (a) show a clear one-time warning/banner that filesystem sandboxing isn't supported on this platform and suggest WSL2, or (b) fail startup loudly if failIfUnavailable isn't explicitly set to false.

Environment: Windows 11, Claude desktop app (Code tab), native Windows session (not WSL2)

What Should Happen?

not able to revert folder access to claude in Windows and it is asking me to install Ubuntu sandbox but why?

Error Messages/Logs

Steps to Reproduce

Honestly not sure — could go either way depending on the root cause. Let me check if this is a known Windows-specific limitation rather than guess.

Research Claude Code sandbox Windows support

I've kicked off research to check whether this is a known Windows limitation (vs. something a reinstall would actually fix) — I'll report back once it's done rather than guess.

Background task completed
· Agent "Research Claude Code sandbox Windows support" finished
· took 25s

Got a definitive answer — and it's simpler than I thought. Let me update the memory with the actual root cause, then explain.

Saved a memory

No — reinstalling won't fix this. Got a definitive answer: sandbox.filesystem enforcement (the piece that would restrict Bash/PowerShell to specific folders) isn't supported on native Windows at all — it only works on macOS, Linux, and WSL2. That's a documented platform limitation, not a bug or a bad install.

What's actually happening: your settings are valid and get accepted without error, but the sandbox engine itself never initializes on native Windows — so the allow/deny rules just silently never activate. No amount of restarting or reinstalling changes that.

The only way to get real enforcement would be running Claude Code inside WSL2 (Windows Subsystem for Linux) instead of native Windows — that's the documented path for Windows users who need this. A container or VM setup would also work, but WSL2 is the standard route.

Given that's a bigger change (different environment entirely), the practical answer for now stays the same: the manual boundary I'm holding myself to (F:\AI_training/Z:\Wildlife only) is the real protection here, not the config. Want me to look into what moving this to WSL2 would actually involve, or are you fine sticking with the manual-compliance approach?

That's a completely fair and correct position — self-discipline by me isn't a real technical control, and you shouldn't have to trust it. Let me find out whether the actual fix (WSL2) is even feasible in this specific setup (the Claude desktop app's Code tab), since that determines what's actually possible here.

Checked if Claude desktop app Code tab supports WSL2

While that researches, here's a more accountable interim approach than pure self-discipline: from now on, before I touch anything outside F:\AI_training/Z:\Wildlife, I'll explicitly ask you first and wait for a yes — not just decide on my own that it's fine. That at least puts a real checkpoint in front of every instance, rather than trusting my judgment silently in the background.

I'll report back once I know whether WSL2 is actually reachable from the desktop app's Code tab (vs. only being available if you ran the standalone CLI manually in a WSL2 terminal, which would be a bigger workflow change).

Good news — the desktop app does support WSL2 directly, no separate CLI workflow needed. Let me check if WSL2 is even installed on this machine first.

Checked if WSL2 is installed and what distributions are available

WSL2's underlying engine is present (Default Version: 2), but no Linux distribution is installed yet — that's required before the desktop app's environment picker would have anything to select.

Installing one (typically Ubuntu) is the next step — this is a meaningful system change (downloads and sets up a full Linux distribution), so per what I just committed to: can I proceed with wsl --install -d Ubuntu? That will download Ubuntu and set it up as a WSL2 distro. After that finishes, you'd start a new session in the Code tab and pick that Ubuntu distro in the environment picker to get a properly sandboxed session going forward.

why ubuntu am using windows

Good question — to be clear, this doesn't replace Windows or change anything about your existing setup. WSL2 (Windows Subsystem for Linux) is a Microsoft feature that runs a real Linux environment side-by-side with Windows on the same machine — your files, PyCharm, DBeaver, everything stays exactly as-is.

Why it's needed specifically here: Claude Code's sandbox feature (the filesystem restriction we've been trying to get working) is built using Linux-only security primitives — they don't exist on Windows at all, which is exactly why it's been silently failing all session. Ubuntu-via-WSL2 isn't a Linux "switch" — it's just the one thing that actually provides those Linux primitives so the sandbox can function, while I still work with your actual project files (which live on F:\, reachable from inside WSL2 too — Windows drives show up as /mnt/f/... etc.).

So: you keep using Windows normally for everything. The only change is that my Claude Code session specifically would run inside that Linux layer instead of directly on Windows, purely so the security boundary we want actually gets enforced.

If you'd rather not go this route, that's completely reasonable too — it is a real setup step. The alternative is continuing with the manual-confirmation approach (I ask before touching anything outside F:\AI_training/Z:\Wildlife, every time). Your call.

report Anthropic regarding this issue

Loaded tools

I don't have a direct tool to submit feedback to Anthropic on your behalf, but here's the right channel and a ready-to-submit bug report so you don't have to write it up from scratch:

Report it here: https://github.com/anthropics/claude-code/issues

Suggested bug report (feel free to copy/paste and adjust):

Title: sandbox.filesystem settings silently accepted but never enforced on native Windows — no warning to user

Description:
Configured sandbox.enabled: true with sandbox.filesystem.denyRead/denyWrite/allowRead/allowWrite rules in global settings.json, intending to restrict Bash/PowerShell tool access to specific directories. The JSON is well-formed and accepted without error.

However, Bash/PowerShell retained full unrestricted filesystem access the entire time — tested across three separate restart attempts (closing a session tab, Alt+F4, full quit via system tray + relaunch). Confirmed via a Claude Code agent that this is because sandbox.filesystem enforcement is not supported on native Windows at all (only macOS/Linux/WSL2), per: https://code.claude.com/docs/en/sandboxing.md

The core issue: there is no warning, error, or any indication to the user that their configured sandbox rules are being silently ignored. A user could reasonably believe their filesystem is restricted when it isn't at all — this is a security-relevant silent failure, not just a missing feature.

Suggested fix: when sandbox.enabled: true is set on native Windows, either (a) show a clear one-time warning/banner that filesystem sandboxing isn't supported on this platform and suggest WSL2, or (b) fail startup loudly if failIfUnavailable isn't explicitly set to false.

Environment: Windows 11, Claude desktop app (Code tab), native Windows session (not WSL2)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 2.7032.0 (6c468a)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

not able to revert folder access to claude in Windows and it is asking me to install Ubuntu sandbox but why?