Claude Code Closes a Bash Deny-Rule Gap and a Silent Policy-Enforcement Failure
Claude CodeClaude Code 2.1.259, released September 2, 2026, closed two more narrow gaps in how the tool enforces rules a user or an organization had already configured. A Bash Read() deny rule protecting a file such as .env previously did not cover that file when it appeared as an option value, as a git diff or git grep file operand, or inside a directory read by grep -r or cp -r, letting a crafted command read a supposedly blocked file without ever triggering the approval prompt. Separately, Anthropic changed what happens when a managed-settings file, a drop-in, an MDM plist, or a Windows registry value cannot be parsed: instead of silently starting the session with the organization's policy unenforced, Claude Code now refuses to start and names the broken source. Both fixes continue a pattern of weekly, narrow corrections to the permission and policy-enforcement layer that Anthropic has been shipping through August and into September.
Key Takeaways
- A single deny rule now covers more command shapes, closing gaps where a protected file could be reached via an option value, a
git diff/git grepoperand, or acd DIR && cat FILEcompound. - Recursive commands over a protected directory now ask first:
grep -rorcp -rspanning a denied file no longer runs without a prompt. - Managed settings now fail closed: a parse error in a managed-settings file, drop-in, MDM plist, or HKLM value stops Claude Code from starting instead of silently running unrestricted.
- The failure names its source, so an administrator debugging a broken managed-settings rollout gets a specific file or value to fix rather than a generic error.
- This is the latest in a recurring weekly cluster of permission and sandbox hardening fixes Anthropic has shipped through August and into September 2026.
- Sourcing outside official channels is thin for this entry, reflecting how granular these particular fixes are relative to the larger multi-item patch clusters that tend to draw broader tech-press coverage.
Sources & Mentions
2 external resources covering this update
A Deny Rule That Didn't Cover Every Way to Reach the File
Claude Code's permission system lets a user or an organization write a Read() deny rule to block a file such as .env or a credentials file from being read at all, no matter which tool touches it. Before 2.1.259, that protection had gaps a crafted command could slip through. A deny rule did not apply when the protected file was passed as an option value, patterns like --ignore-revs-file=.env, -f.env, or @file all reached the file without tripping the rule. It also did not apply to a file named as an operand to git diff or git grep, or to a compound command like cd DIR && cat FILE. On top of that, running grep -r or cp -r over a directory that happened to contain a denied file did not ask for approval before touching it.
Anthropic closed all of these paths in the same release: any of those forms now triggers the same "asks" behavior a direct read of the file would have triggered. The practical effect is that a deny rule written to protect a secret now actually protects it against a wider set of everyday command shapes, not just the most literal one.
Managed Settings Now Fail Closed Instead of Silently Doing Nothing
The second fix addresses what happens when an organization's managed settings, delivered through a managed-settings file, a drop-in file, an MDM-pushed plist on macOS, or an HKLM registry value on Windows, cannot be parsed. Previously, a parse failure in any of those sources meant the settings simply went unenforced without any signal to the user or administrator: a session could start and run under weaker rules than the organization intended, with nothing on screen to say why.
Claude Code 2.1.259 changes that behavior to fail closed: if the managed-settings source cannot be parsed, Claude Code now refuses to start at all, and names exactly which source failed to parse. That turns a silent policy gap into a loud, actionable failure, which matters because a managed-settings file is often the only place an organization's security team can enforce restrictions on a fleet of developer machines.