Native Windows: working directory does not scope shell-tool filesystem access

Claude Code (native Windows): working directory does not scope shell-tool filesystem access

Summary

On native Windows, Claude Code's Bash/PowerShell tools can read and write any path
the OS user can reach — including network (UNC) shares far outside the configured
working directory — without OS-level restriction. The "working directory" framing
implies a boundary that does not actually constrain shell commands on Windows, which
is a safety surprise when operating near shared/multi-user storage.

Environment

• Claude Code on native Windows 11 (not WSL2)
• Working directory: a local project folder on the Desktop
• Storage involved: a shared group SMB/UNC share (\\server\share\...) with

per-owner subfolders; the user only "owns" a few of them

Observed behavior

• With the working directory set to a local Desktop folder, the assistant's

PowerShell tool was able to enumerate, create, and delete files on an unrelated
UNC share outside the working directory, with no OS-level block.

• The user (correctly) expected the working directory to limit scope and was

surprised that shell tools were unconstrained.

Why this matters

• Read/Edit/Write tools honor a working-directory prompt boundary, but **raw shell

commands do not — and on native Windows there is no filesystem sandbox**
(sandboxing is macOS/Linux/WSL2 only).

• permissions.deny/allow rules gate shell commands only at the Claude layer

(prompt/refuse before the call) and match on the command string; they are not
kernel-enforced on Windows and are brittle for free-form shell.

• Net effect: on shared/multi-user Windows storage, a mistaken glob, path typo, or

over-broad recursive command could modify other people's data, and nothing at the
OS level prevents it.

Requests

1. In docs/UI, make explicit on native Windows that shell tools are not

scope-limited to the working directory (the current framing invites the opposite
assumption).

1. Offer a path-scoped write-enforcement option for shell tools on native Windows

that does not require migrating to WSL2 (e.g., an allow/deny list enforced before
command execution, or an opt-in restricted-FS mode).

1. Consider a startup warning when the working directory is on, or has easy access to,

a network/multi-user share.

References

• Sandboxing (macOS/Linux/WSL2 only): https://code.claude.com/docs/en/sandboxing.md
• Permissions: https://code.claude.com/docs/en/permissions.md
• Permission modes: https://code.claude.com/docs/en/permission-modes.md
• Security model: https://code.claude.com/docs/en/security.md

Workaround we adopted

A script-level allowlist guard (canonicalize path, then require it to sit under an
explicit set of owned roots; block everything else, including .. traversal and
prefix look-alikes) routed through safe wrappers for every mutating operation.