Ideia principal

Um hook ligado ao fim de um turno de conversa, e cujo trabalho consiste justamente em chamar o assistente para resumir a troca, dispara a si mesmo: a chamada que ele emite também termina, e esse fim acorda o hook. O laço não é um acidente de implementação, é a consequência direta da montagem — o automatismo usa a ferramenta cujo fim ele vigia.

O remédio não é evitar a chamada, e sim tornar o automatismo capaz de distinguir os disparos que ele mesmo provocou daqueles que vêm do trabalho real. Para isso, o Claude Code passa um indicador stop_hook_active nos dados enviados ao script, e o script sai imediatamente quando o vê, antes de qualquer processamento.

Esse teste fica em primeiro lugar, antes da leitura do transcript e antes de qualquer chamada de modelo. Uma proteção colocada depois do trabalho caro não protege nada: o laço já estaria consumindo.

Por que isso importa

É uma pane que você não descobre projetando, e sim pagando — em tempo de execução, em chamadas faturadas, em sessões que não devolvem o controle. Saber que ela é estrutural permite tratá-la no projeto.

E o padrão aparece em todo lugar onde um sistema reage aos próprios efeitos: um gatilho de banco que escreve na tabela que ele vigia, uma integração contínua que empurra um commit, uma regra de e-mail que responde na thread que ela observa.

Nuances e limites

A distinção só é possível se o ambiente a fornecer. Sem um sinal desse tipo, é preciso fabricá-la — um bloqueio, um marcador, uma janela de tempo — e esses substitutos falham assim que duas execuções se sobrepõem.

E sair por causa desse sinal tem um custo: a troca interna nunca fica registrada.

Questões em aberto

• Como detectar que uma automação reflexiva está rodando em laço, se a saída dela é justamente não escrever nada?