Claude Code ignora proibições do CLAUDE.md: o que mover para permissions e hooks

Você escreveu no CLAUDE.md «não apague dados sem solicitação», e o agente apagou mesmo assim. Não é um bug raro: na issue #46779 o autor reclama que o Claude Code apagava dados repetidamente além da tarefa, embora a proibição estivesse escrita de forma explícita. Uma análise no Habr propõe uma forma clara de pensar nisso: a regra deve viver onde o custo de violá-la se justifica.

Por que o texto não segura

O CLAUDE.md é carregado no início de cada sessão, e o Claude Code o relê após a compactação da conversa. Parece que a regra está sempre no contexto. Mas o problema não é a memória. No benchmark StateTrack-Bench, do EMNLP 2026, os autores atribuíram 88,6% das falhas em conversas longas à deriva de comportamento: o modelo lembra da restrição, mas deixa de segui-la. A Microsoft Research acrescenta um pano de fundo geral: nos modelos de ponta, a qualidade em conversas de vários turnos é, em média, 39% menor que em turno único.

A Anthropic escreve com franqueza na documentação que uma instrução do tipo «nunca faça X» é cumprida na maioria dos casos, mas sob pressão, numa sessão longa, numa situação ambígua ou diante de prompt injection pode ser violada. Aqui, prompt injection significa uma instrução alheia dentro de um arquivo que o agente abriu por causa da tarefa.

Dividindo as regras pelo custo do erro

Se o erro custa minutos, uma linha de texto basta. Se custa dinheiro, expõe chaves ou inicia trabalho sem confirmação, é preciso código. São três ferramentas:

• permissions: as regras allow, ask e deny determinam o que o agente faz sozinho, sobre o que pergunta e o que lhe é proibido;
• hooks: comandos de shell que o Claude Code executa em um evento da sessão, por exemplo antes de gravar um arquivo ou ao tentar encerrar um turno;
• verificação por código antes da execução, por exemplo um script que não inicia o trabalho sem um arquivo com um plano confirmado.

Um exemplo da prática do autor: um comando de uma ferramenta de navegador gastava créditos pagos. Ele foi bloqueado com uma regra deny em .claude/settings.json, e não com um pedido em texto. O arquivo de configurações deve ser commitado no git para que toda a equipe receba as regras. Um detalhe importante de um comentário da issue #65563: uma proteção que olha apenas para comandos Bash não verá uma chamada via MCP. Na própria issue, pediram ao agente que investigasse um bug, e ele, por meio da automação do navegador, clicou em excluir e confirmar em um registro real de um banco de dados de produção.

Com as chaves é parecido. Um deny na leitura de .env fecha o arquivo, um hook de gravação rejeita uma alteração que contenha uma chave, mas a exibição de um segredo a partir do ambiente não é coberta por essas duas regras. Uma chave exposta não pode ser recuperada, por isso não se protege isso apenas com texto.

Hook Stop contra trabalho inacabado

Para que o agente não encerre o turno enquanto a verificação não passar, associa-se ao evento Stop um script que executa a verificação do projeto (por exemplo, make check) e, em caso de falha, sai com código 2. O código 2 bloqueia o encerramento, e o stderr chega ao agente como mensagem de erro. O código 1 sem saída não bloqueia a ação; isso foi verificado pela Caprock nas versões 2.1.289 e 2.1.299. Desde a 2.1.295, a opção onFailure: block bloqueia a ação mesmo quando o próprio hook falha.

Há um limite: após oito bloqueios seguidos sem chamadas de ferramentas, o Claude Code encerra o turno de qualquer maneira. O limite é elevado pela variável CLAUDE_CODE_STOP_HOOK_BLOCK_CAP, e em tarefas longas vale verificar se o hook não esbarra nele.

O que fazer

Trate o CLAUDE.md como um registro de falhas, não como uma declaração. Adicione uma linha após o segundo erro idêntico, mantenha o arquivo abaixo de 200 linhas, designe um responsável e revise as alterações como código. Uma entrada obsoleta prejudica mais do que a ausência dela.

Uma limitação da abordagem: os exemplos do artigo são ilustrativos, e a sintaxe exata deve ser conferida na página Configure permissions da documentação. A pergunta principal para o seu projeto é simples: quais três regras do seu arquivo custam dinheiro ou segredos? Mova essas primeiro para deny, hooks e verificações por código.