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

Em março de 2026, um bug de build do Bun incluiu source maps no pacote npm do Claude Code. Os arquivos .map continham o código-fonte completo e legível em TypeScript — cada módulo, cada comentário, cada codinome interno.¹ A Anthropic removeu o pacote rapidamente, mas a comunidade já tinha extraído e analisado os detalhes internos.

Este não é um post do tipo “olha o que vazou”. Eu mantenho o guia mais completo sobre Claude Code na internet e rodo 84 hooks, 43 skills e 19 agentes em cima dele diariamente.² O vazamento do código-fonte respondeu perguntas que eu vinha tentando descobrir por engenharia reversa comportamental há meses. O que segue é uma análise prática: o que o código-fonte revela sobre como o Claude Code realmente funciona, e o que isso significa para quem constrói em cima dele.

Resumo rápido: 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 verificações numeradas sugerindo incidentes reais de exploração (bashSecurity.ts), o cache de prompts rastreia 14 vetores de quebra com travas persistentes, a coordenação multi-agente é implementada inteiramente como instruções de system prompt, e a detecção de frustração usa regex — não inferência de LLM. A seção Por baixo dos panos do guia cobre as implicações para construtores de harness. Este post cobre a anatomia completa.

Principais conclusões

• Construtores de harness: O modo auto custa uma inferência de classificador por chamada de ferramenta. Considere isso nos modelos de custo para workflows autônomos. Seus hooks PreToolUse complementam, mas não substituem a validação de bash integrada com 23 verificações.
• Usuários avançados: O cache de prompts é frágil — 14 vetores podem quebrá-lo. Mantenha seu CLAUDE.md estável dentro de uma sessão. Se você entrar em loops de compactação, o sistema para após 3 falhas (antes gastava ~250 mil chamadas de API por dia antes do circuit breaker).
• 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 verificação 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 verifica se a ação corresponde à intenção declarada do usuário, não apenas se o comando é “seguro” isoladamente. Isso significa que o modo auto adiciona uma inferência de classificador por chamada de ferramenta — latência real e custo real.

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

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

2. Segurança do bash: 23 verificações, incidentes reais

O módulo de validação do bash (bashSecurity.ts) abrange 2.592 linhas com 23 verificações de segurança numeradas.¹ A profundidade é notável — e cada verificação 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 no Bash. O Claude Code roda no Zsh no macOS (o shell padrão desde o Catalina), e o código-fonte mostra que a Anthropic descobriu vetores de ataque únicos da semântica de expansão do Zsh. A expansão =cmd, por exemplo, é um recurso do Zsh que substitui =curl pelo caminho completo do curl — uma substituição que pode burlar listas de bloqueio ingênuas de comandos.

Para construtores de hooks: seus hooks PreToolUse rodam após essa validação de 23 verificações. Você está adicionando uma segunda camada, não a única camada. As verificações 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. Essas ferramentas falsas envenenam quaisquer dados de treinamento colhidos da sessão — um modelo treinado nesses dados 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 resumos criptográficos em vez de texto bruto. Isso torna a transcrição da conversa inútil para destilação enquanto preserva a experiência do usuário.

Ambas as defesas têm soluções conhecidas. Um proxy MITM, sobrescrita de variáveis de ambiente ou provedores terceiros de API podem contorná-las.¹ As defesas são lombadas, não muros — elas aumentam o custo da destilação sem impedi-la completamente.

4. Modo infiltrado

undercover.ts tem aproximadamente 90 linhas com uma propriedade notável: não existe botão para desligar.¹

O módulo oculta codinomes internos — “Capybara,” “Tengu” — junto com canais do Slack, repositórios internos e outras referências de infraestrutura da Anthropic. Quando o modelo gera texto que contém um codinome, o módulo infiltrado o reescreve antes que o usuário veja.

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

5. Detecção de frustração

userPromptKeywords.ts detecta frustração do usuário via correspondência regex de padrões de palavrões.¹ Isso é mais rápido e barato que uma chamada de inferência LLM — regex roda em microssegundos, uma chamada de modelo leva segundos.

Quando ativado, o Claude ajusta seu comportamento: mais cuidadoso, mais explícito, mais deferente. Se você já notou o Claude ficando subitamente mais cauteloso após expressar frustração, esse é o mecanismo. A mudança comportamental não é emergente do modelo — é projetada no harness.

6. Arquitetura do cache de prompts

promptCacheBreakDetection.ts rastreia 14 vetores distintos de quebra de cache com “travas persistentes.”³ Uma trava persistente significa que, uma vez que uma ação que quebra o cache ocorre, o sistema não tenta restaurar o cache — ele permanece quebrado 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 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 gradualmente ficam mais lentas. Cada mudança de configuração acumula quebras de cache. O design de “trava persistente” significa que você não consegue recuperar revertendo a mudança — o cache se foi para a sessão.

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

7. Circuit breaker do autocompact

Um comentário no 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 ~250 mil chamadas de API por 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 deste circuit breaker, uma sessão presa em um loop de compactação tentaria indefinidamente — cada tentativa consumindo tokens para o prompt e resposta de compactação. Em escala, 250 mil chamadas desperdiçadas de API por dia é um custo significativo de infraestrutura. A correção é uma mudança de três linhas que economiza milhões de tokens diariamente.

Se você encontrar erros repetidos de “compaction failed”, é por isso. O sistema está protegendo você de um loop infinito, não funcionando mal.

8. Modo coordenador: prompts como arquitetura

A coordenação multi-agente (coordinatorMode.ts) é implementada inteiramente como instruções de system prompt, não como 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.

Isso valida o padrão “prompts como arquitetura” que praticantes vinham construindo independentemente. O sistema de hooks que descrevi em Anatomy of a Claw usa a mesma abordagem: dispatchers, skills e agentes são orquestrados através de instruções de prompt, não através de fluxo de controle em nível de código.

Uma diretiva do prompt do coordenador se destaca:

“Nunca escreva ‘com base nas suas descobertas’ — essas frases delegam compreensão aos workers em vez de fazer você mesmo.”

Este é um controle de qualidade codificado no prompt de orquestração. O coordenador deve sintetizar, não retransmitir. O mesmo princípio se aplica a qualquer sistema multi-agente: se o orquestrador está apenas passando mensagens entre especialistas, ele não está agregando 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 somente com adição - Webhooks do GitHub para contexto ciente de 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 agentes persistentes e sempre ativos. A skill /dream é particularmente interessante — ela implica um modelo que processa e consolida sua memória enquanto ocioso, similar a como a consolidação de memória humana funciona durante o sono.

O recurso está bloqueado e ainda não foi lançado. Porém, 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 contexto em background.

10. O sistema de pet companheiro

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

O 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 nível de raridade:

Os pets são renderizados como sprites ASCII 5×12 com animações de 3 frames. Codinomes de espécies são codificados em hexadecimal no código-fonte porque um deles colide com o nome de um modelo não lançado.

Este 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 em ASCII significa zero overhead de performance. É um sistema de engajamento bem projetado escondido dentro de uma ferramenta de desenvolvimento.

11. A fork bomb

Um incidente na comunidade ilustra os riscos do sistema de hooks.⁵ Um desenvolvedor criou um hook SessionStart que gerava 2 instâncias do Claude Code. Cada instância gerada ativava 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 foi salvo de uma conta massiva de API por 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 escalar.

A lição para construtores de hooks: hooks SessionStart devem ser idempotentes. Se seu hook gera processos, esses processos não devem acionar o mesmo hook. Uma variável de guarda, um arquivo PID ou uma flag de ambiente previne a recursão.

O que isso significa

O vazamento do código-fonte confirmou o que praticantes vinham inferindo pelo 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 construtores de harness, as principais implicações são cobertas na seção Por baixo dos panos do guia. Para todos os demais, o vazamento do código-fonte oferece visibilidade rara sobre como uma ferramenta de IA em produção realmente funciona — não como o marketing a descreve, mas como o código a implementa.

A descoberta mais importante também é a mais simples: o sistema é mais complexo do que aparenta, e essa complexidade existe por motivos. As 23 verificações de segurança do bash existem porque 23 vetores de ataque foram descobertos. O circuit breaker do autocompact existe porque 250 mil chamadas de API eram desperdiçadas diariamente. O módulo infiltrado 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 afetada do pacote npm pouco depois que os source maps foram descobertos. A análise neste post é baseada na documentação da comunidade sobre o código-fonte antes de 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 verificações de segurança do bash funcionam não as torna mais fáceis de burlar — as verificações são determinísticas, não dependentes de obscuridade.

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

A descoberta mais prática é a fragilidade do cache de prompts. Se você modifica o CLAUDE.md, arquivos de regras ou configurações de MCP no meio da sessão, você quebra o cache de prompts. Configure tudo antes de iniciar uma sessão.

O que é o KAIROS?

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