Claude Code v2.1.323 · 12 Nov 2026
Sandbox withholds write access to paths that could be redirected
The Windows and Linux sandbox now refuses an allowWrite grant whose path leads elsewhere or to nothing yet, and logs why
You'll notice Tier: how much it should matter to you
2 Useful: my rating, 1 to 5
1 Signal: worth watching, 1 to 5
Sandbox Area: what it touches
Improvements Kind: in v2.1.323, 12 Nov 26
Improvements Section of the release
Unclear Whether this check applies to every sandbox setup or only some.
What
The sandbox now holds back an allowWrite grant (a path you allowed sandboxed commands to write to) when that path does either of these:
leads somewhere other than its own spelling, for example through a shortcut-style link
leads to nothing that exists yet
In both cases a sandboxed command could re-point the path somewhere else. The log notes the grant as withheld and suggests spelling the grant by its real path.
Separately, when blockReadsOutsideWorkingDirectories applies, one more configuration folder is added to the folders re-opened despite denyRead .
Why
Write access granted through a redirectable path is now stricter. If a write grant stops working, list the real folder rather than a link to it.
How sure we are
Something disagrees Something we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt Whether this check applies to every sandbox setup or only some.
Anthropic's release notes agree Fixed a case where the Write and Edit tools could write to a path covered by a Read deny rule
See this entry in the whole of v2.1.323 →
12 Nov 2026 · 888 entries, this one is #309.
Use it now77 You'll notice533 Nothing to try yet64 Under the hood214
Open the release →
Names in this entry
setting allowWrite The sandbox builder can produce a policy-only mode, but nothing visible switches it on.
setting blockReadsOutsideWorkingDirectories A new permissions setting blocks any file read outside your working directories, in prompts and in the sandbox.
setting denyRead Under a relaxed sandbox filesystem policy, the outside-reads block does nothing and this is now logged.
Anthropic's note
Upstream's own release notes for v2.1.323 name something this entry names, so the two are probably about the same change. Probably: the pairing is made on a shared name rather than on the words around it.
Fixed a case where the Write and Edit tools could write to a path covered by a Read deny rule
Is this right?
0
0
Feedback
What's wrong with this entry?
Hard to understand Too vague Looks wrong Not relevant to me Too long Missing the detail I wanted Duplicate of another card
Clear Learned something new I can act on this Good catch
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
← Previous · 308 of 888
Background sessions start with more environment variables removed
You'll notice Sessions
In v2.1.323 Improvements release-page order
Next → · 310 of 888
File edits and writes resist a folder being swapped for a link
You'll notice File Tools