Claude Code refines subagents and hooks, exposing the limits of automating PR review

Three Claude Code releases published between October 1 and 3, 2026 change subagent isolation and the behavior of hooks like PreToolUse. The fixed bugs reveal how to build (and where not to blindly trust) a local code review pipeline.

Three releases, one message about subagents

Between October 1 and 3, 2026, Claude Code published three releases in a row (the most recent, v2.1.289, came out on October 3). The first of them, from October 1, brings a new product announcement relevant to this piece's topic: Claude Mods, a system that lets plugins modify deeper behaviors of Claude Code, and "You should know", a built-in mod in which a parallel agent observes the session and flags issues that the user or Claude itself might miss.

The next two releases, from October 2 and 3, focus on infrastructure fixes in subagents and hooks, documented in the project's official changelog on GitHub. For anyone trying to build a local pipeline for automated pull request review, that is, using specialized agents (a security reviewer, a test generator) triggered before and after each tool call, these fixes matter more than they seem to: they show, through what was broken, how the mechanism actually works under the hood.

How a subagent gains its own identity

One of the October 2 fixes resolves something that was precisely blocking the idea of having different roles per agent: "agent teams: a plugin-defined agent spawned by name now runs with its own prompt, tools, disallowedTools and effort instead of the defaults". In practice, this confirms that each subagent defined in a plugin carries four attributes of its own: prompt, list of allowed tools, list of disallowedTools, and effort level. It's this combination that allows, for example, a "security reviewer" subagent that only sees Read and text search, never Bash, while a "test generator" subagent has Write and Bash enabled to run the suite.

Before the fix, a team agent invoked by name ignored this configuration and fell back to the defaults, which in practice erased the isolation between roles: the security reviewer could inherit the generic agent's permissions. The October 3 release completes the picture with agent.spawn to create teammates on demand and a unique agent_id that stays the same across all hook events in the agent's lifecycle, plus the idle and waiting states in $.agent.list(). This is what makes it possible to audit, hook by hook, which subagent did what.

The command that already ships ready, and what it's missing

Claude Code already has a built-in review command, /code-review, which gained the --max-findings <n>|all flag in the October 2 release to control how many findings the command reports (the choice stays in effect until someone passes --max-findings default). That covers the simple case: running a generic review and adjusting the noise level. What the built-in /code-review doesn't do is separate roles; there's no way to ask it to run with the stance of a security specialist and a test coverage specialist at the same time. That's exactly the gap that subagents with their own tools/disallowedTools fill.

Hooks: from silent failure to blocking by default

The most relevant change for anyone thinking about security is in a discreet changelog fix: PreToolUse and PermissionRequest hooks that failed to match the pattern, or whose input couldn't be serialized to JSON, used to simply let the call through with no gate at all. Now the call is blocked. For a pipeline that relies on a PreToolUse to intercept, say, a git push or a risky Bash command before execution, that's the difference between a hook that fails open and one that fails closed.

Two other adjustments change the notification rhythm of asynchronous hooks:

• Hooks configured with asyncRewake would repeatedly wake Claude up with "found issues" warnings when the hook's own script was missing; now the broken hook is reported only once.
• idle_prompt hooks fired notifications even with background agents still running, which generated premature "done" signals in a flow that still had a subagent in progress.

Both matter for anyone building a notification hook that alerts the main session when the security subagent finds something: without these fixes, the alert turns into spam or fires too early.

Where automation still stumbles

The changelog also documents, through a cause-and-effect table, the edges where the system was still slipping up until this round of fixes:

The pattern that emerges from this list is clear: with every release, new ways appear for a command to escape the permission rule that should block it. This isn't exclusive to Claude Code; it's the nature of any system that tries to match text patterns against shell commands. But it means a PreToolUse hook alone isn't enough as the only layer of defense in a pipeline that deals with real Bash.

Building the pipeline: what you can trust today

With the October 2026 fixes, three pieces become stable enough to support a specialized review subagent: per-agent isolation of tools/disallowedTools/effort, fail-closed behavior in PreToolUse/PermissionRequest, and a consistent agent_id across all hook events for auditing. That's the minimum needed to separate a security reviewer (without Bash) from a test generator (with Bash and Write) and still know, in the log, which of the two made which decision.

What still calls for caution is everything involving permission over shell commands. The bypass edge cases that the changelog itself admits to having fixed (environment variable prefix, variable assignment before the command, bash -c/sh -c, redirection with ~ or a wildcard) suggest that the surface of Bash rules is still being discovered in production. Anyone relying on a security hook as the single exit gate for destructive commands does well to also keep a sandbox and manual review for anything that comes close to rm, git push --force, or infrastructure changes.

When it's not worth building this complexity

If the team only needs a single automated review pass without separating roles, the built-in /code-review with --max-findings does the job without requiring subagent configuration or custom hooks. If the plan is to orchestrate subagents via an MCP server, it only makes sense after the fix to the Agent tool in claude mcp serve, published on October 2, 2026; earlier versions rejected every subagent_type. And if the flow runs on bypassPermissions for convenience, it's worth updating before trusting it near file-deleting commands, since the safeguard against dangerous rm only closed these specific gaps in this same round of releases.

Source 1: Official Claude Code release notes (GitHub)

The information in this article was drawn from Claude Code's public release notes, published in the project's official repository on GitHub (https://github.com/anthropics/claude-code/releases), specifically versions v2.1.287 (October 1, 2026), v2.1.288 (October 2, 2026), and v2.1.289 (October 3, 2026).