Windows Sandbox: Per-Exec Deny Flags / Claude Code v2.1.198

What

Windows sandbox commands now support per-exec denyRead and denyWrite path lists, matching Linux/macOS behavior.

Details

Previously, Windows sandbox was deny-listed only at the session level
Now individual exec calls can pass filesystem.denyRead and filesystem.denyWrite path arrays
filesystem.allowRead (re-allow within denyRead) is still not supported on Windows — remove entries or narrow denyRead
filesystem.allowWrite is still not supported on Windows (Windows sandbox uses deny-list only)

Evidence

Error messages (search for "Per-exec filesystem.allowRead (re-allow within denyRead) is not supported on Windows")

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

The build it came inv2.1.198

1 Jul 2026 · 26 entries, this one is #15.

Either side of it

Open the release →

Names in this entry

settingdenyRead
Under a relaxed sandbox filesystem policy, the outside-reads block does nothing and this is now logged.
settingfilesystem.denyRead
Your sandbox filesystem.denyWrite paths are now enforced in the sandbox mode used when a proxy port is configured, where they were ignored
settingfilesystem.denyWrite
Your sandbox filesystem.denyWrite paths are now enforced in the sandbox mode used when a proxy port is configured, where they were ignored
settingfilesystem.allowRead
On Linux, the sandbox glob warning now also checks filesystem.denyRead and filesystem.allowRead patterns that start at the root or have no fixed folder
settingallowWrite
The sandbox builder can produce a policy-only mode, but nothing visible switches it on.

Is this right?

Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.