Claude Code closed permission bypasses: update before relying on deny rules

Many teams use Claude Code's permission rules as policy: deny rules for destructive commands, ask rules for anything that touches production, and managed settings so developers cannot loosen them. Between 3 and 14 October 2026, a run of Claude Code releases fixed cases where those rules could be skipped. None of the fixes came with a CVE identifier, and most are one line in a long changelog, so they are easy to miss. Teams that rely on deny rules should make sure every machine is on a recent version, and retest their rules with the patterns the fixes describe.

The context: what was fixed

The Claude Code changelog and the GitHub release notes list the fixes. The most relevant, by version:

2.1.289, 3 October. Two fixes concern the sandbox's auto-allow setting. One fixed "Bash deny and ask rules missing a command behind an environment variable prefix with an expanded value (e.g. TZ="$HOME" rm -rf build) when the sandbox auto-allows commands". Another fixed a deny or ask rule being skipped under sandbox auto-allow when a bare variable assignment came before the command. The same release fixed a deny or ask rule on a nested part of a compound command not holding over a user-installed mod's approval on managed machines, and Read deny rules not applying to files reached through a symlink from the IDE.

2.1.290, 5 October. Fixes for deny or ask rules missing a command or path whose name came from a variable set on declare, typeset, export or readonly; Read deny rules not applying to image paths pasted or dragged into the prompt; sandboxed Monitor tool commands skipping the permission prompt under sandbox auto-allow; Bash checks not applying Read deny rules to wildcards in some option values; permission rules and safety checks not being applied after a PreToolUse hook rewrote a tool call's input; and a user-installed mod that could make an organisation's guard skip its check.

2.1.292, 6 October. The one entry marked as security: "Fixed PreToolUse hook approvals and auto mode bypassing the permission prompt for file reads from network (UNC) paths". It also fixed a managed sandbox read-deny path that appears or changes mid-session not taking effect fully.

Later releases. Version 2.1.296, on 9 October, fixed rm -rf /c/Users/<name> in Git Bash on Windows not asking in bypass permissions mode, and fixed managed PreToolUse hooks that deny a call with "continue": false refusing the call without ending the turn. Version 2.1.299, on 14 October, fixed deny and ask rules for an MCP server (mcp__<server>) not applying when the server's normalised name contains a double underscore, fixed Windows hooks that set no shell failing open when Git for Windows is not installed, and improved enforcement of managed permission rules, managed hooks and organisation MCP tool names against user-installed mods.

Analysis: what to make of it

Sandbox auto-allow is where rules interact

The permissions documentation explains why several fixes mention auto-allow. When sandboxing is on and autoAllowBashIfSandboxed is left at its default of true, sandboxed Bash commands run without prompting even when a bare Bash ask rule is set, because the sandbox boundary stands in for that prompt. Deny rules and specific ask rules are still meant to apply, and the documentation says a deny or ask rule matches past any leading variable assignment, so Bash(rm *) in deny still matches FOO=bar rm -rf tmp/. The 2.1.289 and 2.1.290 fixes close cases where variable prefixes and assignments slipped past that matching under auto-allow.

Network paths now always prompt

The UNC fix matters most on Windows. The documentation explains that reading a network path can contact the host it names, and on Windows that contact can send the host the user's credentials. From v2.1.292, a file read from a network path keeps its prompt even when an allow rule covers the tool, a PreToolUse hook returns allow, or auto mode is on. In dontAsk mode the read is denied instead. In bypass permissions mode it runs without the prompt, which is one more reason to disable that mode on managed machines.

Deny rules were never a full boundary

The documentation is explicit that a Bash deny rule "isn't a security boundary around the program". It matches the form of a command Claude usually produces, after splitting compound commands and stripping known wrappers, but not the same program called by its full path or inside sh -c. Its advice is to pair command deny rules with the sandbox's filesystem and network restrictions when a restriction must hold. The October fixes make deny rules more reliable; they do not change that design.

Mods and hooks are part of the policy surface

Several fixes concern user-installed mods weakening organisation guards, and hooks failing open. That is a reminder that a policy is the combination of rules, hooks, managed settings and the extensions installed on the machine, and each piece needs a version that enforces it. For custom policy hooks, version 2.1.295 also added onFailure: "block", so a hook that can't start, times out or exits unexpectedly blocks the action; see Claude Code hooks can now fail closed.

What it means for engineering and security leaders

If permission rules are part of your control set, the Claude Code version on each machine is part of that control. A deny rule written today was not reliably enforced in every case on a version from the start of October. Know which versions are in use, set a floor, and check it.

Treat deny rules as a guard against common mistakes, and use the sandbox for the restrictions that must hold. For destructive commands, network egress and secrets, the sandbox's filesystem and network limits are the stronger layer; the earlier piece on sandboxing coding agents covers those settings.

Practical takeaways for this week

• Update Claude Code to 2.1.299 or later on every machine, and check versions rather than assuming auto-update ran.
• Retest critical deny rules with environment variable prefixes, bare assignments, export and declare forms, compound commands and symlinked paths.
• On Windows, confirm that reads from network paths prompt, and test destructive Git Bash commands in each permission mode you allow.
• In managed settings, set permissions.disableBypassPermissionsMode and, if auto mode is not approved, permissions.disableAutoMode to "disable".
• Pair command deny rules with sandbox filesystem and network restrictions for anything that must not happen.
• Review which mods and plugins are installed on managed machines.

Where SpanDock fits

SpanDock guardrails, on the Enterprise plan and in the 30-day trial, add a check of their own: SpanDock installs a hook in Claude Code, Codex and Gemini CLI that checks the prompt and every tool call before it runs, and calls through the MCP gateway are covered too. If a person removes the hook from their settings, SpanDock puts it back within a minute and the server shows it in the meantime. You choose whether calls go through or are blocked when SpanDock can't check. For keeping secrets out of prompts with the same mechanism, see guardrails for secrets and personal data.