Claude Code's Sandbox Deny Rules Could Be Bypassed by Renaming the File
One line in the 2.1.236 changelog closes three separate ways to read a file a macOS sandbox rule had denied. All three worked because the rule was resolving a name, not guarding a file.
NeuroX AI · August 20, 2026
One line in the Claude Code 2.1.236 changelog closes three distinct holes in macOS sandbox enforcement. Wildcard read-deny rules like **/.env now take precedence inside allowed read regions, now cover matched directories' contents, and can no longer be bypassed by renaming the denied file.
Read the third one again. The file was denied; mv made it readable. The rule matched a path pattern, the sandbox resolved that pattern at read time, and a rename changed the answer. It was never protecting the secret. It was protecting the string .env.
The other two are the same bug wearing different clothes. A deny rule that loses to an allow rule inside its own region is a precedence bug. A directory pattern that matches the directory but not the files under it is a scope bug. Both produce a config that reads as protective and enforces nothing — the worst possible state for a guardrail, because nobody goes looking.
Same release, same shape elsewhere: auto mode's git status check "can no longer be fooled by a repo's status.showUntrackedFiles=no setting into reporting a clean tree." The check asked a question and trusted an answer supplied by the thing it was checking.
In-house agents are built almost entirely out of this pattern. The allowlist is a regex over a command string. The secret filter is a filename match. The safety gate asks the tool whether the tool did anything dangerous. None of those are wrong on the happy path — they just aren't controls.
A guardrail you have never tried to defeat is a guess.