Claude Code refina subagents e hooks e expõe os limites de automatizar revisão de PR

Três releases do Claude Code publicadas entre 1 e 3 de outubro de 2026 mexem na isolação de subagents e no comportamento de hooks como PreToolUse. Os bugs corrigidos revelam como montar (e onde não confiar cegamente em) um pipeline local de revisão de código.

Três releases, um recado sobre subagents

Entre 1 e 3 de outubro de 2026 o Claude Code publicou três releases seguidas (a mais recente, v2.1.289, saiu em 3 de outubro). A primeira delas, de 1º de outubro, traz um anúncio de produto novo relevante ao tema deste texto: Claude Mods, um sistema que permite a plugins modificarem comportamentos mais profundos do Claude Code, e "You should know", um mod embutido no qual um agente paralelo observa a sessão e aponta problemas que o usuário ou o próprio Claude podem deixar passar.

As duas releases seguintes, de 2 e 3 de outubro, concentram-se em correções de infraestrutura em subagents e hooks, documentadas no changelog oficial do projeto no GitHub. Para quem tenta montar um pipeline local de revisão automatizada de pull request, ou seja, usar agentes especializados (um revisor de segurança, um gerador de testes) disparados por gatilhos antes e depois de cada ferramenta, essas correções importam mais do que parecem: elas mostram, pelo que estava quebrado, como o mecanismo realmente funciona por baixo.

Como um subagent ganha identidade própria

Um dos fixes do dia 2 de outubro resolve algo que travava justamente a ideia de ter papéis diferentes por agente: "agent teams: a plugin-defined agent spawned by name now runs with its own prompt, tools, disallowedTools and effort instead of the defaults". Na prática, isso confirma que cada subagent definido num plugin carrega quatro atributos próprios: prompt, lista de tools permitidas, lista de disallowedTools e nível de effort. É esse conjunto que permite, por exemplo, um subagent "revisor de segurança" que só enxerga Read e busca de texto, nunca Bash, enquanto um subagent "gerador de testes" tem Write e Bash liberados para rodar a suíte.

Antes da correção, um agente de equipe invocado pelo nome ignorava essa configuração e caía nos valores padrão, o que na prática apagava o isolamento entre papéis: o revisor de segurança podia herdar permissões do agente genérico. A release de 3 de outubro completa o quadro com agent.spawn para criar colegas de equipe sob demanda e um agent_id único que se mantém o mesmo em todos os eventos de hook do ciclo de vida do agente, além dos estados idle e waiting em $.agent.list(). Isso é o que torna possível auditar, hook a hook, qual subagent fez o quê.

O comando que já vem pronto, e o que falta nele

O Claude Code já tem um comando embutido de revisão, /code-review, que ganhou na release de 2 de outubro a flag --max-findings <n>|all para controlar quantos achados o comando reporta (a escolha fica valendo até alguém passar --max-findings default). Isso cobre o caso simples: rodar uma revisão genérica e ajustar o volume de ruído. O que o /code-review built-in não faz é separar papéis, não há como pedir que ele rode com a postura de um especialista em segurança e outro em cobertura de teste ao mesmo tempo. É exatamente a lacuna que subagents com tools/disallowedTools próprios preenchem.

Hooks: de falha silenciosa a bloqueio por padrão

A mudança mais relevante para quem pensa em segurança está num fix discreto do changelog: hooks de PreToolUse e PermissionRequest que falhassem ao casar o padrão, ou cujo input não pudesse ser serializado em JSON, antes simplesmente deixavam a chamada passar sem gate nenhum. Agora a chamada é bloqueada. Para um pipeline que depende de um PreToolUse para interceptar, digamos, um git push ou um comando Bash arriscado antes da execução, essa é a diferença entre um hook que falha aberto e um que falha fechado.

Dois outros ajustes mexem no ritmo de notificação dos hooks assíncronos:

• Hooks configurados com asyncRewake ficavam acordando o Claude repetidamente com avisos de "found issues" quando o script do próprio hook estava ausente; agora o hook quebrado é reportado uma única vez.
• Hooks de idle_prompt disparavam notificação mesmo com agentes em segundo plano ainda rodando, o que gerava sinais de "terminou" prematuros num fluxo que ainda tinha subagent em execução.

Ambos importam para quem monta um hook de notificação que avisa a sessão principal quando o subagent de segurança encontra algo: sem esses fixes, o alerta vira spam ou dispara cedo demais.

Onde a automação ainda tropeça

O changelog também documenta, por tabela de causa e efeito, as bordas onde o sistema ainda escorregava até esta leva de correções:

O padrão que aparece nessa lista é claro: a cada release surgem novas formas de um comando escapar da regra de permissão que deveria barrá-lo. Isso não é exclusividade do Claude Code, é a natureza de qualquer sistema que tenta casar padrão de texto contra comando de shell. Mas significa que um hook de PreToolUse sozinho não é suficiente como única camada de defesa num pipeline que lida com Bash de verdade.

Montando o pipeline: o que dá para confiar hoje

Com as correções de outubro de 2026, três peças ficam estáveis o bastante para sustentar um subagent especializado em revisão: isolamento de tools/disallowedTools/effort por agente, comportamento fail-closed em PreToolUse/PermissionRequest, e agent_id consistente em todos os eventos de hook para auditoria. Isso é o mínimo para separar um revisor de segurança (sem Bash) de um gerador de testes (com Bash e Write) e ainda saber, no log, qual dos dois tomou qual decisão.

O que ainda pede cautela é tudo que envolve permissão sobre comando de shell. As bordas de bypass que o próprio changelog admite ter corrigido (prefixo de variável de ambiente, atribuição de variável antes do comando, bash -c/sh -c, redirecionamento com ~ ou curinga) sugerem que a superfície de regras de Bash ainda está sendo descoberta em produção. Quem depende de um hook de segurança como porta de saída única para comandos destrutivos faz bem em manter também sandbox e revisão manual para qualquer coisa que chegue perto de rm, git push --force ou alteração de infraestrutura.

Quando não vale montar essa complexidade

Se o time só precisa de uma passada de revisão automatizada sem separar papéis, o /code-review embutido com --max-findings resolve sem exigir configuração de subagents nem hooks customizados. Se o plano é orquestrar subagents via servidor MCP, só faz sentido depois da correção da ferramenta Agent em claude mcp serve, publicada em 2 de outubro de 2026; versões anteriores rejeitavam qualquer subagent_type. E se o fluxo roda em bypassPermissions por conveniência, vale atualizar antes de confiar nele perto de comandos que apagam arquivo, já que a salvaguarda contra rm perigoso só fechou essas brechas específicas nesta mesma leva de releases.

Fonte 1: Release notes oficiais do Claude Code (GitHub)

As informações deste artigo foram extraídas das release notes públicas do Claude Code, publicadas no repositório oficial do projeto no GitHub (https://github.com/anthropics/claude-code/releases), especificamente das versões v2.1.287 (1º de outubro de 2026), v2.1.288 (2 de outubro de 2026) e v2.1.289 (3 de outubro de 2026).

Fonte: Release notes oficiais do Claude Code (GitHub)