On macOS, granting write access to a folder no longer reopens files you denied inside it.
What's wrong with this entry?
The macOS sandbox profile is now assembled from explicit allow, deny and writable-root lists, and adds a further section that reinstates your denials for any path that happens to sit inside a folder Claude Code is allowed to write in. Granting write access to a directory no longer quietly reopens a file you had denied reads on inside it, and denied paths under a writable root can no longer be deleted or unlinked.
- Rules that deny a path outright, or allow it only inside an otherwise denied area, are converted into both read denials and delete/unlink denials scoped to the writable roots.
- Glob patterns in those rules are expanded into regular expressions matching the folder itself and everything beneath it.
- The parent directory of each glob-based denial is added as its own literal entry, so the containing folder is covered as well as its contents.
- Paths you explicitly allowed get carve-outs in the generated profile and stay writable.
- The re-application step is marked in the profile itself with the comment
; File read: keep read-denied paths inside write roots in place, and the delete rules use the sandbox operation namedfile-write-unlink.
; File read: keep read-denied paths inside write roots in place, file-write-unlink
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.239
Sandboxed CLIs get placeholder credentials so they route through the agent proxy
Both mention sandbox
-
v2.1.239
Per-tool memory limits detect an outer cgroup already in place
Both mention sandbox
-
v2.1.239
Memory limits on Linux notice when the process is already inside a managed group
Both mention sandbox