O que o vazamento do código-fonte do Claude Code revela

Em março de 2026, um bug de build do Bun enviou source maps no pacote npm do Claude Code. Os arquivos .map continham todo o código-fonte legível do TypeScript: cada módulo, cada comentário, cada codinome interno.¹ A Anthropic removeu o pacote rapidamente, mas a comunidade já havia extraído e analisado as entranhas.

O vazamento do código-fonte do Claude Code revelou que o modo auto executa um classificador Sonnet 4.6 separado por chamada de ferramenta, a segurança do bash usa 23 checagens numeradas sugerindo incidentes reais de exploração, e o prompt caching rastreia 14 vetores de quebra com travas fixas. O código também expôs defesas anti-destilação usando injeção de ferramentas falsas, um módulo undercover que remove codinomes internos sem opção de desligamento forçado, e coordenação multi-agente implementada inteiramente como instruções de system prompt em vez de código dedicado de protocolo.

Não estou escrevendo um post do tipo “olha o que vazou”. Eu mantenho o guia mais completo sobre Claude Code da internet e rodo 84 hooks, 43 skills e 19 agents em cima dele diariamente.² O vazamento do código-fonte respondeu a perguntas que eu vinha fazendo engenharia reversa através de observação comportamental há meses. O que segue é uma análise de quem usa na prática sobre o que o código-fonte revela sobre como o Claude Code realmente funciona, e o que as descobertas significam para quem constrói em cima dele.

TL;DR: O código-fonte confirma que o modo auto executa um classificador Sonnet 4.6 separado por chamada de ferramenta (yoloClassifier.ts), a segurança do bash tem 23 checagens numeradas sugerindo incidentes reais de exploração (bashSecurity.ts), o prompt caching rastreia 14 vetores de quebra com travas fixas, a coordenação multi-agente vive inteiramente em instruções de system prompt, e a detecção de frustração usa regex, não inferência de LLM. A seção Under the Hood do guia cobre as implicações para quem constrói. O post abaixo cobre a anatomia completa.

Principais conclusões

• Para quem constrói: O modo auto custa uma inferência de classificador por chamada de ferramenta. Leve em conta essa sobrecarga em modelos de custo para fluxos autônomos. Seus hooks PreToolUse complementam mas não substituem a validação bash integrada de 23 checagens.
• Para usuários avançados: O prompt cache quebra facilmente em 14 vetores. Mantenha seu CLAUDE.md estável dentro de uma sessão. Se você bater em loops de compactação, o sistema para após 3 falhas (o disjuntor existe porque a compactação tentando novamente chegou a desperdiçar 250K chamadas de API/dia).
• Para pesquisadores de segurança: A profundidade do módulo de segurança do bash (2.592 linhas, defesas específicas para Zsh) sugere um histórico de tentativas reais de exploração. Cada checagem numerada tem uma história por trás.

1. O classificador do modo auto

O arquivo internamente chamado yoloClassifier.ts tem 1.495 linhas.³ Ele implementa o sistema de permissões do “modo auto”, o classificador que decide se permite, bloqueia ou pergunta sobre cada chamada de ferramenta.

A descoberta principal: o modo auto não é uma instrução de prompt. É uma chamada de modelo separada. Cada invocação de ferramenta é avaliada por um classificador Sonnet 4.6 que checa se a ação corresponde à intenção declarada pelo usuário, não apenas se o comando é “seguro” isoladamente. Portanto, o modo auto adiciona uma inferência de classificador por chamada de ferramenta, introduzindo latência real e custo real.

O Claude Code expõe cinco modos de permissão internamente:¹

O disjuntor do modo auto espelha aquele que a Anthropic documentou publicamente: 3 bloqueios consecutivos ou 20 no total pausam para manual.⁴ O código-fonte confirma que isso é um limite rígido, não uma sugestão suave.

2. Segurança do bash: 23 checagens, incidentes reais

O módulo de validação do bash (bashSecurity.ts) abrange 2.592 linhas com 23 checagens de segurança numeradas.¹ A profundidade é notável, e cada checagem sugere um incidente real por trás.

As defesas específicas para Zsh são notáveis. A maioria das ferramentas de segurança mira o Bash. O Claude Code roda em Zsh no macOS (o shell padrão desde o Catalina), e o código-fonte mostra que a Anthropic descobriu vetores de ataque únicos à semântica de expansão do Zsh. A expansão =cmd, por exemplo, é um recurso do Zsh que substitui =curl pelo caminho completo para o curl, uma substituição que pode burlar blocklists ingênuas de comandos.

Para quem constrói hooks: seus hooks PreToolUse rodam após essa validação de 23 checagens. Você está adicionando uma segunda camada, não a única camada. As checagens integradas lidam com ataques em nível de shell que seus hooks em nível de aplicação não detectariam.

3. Defesas anti-destilação

O código-fonte revela defesas ativas contra extração de dados de treinamento:¹

Injeção de ferramentas falsas. Quando a flag ANTI_DISTILLATION_CC está habilitada, o Claude Code injeta definições de ferramentas falsas na conversa. As ferramentas falsas envenenam quaisquer dados de treinamento coletados da sessão. Um modelo treinado com dados envenenados aprenderia schemas de ferramentas incorretos.

Sumarização de texto conector. Uma segunda defesa armazena em buffer o texto do assistente entre chamadas de ferramenta e retorna sumários criptográficos em vez do texto bruto. Os sumários deixam as transcrições da conversa inúteis para destilação enquanto preservam a experiência do usuário.

Ambas as defesas têm workarounds conhecidos. Um proxy MITM, overrides de variáveis de ambiente ou provedores de API terceirizados podem burlá-las.¹ As defesas funcionam como redutores de velocidade, não como muros: elas elevam o custo da destilação sem impedi-la completamente.

4. Modo undercover

O undercover.ts tem aproximadamente 90 linhas com uma propriedade notável: não há opção de desligamento forçado.¹

O módulo oculta codinomes internos (“Capybara”, “Tengu”), canais do Slack, repositórios internos e outras referências de infraestrutura da Anthropic. Quando o modelo gera texto contendo um codinome, o módulo undercover o reescreve antes que o usuário veja a saída.

O design “sem desligamento forçado” significa que o módulo roda em todos os contextos, inclusive quando funcionários da Anthropic usam o Claude Code. O código-fonte também revela que commits autorados por IA de funcionários da Anthropic não carregam atribuição de IA em suas contribuições open source porque o módulo undercover remove esses marcadores.

5. Detecção de frustração

O userPromptKeywords.ts detecta frustração do usuário via correspondência de padrões regex em palavrões.¹ Regex roda em microssegundos; uma chamada de modelo leva segundos. A diferença de velocidade e custo explica a escolha de design.

Quando acionado, o Claude ajusta seu comportamento: mais cuidadoso, mais explícito, mais deferente. Se você notou o Claude se tornando subitamente mais cauteloso depois de você expressar frustração, o módulo de palavras-chave é o mecanismo. A mudança comportamental não é emergente do modelo. Está engenheirada na camada de orquestração.

6. Arquitetura do prompt cache

O promptCacheBreakDetection.ts rastreia 14 vetores distintos de quebra de cache com “travas fixas”.³ Uma trava fixa significa que, uma vez que uma ação que quebra o cache ocorre, o sistema não tenta restaurar o cache. A quebra persiste pelo resto da sessão.

Implicações práticas para usuários diários:

• Reordenar seções no seu CLAUDE.md quebra o cache
• Alternar o extended thinking no meio da sessão quebra o cache
• Mudar configurações de servidor MCP quebra o cache
• Adicionar ou remover arquivos de regras quebra o cache

Os 14 vetores explicam um padrão que muitos usuários avançados notaram: sessões que começam rápidas vão ficando lentas gradualmente. Cada mudança de configuração acumula quebras de cache. O design de “trava fixa” significa que você não pode se recuperar revertendo a mudança. Uma vez quebrado, o cache permanece quebrado durante a sessão.

Melhor prática: Defina seu CLAUDE.md, arquivos de regras e configuração do MCP antes de iniciar uma sessão. Não os modifique no meio da sessão.

7. Disjuntor do autocompact

Um comentário do código-fonte documenta a escala de um problema anterior:¹

“1.279 sessões tiveram mais de 50 falhas consecutivas de autocompact (até 3.272 em uma única sessão), desperdiçando ~250K chamadas de API/dia.”

A correção: MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3. Após 3 falhas consecutivas de compactação, o sistema interrompe o autocompact e exibe um erro em vez de queimar tokens silenciosamente.

Antes do disjuntor, uma sessão presa em um loop de compactação tentava novamente indefinidamente, com cada tentativa consumindo tokens para o prompt e a resposta de compactação. Em escala, 250K chamadas de API desperdiçadas por dia representam um custo significativo de infraestrutura. A correção é uma mudança de três linhas que economiza milhões de tokens diariamente.

Se você bate em erros repetidos de “compaction failed”, o disjuntor está te protegendo de um loop infinito, não funcionando mal.

8. Modo coordenador: prompts como arquitetura

A coordenação multi-agente (coordinatorMode.ts) vive inteiramente em instruções de system prompt, não em orquestração em nível de código.³ O modelo orquestrador recebe um prompt descrevendo como delegar, agregar e sintetizar. Os agentes subordinados não são processos especiais. São instâncias do Claude com system prompts diferentes.

O design valida o padrão “prompts como arquitetura” que praticantes construíram de forma independente. O sistema de hooks que descrevi em Anatomy of a Claw usa a mesma abordagem: dispatchers, skills e agents operam através de instruções de prompt, não através de controle de fluxo em nível de código.

Uma diretiva do prompt do coordenador se destaca:

“Nunca escreva ‘com base nas suas descobertas’ — essas frases delegam o entendimento para os workers em vez de fazer isso você mesmo.”

A diretiva funciona como um portão de qualidade codificado no prompt de orquestração. O coordenador precisa sintetizar, não retransmitir. O mesmo princípio se aplica a qualquer sistema multi-agente: se o orquestrador apenas passa mensagens entre especialistas, ele não adiciona valor.

9. KAIROS: o agente autônomo não lançado

O código-fonte contém referências a um recurso não lançado chamado KAIROS, um agente autônomo com memória persistente.¹

Componentes principais: - Uma skill /dream para destilação noturna de memória - Logs diários append-only - Webhooks do GitHub para contexto ciente do repositório - Um daemon em background com refresh via cron de 5 minutos - Feature gates impedindo a ativação

O KAIROS parece ser a resposta da Anthropic para assistentes de agente persistentes e sempre ligados. A skill /dream é particularmente interessante porque implica um modelo que processa e consolida memória enquanto ocioso, similar a como a consolidação de memória humana funciona durante o sono.

Feature gates impedem a ativação, e a Anthropic não lançou o KAIROS. Mas sua presença no código-fonte sinaliza a direção: o Claude Code está evoluindo de uma ferramenta baseada em sessão para um agente persistente e ciente do background.

10. O sistema de pet companheiro

Uma das descobertas mais surpreendentes: o Claude Code inclui um sistema de pet companheiro.¹

Cada pet é determinístico, derivado de um hash do ID do usuário usando Mulberry32, descrito no código-fonte como “bom o suficiente para escolher patos”. Cada pet tem 5 atributos (DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK) e um tier de raridade:

O sistema renderiza pets como sprites ASCII 5x12 com animações de 3 frames. O código-fonte codifica em hex os codinomes de espécie porque um colide com o nome de um modelo não lançado.

O sistema de companheiro não é um recurso de piada. É uma mecânica de retenção. A atribuição determinística significa que seu pet é sempre o mesmo, criando apego. O sistema de raridade cria moeda social. A renderização ASCII significa zero overhead de performance. A Anthropic construiu um sistema de engajamento bem projetado e o escondeu dentro de uma ferramenta para desenvolvedores.

11. A fork bomb

Um incidente da comunidade ilustra os riscos do sistema de hooks.⁵ Um desenvolvedor criou um hook SessionStart que iniciava 2 instâncias do Claude Code. Cada instância iniciada acionava o hook novamente, criando crescimento exponencial: 1 → 2 → 4 → 8 → 16 → 2^N.

Pela manhã, centenas de instâncias do Claude Code estavam rodando simultaneamente. O sistema evitou uma conta enorme de API através de um mecanismo irônico: o consumo de memória de cada instância (Bun, React, TUI) fez a máquina travar antes que a cobrança pudesse disparar.

A lição para quem constrói hooks: hooks SessionStart precisam ser idempotentes. Se seu hook inicia processos, esses processos não podem acionar o mesmo hook. Uma variável de guarda, um arquivo PID ou uma flag de ambiente impede a recursão.

O que isso significa

O vazamento do código-fonte confirmou o que praticantes haviam inferido a partir do comportamento: o Claude Code não é um wrapper fino em torno de uma chamada de API. É um sistema de engenharia substancial com camadas de segurança, otimizações de performance, ajustes comportamentais e recursos não lançados que sinalizam o roadmap do produto.

Para quem constrói, as implicações principais aparecem na seção Under the Hood do guia. Para todos os outros, o vazamento do código-fonte fornece uma visibilidade rara de como uma ferramenta de IA em produção realmente funciona — não como o marketing descreve, mas como o código implementa.

A descoberta mais importante também é a mais simples: o sistema é mais complexo do que aparenta, e essa complexidade existe por razões. As 23 checagens de segurança do bash existem porque 23 vetores de ataque foram descobertos. O disjuntor do autocompact existe porque 250K chamadas de API foram desperdiçadas diariamente. O módulo undercover existe porque codinomes vazam. Cada linha de código defensivo tem uma história por trás.

Fontes

Perguntas frequentes

O código-fonte do Claude Code ainda está disponível?

Não. A Anthropic removeu a versão do pacote npm afetada logo após os source maps serem descobertos. A análise neste post é baseada em documentação da comunidade do código-fonte antes de ele ser removido.

O vazamento do código-fonte afeta a segurança do Claude Code?

As descobertas relevantes para segurança (validação do bash, sistema de permissões) descrevem mecanismos defensivos, não vulnerabilidades. Saber como as checagens de segurança do bash funcionam não as torna mais fáceis de burlar porque as checagens são determinísticas, não dependentes de obscuridade.

Devo mudar como uso o Claude Code com base nessas descobertas?

A descoberta mais acionável é a fragilidade do prompt cache. Se você modificar CLAUDE.md, arquivos de regras ou configurações do MCP no meio da sessão, você quebra o prompt cache. Defina sua configuração antes de iniciar uma sessão.

O que é KAIROS?

Um recurso de agente autônomo não lançado encontrado no código-fonte. Ele inclui memória persistente, destilação noturna e processamento em background. Está feature-gated e não disponível para usuários.