Claude Code 2.1.269 shipped on 11 September 2026 with fixes for a set of permission-bypass bugs that let the tool get around deny-rules configured for Edit, Write and Read — the exact controls teams use to stop the agent from touching secrets, .env files or specific directories.
If you've configured a deny-rule in Claude Code at any point before that date, it's worth assuming it did not fully hold.
What actually broke
The 2.1.269 release notes describe four distinct ways a configured deny-rule could be silently circumvented: parenthesized file paths that slipped past the pattern matcher, symlinked system directories such as /etc, /tmp, /var and .git that resolved differently than the literal path being checked, unclosed bracket patterns in path-matching rules, and using tee or shell redirection to write to a path an Edit() deny-rule was supposed to block. None of these are cosmetic. Each one describes a case where a rule a team believed was blocking access to a given path was not actually blocking it.
The context: a week of visible progress, then a quieter fix
The same release cadence that produced 2.1.269 followed close behind version 2.1.260, shipped on 3 September 2026, which added a fullscreen /diff panel showing live uncommitted edits — a genuinely useful feature for reviewing what Claude Code has changed before you commit it, covered at the time by Pondero and DevelopersIO. The permission fixes eight days later got far less attention, which is typical: security patches to permission systems rarely get the same coverage as a new UI panel, even when they matter more to anyone running the tool with restricted access.
Why this matters even if nothing bad happened to you
The bypass techniques were general, not exploit chains built against a specific target — a parenthesized path or a tee redirection is something Claude Code itself might attempt in the ordinary course of working through a task, not something requiring an attacker. If you had a deny-rule blocking access to /etc, a .git directory, or a path containing parentheses, and Claude Code needed to touch something adjacent to that path while doing legitimate work, there was a real chance the rule didn't do what you assumed. That's a different risk profile from a targeted vulnerability: the failure could have happened quietly, in the middle of ordinary use, without anyone noticing at the time.
What to actually do now
First, update to Claude Code 2.1.269 or later — check your version and don't defer this the way you might defer a UI update. Second, go back through any permission or deny-rule configuration your team has in place and specifically check whether it relies on blocking a symlinked path, a parenthesized path, a bracket pattern, or blanket Edit() denial without also restricting shell access. If any of your rules use those patterns, treat the period before 11 September as a window where the rule may not have held, and check logs or file history for the paths in question if that's feasible. Third, if you don't already log what Claude Code actually writes and where, this is a reasonable moment to add that, since a deny-rule failing silently is only a problem you can respond to if you can tell it happened.
The general lesson: deny-rules are one layer, not the whole wall
Permission systems inside AI coding agents are still new, and bypass bugs like this one should be expected to recur — not because Anthropic is careless, but because the surface area (path matching, symlink resolution, shell redirection, tool composition) is large and adversarial testing of it is still catching up. The practical response isn't to distrust Claude Code specifically; it's to stop treating a client-side deny-rule as a sufficient control for anything genuinely sensitive. For secrets, credentials, or production configuration, pair the deny-rule with something that doesn't depend on the agent's own path-matching logic being correct: a read-only filesystem mount, a container boundary the process can't cross, or a separate credential store the agent's process never has filesystem access to at all. A deny-rule is convenient and worth keeping, but it should sit alongside a layer that would still hold even if the next bypass bug looks nothing like these four.
The bottom line
Claude Code 2.1.269, released 11 September 2026, fixed four ways a configured deny-rule on Edit, Write or Read could be silently bypassed — parenthesized paths, symlinked system directories, unclosed bracket patterns and shell redirection around Edit(). Update to 2.1.269 or later now, audit any deny-rule you have that touches those patterns, and put a layer behind it — read-only mounts or containerisation — that doesn't depend on the agent's permission logic being correct.