Claude Code's Permission Patches, Explained: What 2.1.289 to 2.1.296 Actually Fixed

Anthropic shipped eight versions of Claude Code in roughly five days, 2.1.289 through 2.1.296, and the changelog for that run reads less like a feature cadence and more like an incident response log. According to the project's own changelog, at least a dozen of the individual line items across those eight releases are permission or sandbox fixes, several described explicitly as closing a way for a tool call to execute, or a file to be read, without the approval the user's settings should have required. One, in 2.1.292, is labeled directly in the changelog as a security fix: PreToolUse hook approvals and auto mode could bypass the permission prompt for reads from UNC network paths.

If you run Claude Code against real client codebases, as most of our engineering team does daily, this is not an abstract changelog curiosity. A permission system for an agentic coding tool only matters if it holds under the specific, slightly weird inputs an engineer or a misconfigured script will eventually throw at it. Looking at eight releases of patches to the same subsystem in sequence tells you more about where that system is structurally fragile than any single release note does on its own.

The pattern: three distinct ways a deny rule stopped applying

Reading the eight releases together, the bypasses cluster into three mechanical categories, and each one is worth understanding on its own because each implies a different class of audit for your own setup.

Indirection through the filesystem. 2.1.289 fixed Read deny rules not applying when a file was reached through a symlink, whether that symlink came from an IDE selection, an @-mention, or a changed link mid read. 2.1.290 extended this to CLAUDE.md files opened through a symlink and to @-mentions through a link altered between the check and the read. 2.1.292 closed the same category for notebook and PDF reads on macOS and Windows, where a linked file could be swapped mid read to return something outside the approved set. The common thread: a deny rule written against a path string does not automatically cover every way the filesystem can resolve to that path, and a tool that checks the path you asked for rather than the file you actually got will miss this every time.

Indirection through shell semantics. 2.1.289, 2.1.290, and 2.1.296 all patched variations of the same underlying problem: a Bash command whose dangerous part is hidden behind an environment variable assignment, a declare, typeset, export, or readonly prefix, or in 2.1.296's case, the BASH_ARGV0 variable, could get auto approved under sandbox auto allow instead of being evaluated against deny and ask rules. This is the classic shell parsing problem: a permission checker that pattern matches against the literal command string has to account for every way bash lets you construct that string indirectly, and attackers, or more realistically, legitimate but unusual scripts, will keep finding the ones you missed.

Indirection through protocol and transport. 2.1.292's UNC path fix and 2.1.295's host:80 site deny rule fix for Claude in Chrome are both the same category at a different layer: a permission rule written for one transport or protocol representation of a resource did not automatically extend to an equivalent representation reached a different way.

What to actually audit in your own deployment

None of these patches require you to do anything if you keep Claude Code current, which is the straightforward fix and the one we recommend to clients running it in CI or on shared infrastructure. But the pattern is worth translating into a short audit checklist if your organization has written custom deny or ask rules on top of the defaults, because custom rules are exactly where this class of bug reappears.

First, if you have deny rules referencing specific file paths, check whether any of those paths are, or could become, symlinks in your repository layout. A deny rule on .env does nothing if a developer's local setup symlinks .env from a location your rule does not cover. Second, if you have Bash ask or deny rules written as literal command prefixes, assume an environment variable indirection exists that your rule does not anticipate, and prefer rules on the resolved command where your tooling supports it. Third, if your team runs Claude Code against UNC paths, network shares, or through Claude in Chrome with site level deny rules, re-verify those specific configurations against the current version rather than assuming an old test still holds.

When this applies to your stack

If your engineering org has standardized on Claude Code, as a growing share of the market has, the practical takeaway is narrower than "audit everything": keep the CLI current, treat custom permission rules as code that needs the same kind of adversarial review your actual application code gets, and assume indirection, through symlinks, shell variables, or alternate path syntax, is the first place a rule will quietly stop applying. Teams running agentic coding tools at scale across client environments, which is most of what we do for infrastructure clients adopting Claude Code or comparable agentic IDEs, should treat this release run as a reminder to re-run their own permission configuration against a current build rather than a one time setup. If you want a second set of eyes on how your organization has configured agentic coding tool permissions across a shared engineering environment, that is squarely the kind of AI integration and agent engineering work we do with clients.

FAQ

Is Claude Code unsafe to use after this many security related patches? No. The volume of fixes reflects an unusually permission heavy subsystem getting unusually close scrutiny, which is the behavior you want from a vendor, not a reason to avoid the tool. The alternative, a permission system that never gets this kind of adversarial testing, is worse.

Do I need to change my settings after these patches? If you are only using Claude Code's default permission settings, no action is required beyond updating to a current version. If you have written custom deny or ask rules, re-test them specifically against symlinks and environment variable indirection.

Were any of these bugs exploited in the wild? The changelog does not state that, and nothing in the public release notes claims active exploitation. They read as proactively discovered and patched issues.

How does this compare to permission handling in Cursor or GitHub Copilot? Cursor and Copilot have different permission models and we are not aware of a comparably detailed public changelog of permission specific fixes for either tool over the same window, which makes a direct comparison difficult to make responsibly. The more useful comparison is whether your chosen tool's vendor publishes this level of changelog detail at all.

What is BASH_ARGV0 and why does it matter here? It is a Bash variable that lets a script override what $0 reports for a command, which can be used, intentionally or not, to make a command's effective behavior diverge from what its literal name suggests. 2.1.296 made Claude Code's permission checks prompt rather than auto approve when a command assigns and uses it.