Claude Code

Claude Code 2.1.290 takes back eight things auto-approval used to let through

3 min read AI-generated

A mod you downloaded could unload your organization's plugin. Now the mod is the one that goes.

Featured image for "Claude Code 2.1.290 takes back eight things auto-approval used to let through"

2.1.290 landed in the npm registry on October 5 at 18:12 UTC. 190 changelog lines: 112 fixes, 22 changes, 15 improvements, 11 additions, plus separate sections for VS Code, Claude Tag, cloud sessions and Code Review. For comparison, 2.1.289 two days earlier had 27.

With that much, it pays to look for a pattern. There is one, and it sits in the permission layer.

Eight commands that used to run without asking

rg and git grep count as read-only, so they were auto-approved — even when the shell would still have expanded their arguments as wildcards. Same problem with wildcards in the option values of other read-only commands. Then there are commands whose variable names zsh reads differently from bash; those slipped through because the check assumed bash semantics.

ps now asks in more of its forms. pyright is no longer treated as read-only. A short form of a git clone option kept the sandbox exemption from a pattern like git * in sandbox.excludedCommands; it’s now handled like the long form. Sandboxed Monitor commands skipped the prompt entirely under sandbox auto-allow. And in plan mode, the auto-mode classifier could approve connector tools that aren’t read-only and carry a server-pushed ask policy.

None of those lines announces a feature. Together they say something: auto-approval was more generous than the rules you wrote, in eight places.

Two fixes describe the same attack. Reading an image on macOS and Windows could return a file that was never approved, because the link got swapped mid-read. And an @-mention under the read block or --restricted could read a file outside the working directories the same way.

In the same block: a CLAUDE.md, a rule or an AGENTS.md symlinked to somewhere outside loaded anyway, despite permissions.blockReadsOutsideWorkingDirectories. And Read deny rules didn’t apply to image paths you drag into the prompt.

A mod could switch off your company’s plugin

Two lines sit almost next to each other and belong together: a user-installed mod could get an organization’s plugin unloaded, and a user-installed mod could make an organization’s guard skip its check. In both cases the mod is now the thing that gets unloaded, not the policy.

The same thinking shows up elsewhere in the changelog. Claude in Chrome can no longer be switched on by a project’s settings file, and CLAUDE_CODE_DISABLE_ATTACHMENTS can’t be set from a repo’s .claude/settings.json anymore. A repository you cloned doesn’t get to reconfigure your tooling.

The WebSearch budget now refills

The WebSearch budget no longer runs out after 200 calls — it refills at 100 per hour, tunable with CLAUDE_CODE_WEB_SEARCH_REFILLS_PER_HOUR, off at 0. WebFetch quietly threw away everything past 100,000 characters for a long time; now it tells you how much went unread and accepts an offset. And /code-review at medium effort reports cleanup and convention findings on Opus 5.5 and Sonnet 5.5 too.

Also new: claude attach <name> and claude logs <name> — part of a session name works instead of the id.

The permission layer was never as strict as it looked

Eight auto-approvals rolled back, three symlink races closed, two ways a mod could step around company policy. That isn’t a random bundle, that’s a review. If you set deny rules in Claude Code and trusted them, until yesterday you got something other than what your file said. The understated tone of the changelog is pleasant. Reassuring it isn’t.

Sources

Claude CodeAnthropicReleasesSecurityPermissions