Claude Code 2.1.304: Code Review levels, mod controls and skill hook caps

Claude Code 2.1.304, dated 19 October 2026 in Anthropic's changelog, is a release about who decides. Code Review gains three review levels an organization Owner picks, mod authors get two new fields on the tool.check event plus a way to turn an organization's setting into a ceiling, and a skill's hooks are now capped per source. If you administer Claude Code for a team, the Code Review and mod settings changes are the two to read before you upgrade; if you only use it, the per-source hook cap and a rm -r safety fix are the parts that will reach you.

The release lands a day after 2.1.303, which the changelog records as bug fixes and reliability improvements alone. 2.1.304 carries 12 improvements and 43 bug fixes alongside the new features.

#What do Code Review's new review levels do?

The review level sets how thorough each review is, and the Code Review documentation is explicit that a more thorough review costs more. An Owner chooses one level for the organization and can override it per repository.

Level	Thoroughness	Speed and cost	Who sets it
Quick	A lighter pass	Fastest, lowest cost	Organization Owner, or per repository
Standard	Balanced depth, speed and cost. The default	Between the other two	Organization Owner, or per repository
Deep	The most thorough pass	Takes the longest, costs the most	Organization Owner, or per repository

The documentation pairs the per-repository override with an example worth copying: Quick for a routine codebase and Deep for a critical one. It also notes that Code Review chooses the Claude models reviews run on, and that its admin settings offer no model choice, so the review level is the only thoroughness control you have.

Two limits are worth stating plainly, because neither changed in this release. Code Review is a Team and Enterprise feature, and a review never approves or blocks a pull request, so the decision to merge stays with your team. If you are on another plan, the /code-review command in a session is the route that is open to you, on any plan.

Alongside the levels, the changelog records a second admin option: Code Review admin settings can now review every repository in a GitHub organization, including ones added later, without selecting them one by one. That is the setting to check after upgrading if your organization adds repositories often, because it changes what gets reviewed by default rather than how.

#What changed for mod authors?

Three changes, all from the changelog's own wording.

The tool.check answer gains decider: "person". Per the changelog, it means only the permission dialog or a host's callback can approve the ask, and the call is refused with the mod's reason where nobody can be asked. That second clause is the useful half: it gives a mod a way to say "a human must approve this" that fails closed in an unattended session rather than falling through to whatever the rules would have allowed.

The same event gains e.isReadOnly, set when the tool call is read-only. A guard that wants to wave through reads and stop writes no longer has to infer that from the tool name and its arguments.

Separately, settings.read hooks now receive each settings layer and rewrite the merged settings. The changelog spells out what this is for: a managed mod can make an organization's setting a ceiling, including the cleanupPeriodDays the retention sweep uses. Before, a hook saw the merged result and could replace it; seeing the layers is what makes "no user setting may exceed this" expressible.

One caveat if you go looking for details. The mods reference has not caught up: it states that its entries cover the CLI and the Desktop app as of v2.1.290, and its tool.check section still lists only e.agentId and e.ceiling as the event's added fields. For decider and e.isReadOnly the changelog is the source today. The reference itself points at the TypeScript declarations Claude Code writes for your installed version as the authority when the two disagree, which is the right place to check once you have 2.1.304 in hand. Our guide to Claude Code mods covers the hook model these fields sit in.

#What are the new limits on skill hooks?

The skills of one source, meaning a repository, your own folder, or a plugin, can now register at most 1,024 hooks and 16,384 matcher characters per session. The cap is per source rather than per session in total, which is the detail that decides whether it affects you: a single plugin registering hooks generously can no longer exhaust the budget that another plugin or your own project skills need.

A second skills change is narrower and easy to miss. Under a policy that allows hooks from plugins only, a skill used in the main conversation whose hooks are kept out no longer gets its allowed-tools. If you run that policy, a skill that relied on allowed-tools to widen what it could reach will now find that permission withheld along with its hooks. That is consistent rather than surprising, but it is a behaviour change in a session that was previously granting the tools and dropping the hooks. See skills, subagents, plugins and MCP compared for where skill hooks sit among the extension points, and the Claude Code platform hub for the rest of the surface.

#Which fixes matter most if you run Claude Code unattended?

Four of the 43, picked for what they could have cost you rather than for how often they fired.

• rm -r on a mounted drive now prompts. Deleting a mounted drive, or a folder at its top level such as /Volumes, /media or WSL's /mnt/c, was not getting the safety prompt that rm -rf /Applications gets. It does now.
• claude --worktree could lose commits. It was removing the worktree and its branch without asking at exit when HEAD was detached or on another branch. The changelog names losing commits as the consequence.
• A plugin could outrun --max-turns. In headless runs, a plugin could keep the run going past --max-turns, Stop, or ended input by spawning subagents or re-running a finished one. If you cap headless runs for cost or safety, this is the fix that makes the cap hold.
• A full disk could silently truncate transcripts. CLAUDE_CODE_TRANSCRIPT_LOCAL_GC was dropping messages from the saved transcript when the disk filled up while the file was being trimmed.

One more for anyone running sandboxed commands on Linux: a sandbox.filesystem.denyRead glob containing brackets that are not a character class, such as a [user-id] route folder, was stopping sandboxed commands from starting at all. Next.js-style route directories make that an easy pattern to hit by accident.

#What else is new in this release?

Two commands worth knowing about, both from the changelog.

/auto-mode-setup is a guided setup that reads your project and recent sessions to teach auto mode about your environment. It is now also available on Bedrock, Vertex, Foundry, the Claude apps gateway and telemetry-disabled sessions, which is the part that is new: the command existed, the reach did not.

/claude-api managed-agents-secure compares a Managed Agents agent's settings with Anthropic's published security guide, and the changelog is specific that it changes nothing while doing so. A read-only posture check is a reasonable thing to run before you widen what an agent can reach.

#Should you upgrade now?

For most people, yes, and the rm -r and --worktree fixes are the argument on their own. Two groups should read first rather than upgrade first.

If you administer Code Review, the new review-every-repository option changes what gets reviewed by default, and the organization review level is a cost decision as much as a quality one. Decide both deliberately instead of discovering them.

If you ship a mod or a plugin that registers skill hooks, check your hook count and total matcher length against the 1,024 and 16,384 per-source caps before your users upgrade, and check whether anything you own depends on a main-conversation skill getting its allowed-tools under a plugins-only hook policy.

Before installing any third-party plugin or skill on the back of a release note, including the mods discussed here, work through our skill security audit. Nothing in this article is an endorsement of any third-party component, and a mod that handles tool.check is by definition code that can answer a permission question on your behalf.