Claude Code 2.1.289: five permission gaps closed at once

Claude Code 2.1.289, shipped on October 3, 2026, has almost nothing visible to show for itself: nearly all of its close to thirty entries are internal bugs in plugins and mods, mostly in how they draw. But tucked inside that cleanup, five separate fixes each close a blind spot in the permission guardrails, four of them real bypasses of deny and ask rules, the mechanism meant to block an action before it runs. Two sit at the boundary between what a user installs and what an organization manages, three are about how a rule recognizes the command or file it's supposed to block. None of them is dramatic on its own. Together they continue a pattern this digest has already tracked for weeks: a guardrail that already exists, and one precise shape of command that still slipped past it.

Mods and managed permissions: an approval shouldn't override everything

A mod is a plugin that runs inside Claude Code and can, among other things, approve a tool call on your behalf. The documentation is blunt about what that can override: "A mod that approves tool calls can approve one that an ask rule would prompt for, or that one of your own PreToolUse hooks blocked [...] including when it can approve a call that a deny rule refuses". That's intentional for individual use. On a managed machine, Claude Code loads a built-in mod, cc-plugin-sec-default, that guards what the organization manages from user-installed mods, and an organization can also block those mods outright with allowManagedModsOnly. The 2.1.289 changelog fixes a case where that boundary didn't hold: on a managed machine, a deny or ask rule targeting a nested part of a compound shell command, something like command1 && command2, could still get waved through by a user-installed mod's approval. The rule was aimed exactly at that case, and the mod got through anyway.

The second fix addresses a different but related risk, with no deny or ask rule involved: a user-installed plugin could rewrite the descriptions of an organization-managed MCP server's sign-in tools. Those tools handle authentication with the server, and their description is what tells Claude what they're for. A user's plugin had no business changing a tool the organization controls. 2.1.289 stops it.

Three bypasses of the deny and ask rules themselves

The rest of this batch is about the mechanics of rule matching, not the boundary with mods. The permissions doc states the principle for symlinks: "Deny rules: apply when either the requested path or the file it resolves to matches", and notes that Claude Code applies Read deny rules to the directory that a Grep or Glob path argument resolves to. The 2.1.289 changelog extends that coverage to an access path the docs didn't spell out yet: a file @-mentioned, changed, or selected in the IDE escaped Read deny rules when it went through a symlink.

The last two fixes are about the sandbox. The sandboxing doc states what still holds even in auto-allow mode: "Explicit deny rules are always respected". What 2.1.289 fixes isn't a rule being deliberately ignored, it's a rule failing, in auto-allow mode, to recognize the command it targeted when that command hid behind an environment variable prefix with an expanded value. A command like TZ="$HOME" rm -rf build let the rm -rf slip under a deny or ask rule's radar. The neighboring fix covers the same blind spot for a bare variable assignment placed before the command. In both cases the rule existed and targeted the right command, it just didn't recognize it under that particular disguise.

Everything else, briefly

• Frozen terminal: a code block with many unclosed <script> tags, or deeply nested ${ substitutions, could freeze the terminal. The same flaw hit published artifact pages, on the reader's own browser tab.
• claude auth status: a 2.1.288 change may have made VS Code sign-outs more frequent; 2.1.289 reverts it.
• Mods not loading: installed mods didn't load in the first session after a Claude Code upgrade.
• agent.spawn: a new method for mods that manage teams of agents, with one agent id across plugin hook events and idle and waiting states in $.agent.list().
• The rest of the release, mostly display and reload bugs for plugin and mod authors, only matters if you build one.

What to take away

If you manage mods for a team, the first fix is the one to remember: a deny or ask rule on part of a compound command now holds against a user-installed mod's approval, on a managed machine. For everyone else, this release keeps working through territory this digest has already covered for weeks: closing, one at a time, the exact spots where a permission rule existed but failed to recognize what it was supposed to block. None of these five fixes points to a gaping hole, but all of them confirm that deny and ask rules are worth writing carefully, because Claude Code keeps finding the gaps in them.