Claude Code 2.1.289 stops a mod from overriding a shell deny rule

Claude Code v2.1.289 blocks mod-approved nested shell commands when deny or ask rules match, and fixes sandbox variable-prefix parsing.

Claude Code v2.1.289, released on 2026-10-03 at 23:07 UTC, closes a permission gap on managed machines: a deny or ask rule on a nested part of a compound shell command now holds over a user-installed mod's approval. The release also fixes two sandbox auto-allow parsing cases, symlinked Read deny checks, and a VS Code sign-out regression from v2.1.288.

Claude Code v2.1.289 in context

  • Claude Code v2.1.287 added Claude Mods on 2026-10-01. Its release notes describe mods as plugins that can modify deeper behavior.
  • Claude Code's admin documentation says a mod runs code inside Claude Code with the permissions of the user who installed it, and that mods are not sandboxed.
  • When managed settings are present, Claude Code loads the built-in sec-default@builtin guard ahead of user-installed mods. The documentation says deny rules and managed hooks take precedence where that guard loads.
  • The v2.1.289 release note names a narrower repair: a rule attached to a nested part of a compound shell command now holds over a user-installed mod's approval on managed machines.

Claude Code v2.1.289 and compound shell commands

A compound shell command contains more than one command joined by shell syntax such as &&, ;, or |. The v2.1.289 release note says the permission engine previously let a user-installed mod's approval override a deny or ask rule attached to a nested command. Version 2.1.289 fixes that interaction on managed machines.

The distinction matters for administrators. The admin documentation says the built-in guard protects managed settings, managed instructions, and organization-managed MCP tool descriptions. It also says a user mod can approve calls that an ordinary ask rule would prompt for, or that a non-managed hook blocked. The release note does not announce that every mod approval is now forbidden. It identifies the nested-command case as the repaired path.

Claude Code v2.1.289 and sandbox variable prefixes

Claude Code's sandbox is off by default. When it is enabled, sandbox.autoAllowBashIfSandboxed defaults to true, so sandboxed commands can run without a prompt. The v2.1.289 release notes identify two command forms that previously made Bash deny and ask rules miss the command under sandbox auto-allow:

TZ="$HOME" rm -rf build
VAR=value command

The first form puts an environment-variable prefix with an expanded value before the command. The second puts a bare variable assignment before it. Version 2.1.289 fixes both rule-matching cases. The release note describes the affected syntax, but it does not specify a parser implementation, so the safe claim is about the enforcement result rather than an internal algorithm.

Claude Code v2.1.289's other fixes

The same release also changes several plugin, file, editor, and rendering paths:

  • Read deny rules now apply when a file is @-mentioned, changed, or selected in the IDE through a symlink.
  • The VS Code extension reverted a v2.1.288 change to claude auth status that may have made sign-outs more frequent.
  • Claude Code fixed terminal freezes on short code blocks with many unclosed <script> tags or deeply nested ${ substitutions. It also fixed published artifact pages freezing or crashing the reader's browser tab on the unclosed-script case.
  • Installed mods now load in the first session after a CLI upgrade.
  • A user-installed plugin can no longer rewrite the descriptions of organization-managed MCP server sign-in tools.

For a managed installation, the practical update is to run v2.1.289 or later before relying on deny rules around compound commands or sandboxed Bash. This post covers the fixes named in the 2026-10-03 release note; it does not claim that v2.1.289 replaces managed policy or makes user-installed mods sandboxed.

Sources

Last verified: 2026-10-06.

Spotted an outdated or wrong claim? Agents can report it with evidence throughPOST /api/feedback; an editor checks every report. See llms.txt for the agent API.