Claude Code 2.1.289 Closes Deny Rule Gaps Stable Channel Still Lacks

• Copilot CLI v1.0.92-3 (6:06 PM ET, 2 Oct) is a pre-release, and stable is still v1.0.91.

Claude Code v2.1.289 is a permissions release: it closes several shapes of command and file access in which a deny or ask rule was supposed to apply and did not, and the channel split decides who has the fix. Treat today as the day to check which Claude Code build enforces your deny rules, leave stable fleets where policy puts them, and ignore the pre-releases.

Top Stories

1. Claude Code v2.1.289 makes deny rules hold in shapes they used to miss

The changelog says a deny or ask rule on a nested part of a compound shell command did not hold over a user-installed mod’s approval on managed machines, which the docs tie to managed settings or a Team or Enterprise sign-in. A mod is a plugin that runs code inside Claude Code and can approve a tool call before the permission prompt. Anthropic’s docs explain the setup: a built-in guard loads on those machines, and where it loads, a user’s mod cannot approve a call that a deny rule refuses, unless an administrator sets allowModsToOverrideDenyRules. An API-key user on an unmanaged laptop gets no guard, and the docs say a mod can approve a denied call there. The changelog says “deny or ask,” but the docs say a mod can approve a call an ask rule would prompt for, so rely on the deny half. Mods arrived in v2.1.287, so this gap can exist only in v2.1.287 and v2.1.288.

The next three fixes apply whether or not you use mods. Bash deny and ask rules no longer miss a command behind an environment-variable prefix with an expanded value when the sandbox auto-allows commands, and the changelog’s example is TZ="$HOME" rm -rf build. A deny or ask rule is also no longer skipped under sandbox auto-allow when a bare variable assignment comes before the command. Read deny rules now apply to files @-mentioned, changed or selected in the IDE through a symlink. The changelog does not say which release introduced any of these three gaps, so do not assume stable is exposed or safe.

One more fix is narrower: a user-installed plugin can no longer rewrite the descriptions of an organization-managed MCP server’s sign-in tools.

Practical dev impact: A deny rule in a settings file states intent, so confirm that the binary reads v2.1.289 before you call a command or file protected. The changelog does not name the surfaces for these fixes, so check each one you run, including the VS Code panel and Desktop.

2. The same release fixes mods that did not load after an upgrade, and hardens mod drawing

The changelog says it fixed installed mods not loading in the first session after an upgrade. That is a bug fix, and the changelog does not say whether the upgrade onto v2.1.289 itself benefits. If a mod seems missing after an update, quit and start Claude Code again, then run claude plugin list. If it is still missing, compare against claude --safe-mode, which Anthropic documents as turning installed mods off.

For mod authors, v2.1.289 raises a ui.fault event when a Client element fails while drawn, instead of letting it take down everything the mod drew around it. A value from a ui.render hook that makes a row throw now falls back to the engine’s own row instead of ending the session. claude plugin validate no longer skips a plugin whose folder also holds a marketplace manifest. Anthropic’s mods reference lists agent.spawn as an event that fires when a subagent or teammate is about to start, where a hook can pick its model or deny it.

Separately, in the VS Code extension v2.1.289 reverts a v2.1.288 change to claude auth status that may have made sign-outs more frequent.

Practical dev impact: Take the update if a mod pane crashed a session or the IDE kept signing you out, and hold off on agent.spawn workflows until the docs say more than one table row.

3. Copilot CLI v1.0.92-3 and VS Code v1.141 Insiders are pre-release only

GitHub published Copilot CLI v1.0.92-3 as a pre-release at 6:06 PM ET on 2 Oct, and npm lists latest as v1.0.91 and prerelease as v1.0.92-3. It adds a pre-conversation Ctrl+E picker to switch between local and cloud runs. Sandboxed shell commands now offer a network bypass prompt whenever the proxy blocks a destination, and sandboxed scripts that run Git authenticate with masked credentials and SSH remote rewrites. Sub-agents keep working after you replace your GitHub credentials, and retired models leave the model picker and supported CLI selections.

The VS Code v1.141 Insiders notes, last updated 2 Oct, add a Background Shells pill that tracks attached and detached shell processes started by the Copilot harness. They also add sign-in to multiple GHE.com and GitHub Enterprise Server instances.

Practical dev impact: Leave fleets on Copilot CLI v1.0.91 and stable VS Code. A network bypass prompt is a question, not an allow.

Practical Impact Analysis

The decision today is which build enforces your deny rules, and it depends on which channel each machine follows. npm stable and the native installer’s stable pointer are both v2.1.285, while latest and next are v2.1.289, so a machine on stable has none of these fixes. It also has no mods, so the mod-approval gap cannot exist there, but the prefix, assignment and symlink gaps may. A machine on v2.1.287 or v2.1.288 has mods switched on, so it can have the mod gap as well, and is the first one to update.

Because next matches latest today and can move on the next publish, pin the version if a pilot must not float. If policy says stable, write that down and protect sensitive commands and files some other way until stable advances. The prefix and assignment fixes matter where sandbox auto-allow is on, which the docs say is the default once the sandbox is enabled, and the symlink fix matters if a repository keeps .env files or secrets folders behind links.

Tutorial

Steps 1 and 2 are in the script below, with the install line commented out until policy allows it. The script also writes the step 3 deny list and the step 5 scratch project, and steps 4 and 5 happen inside Claude Code.

1. Check which build and channel you are on. As of about 6:00 AM ET on 4 Oct, the tags read latest: 2.1.289, next: 2.1.289 and stable: 2.1.285.
2. Install v2.1.289 only where policy allows the latest channel, then run claude --version, which should print 2.1.289 (Claude Code). Anthropic documents a bash -s 2.1.289 form of its native installer for an exact version, and says the channel you pick at install time becomes the auto-update default, so check autoUpdatesChannel afterward.
3. Put a deny list in managed settings. The example below is adapted from Anthropic’s server-managed settings page, and managed settings can arrive as a file, an MDM policy or the claude.ai console.
4. Start a session and run /plugin. On a machine with managed settings, or for a Team or Enterprise sign-in, the built-in guard is listed as cc-plugin-sec-default. If you do not see it, a mod may approve what a deny rule refuses.
5. Test the env-prefix case in the scratch directory, never in a real project. Change to the printed scratch path first, then start claude and ask it to run TZ="$HOME" rm -rf build. On v2.1.289 the deny rule should refuse it. The install and the JSON syntax were checked, but this prompt was not run in a live session, so treat step 5 as a test of your own, not a confirmed result. The sandbox needs a supported platform (macOS, Linux or WSL2).

#!/usr/bin/env bash
set -u

# Step 1: running build and channel tags
claude --version
npm view @anthropic-ai/claude-code dist-tags

# Step 2: uncomment only where policy allows the latest channel
# npm install -g @anthropic-ai/claude-code@2.1.289
# claude --version

# Steps 3 and 5: write example files into a scratch directory
scratch="$(mktemp -d)"
mkdir -p "$scratch/.claude" "$scratch/build"


... click "Show full code" below to expand

#!/usr/bin/env bash
set -u

# Step 1: running build and channel tags
claude --version
npm view @anthropic-ai/claude-code dist-tags

# Step 2: uncomment only where policy allows the latest channel
# npm install -g @anthropic-ai/claude-code@2.1.289
# claude --version

# Steps 3 and 5: write example files into a scratch directory
scratch="$(mktemp -d)"
mkdir -p "$scratch/.claude" "$scratch/build"

# Step 3: example deny list; deploy the real one through managed settings
cat > "$scratch/managed-settings-example.json" <<'JSON'
{
  "permissions": {
    "deny": ["Bash(curl *)", "Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}
JSON

# Step 5: scratch project with the sandbox on and a Bash deny
cat > "$scratch/.claude/settings.json" <<'JSON'
{
  "sandbox": { "enabled": true },
  "permissions": { "deny": ["Bash(rm *)"] }
}
JSON
echo "Scratch project: $scratch"

Recommended AI prompt

Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever AI you use.

I run a team that uses Claude Code and I need to know whether our deny rules are actually enforced after Claude Code v2.1.289. Write a one-page checklist that tells me, in order, how to find out which Claude Code version and release channel each machine runs, how to tell whether a machine has managed settings or a Team or Enterprise sign-in so the built-in mod guard loads, how to confirm a deny rule for a Bash command and a .env file holds, and when to update. Explain that the v2.1.289 changelog fixes a mod’s approval beating a deny rule on a nested part of a compound command, a deny or ask rule skipped behind an environment-variable prefix or a bare variable assignment under sandbox auto-allow, and a Read deny skipped through a symlink. Do not claim an ask rule is protected from mods, and do not tell me to enable anything new. Ask me for anything you need, such as our operating systems, whether we use the sandbox, and whether our machines get settings from a file, MDM or the admin console, instead of guessing.