Claude Code Closes Deny and Ask Rule Gaps Under Sandbox Auto-Allow, Symlinks and Mods

Claude CodeOct 3, 2026View original changelog

Claude Code 2.1.289 patches five gaps where Bash deny and ask rules, Read deny rules and organization-managed settings could be sidestepped. Commands prefixed with an expanded environment variable or a bare variable assignment could slip past deny and ask rules when the sandbox auto-allowed commands. Read deny rules also failed to apply to IDE-selected files reached through a symlink, and a user-installed mod or plugin could override managed policy. Users who rely on deny rules to keep Claude away from files and commands should upgrade.

Key Takeaways

Deny and ask rules now apply to commands hidden behind an expanded environment variable prefix such as TZ="$HOME" rm -rf build when the sandbox auto-allows commands.
A bare variable assignment before a command no longer causes a Bash deny or ask rule to be skipped under sandbox auto-allow.
Read deny rules now cover symlinked paths for files that are @-mentioned, changed or selected in the IDE.
On managed machines, a user-installed mod can no longer override a deny or ask rule on a nested part of a compound shell command.
A user-installed plugin can no longer rewrite the sign-in tool descriptions of an organization-managed MCP server.
The fixes are silent and need no configuration: existing rules start holding after the upgrade to 2.1.289.

Deny and ask rules held up in more cases

Claude Code 2.1.289 closes five gaps in which the agent could act outside rules that a user or an organization had set. Deny and ask rules are the main way developers keep Claude away from destructive commands and sensitive files, so a rule that silently fails to apply is more serious than an ordinary bug. The release addresses several different ways those rules could be skipped.

Bash rules and the sandbox auto-allow path

Two of the fixes concern what happens when the sandbox is configured to auto-allow commands. In that mode, a Bash deny or ask rule is expected to still stop a matching command before it runs.

The first case involved an environment variable prefix with an expanded value. A command such as TZ="$HOME" rm -rf build could hide the rm behind the prefix, so a deny or ask rule written for rm missed it. Claude Code now evaluates the command behind the prefix and applies the rule.

The second case involved a bare variable assignment placed before the command. Under sandbox auto-allow, the assignment could cause the deny or ask rule to be skipped entirely. Claude Code 2.1.289 now applies the rule in that situation too.

Developers who pair sandbox auto-allow with deny rules for commands such as rm or network tools get the most direct benefit, because those combinations are where the gap appeared.

Nested commands and mod approvals on managed machines

On managed machines, a deny or ask rule attached to a nested part of a compound shell command did not hold when a user-installed mod approved the command. The rule now stands even when a mod has approved the call. This matters to organizations that use managed settings to enforce policy, since a locally installed mod should not be able to override it.

A related fix covers a user-installed plugin that could rewrite the descriptions of the sign-in tools belonging to an organization-managed MCP server. Descriptions of those tools are now protected from that kind of rewriting, which keeps what the model and the user see for managed servers consistent with what the organization configured.

Read deny rules and symlinks

Read deny rules did not apply to files that were @-mentioned, changed or selected in the IDE when the file was reached through a symlink. A path blocked by a Read deny rule could therefore be read if it was reached through a link. Claude Code now applies Read deny rules to those files as well.

Other changes in the release

The same release carries a large group of plugin and mod fixes. These cover pane rendering, hot reload of symlinked plugin directories, claude plugin validate and installed mods not loading in the first session after an upgrade. The release also includes a fix for terminal freezes on short code blocks containing many unclosed <script> tags, and a VS Code revert of a 2.1.288 claude auth status change that may have made sign-outs more frequent.

Who should update

Anyone who depends on deny or ask rules, on sandbox auto-allow, or on organization-managed settings should move to 2.1.289. The fixes change no commands or settings, so nothing needs to be reconfigured after upgrading. Rules that were previously skipped in these cases simply start applying.