O código fonte do Claude Code vazou: 8 coisas que mudaram meu uso

Semana passada, alguém na Anthropic cometeu o tipo de erro que tira o sono de qualquer engenheiro de plataforma. Publicaram um pacote NPM que incluía um source map apontando direto pro TypeScript original dos servidores. Um pesquisador de segurança seguiu a trilha, e em poucas horas o código fonte completo do Claude Code estava espelhado no GitHub. Mais de 2.000 arquivos. Meio milhão de linhas de código de produção.

Eu uso Claude Code todo dia. É a ferramenta que roda no meu terminal enquanto escrevo código, refatoro módulos, rodo testes, planejo arquitetura. Quando vi a notícia, não fui atrás por curiosidade. Fui atrás porque queria entender a máquina que eu uso 8 horas por dia e nunca tinha visto por dentro.

O que encontrei mudou como eu uso a ferramenta. Não de forma incremental. De forma estrutural. Percebi que eu estava usando talvez 15% do que o Claude Code oferece, e que a diferença entre um usuário casual e um usuário avançado não está na qualidade dos prompts. Está na configuração do ambiente ao redor.

Separei 8 insights. Todos práticos. Todos que já estou aplicando.

1. Não é um chatbot no terminal: é um runtime de agente

A primeira coisa que o código fonte deixa óbvia é algo que a interface esconde: o Claude Code não é “o Claude rodando no terminal”. É um runtime de agente completo, construído com Bun, TypeScript e React, com uma arquitetura que mais parece um sistema operacional do que um wrapper de API.

Olha o que tem lá dentro: sistema de ferramentas com registro dinâmico, engine de permissões com múltiplas camadas, gerenciador de tarefas com fila e prioridade, coordenador multi-agente, cliente e servidor MCP, sistema de plugins, e um pipeline de execução que orquestra tudo isso.

O fluxo real de uma interação:

1. Seu input entra num parser CLI que extrai comandos, flags e contexto
2. Passa por um query engine que decide a estratégia de execução
3. Chama a API do LLM com o contexto montado
4. O retorno entra num loop de execução de ferramentas (que pode chamar o LLM de volta várias vezes)
5. O resultado é renderizado no terminal via React Ink

Se você está usando Claude Code como um chat onde digita perguntas e espera respostas de texto, está perdendo a maior parte do valor. O modelo é apenas uma peça. Os sistemas ao redor: ferramentas, permissões, memória, contexto, agentes. São eles que transformam uma conversa em automação real.

Entender isso muda a forma como você interage. Em vez de pensar “como eu formulo esse prompt melhor?”, você começa a pensar “como eu configuro esse ambiente melhor?”. A segunda pergunta tem retorno muito maior.

2. Os 85 comandos que (quase) ninguém usa

O código revela que existem aproximadamente 85 slash commands registrados no Claude Code. A maioria dos devs que eu conheço usa talvez 5. Alguns não sabem que existem.

Os que mais impactaram meu workflow:

/plan: Esse comando sozinho mudou como eu abordo tarefas complexas. Em vez de soltar o Claude Code pra sair editando arquivos, o /plan força ele a montar a abordagem inteira primeiro: quais arquivos serão tocados, em que ordem, quais dependências existem, e qual a estratégia. Só depois da sua aprovação ele executa.

Uso em toda tarefa que envolve mais de 2 arquivos. A diferença de qualidade é dramática. Sem plano, o Claude Code frequentemente começa editando um arquivo, descobre uma dependência, volta, edita outro, e o resultado fica fragmentado. Com plano, a execução é cirúrgica.

/compact: Comprime o histórico da conversa mantendo o que importa. Toda sessão longa acumula contexto que você não precisa mais: erros já corrigidos, abordagens descartadas, outputs intermediários. Cada token nesse histórico custa dinheiro e consome janela de contexto.

O truque que descobri: dá pra passar um prompt junto pra direcionar o que manter.

/compact mantém tudo sobre a integração com Stripe e ignora os erros de tipagem que já corrigimos

Isso é ouro quando você está numa sessão de 2 horas e precisa continuar com contexto limpo.

/review e /security review: Não são comandos genéricos de “revisa esse código”. São workflows estruturados e dedicados que rodam uma revisão completa com checklist interno. O /security review especificamente procura por padrões como secrets hardcoded, SQL injection, XSS, e problemas de autenticação. Rodo antes de todo PR.

/context: Gerencia quais arquivos o Claude Code está prestando atenção. Parece simples, mas é crítico. Cada arquivo no contexto custa tokens. Quando você abre um projeto grande e o Claude Code carrega 15 arquivos, você está queimando contexto (e dinheiro) com coisas que talvez não sejam relevantes pra tarefa atual. Esse comando dá visibilidade e controle.

/cost: Mostra o gasto acumulado da sessão. Eu checo isso várias vezes por dia. Não por paranoia, mas porque o custo é um sinal. Se uma tarefa simples está custando muito, geralmente significa que o contexto está poluído ou a abordagem está errada.

/resume: Retoma uma sessão anterior sem reexplicar tudo. Fechou o terminal, foi almoçar, voltou? /resume e você continua de onde parou. A alternativa é gastar 5 minutos reconstruindo contexto, pagando tokens por isso.

A conexão entre esses comandos e o ponto anterior é direta: eles só fazem sentido quando você para de tratar o Claude Code como chat e começa a tratar como um runtime que precisa ser operado.

3. CLAUDE.md é o arquivo mais importante do seu projeto

Se você só aplicar uma coisa desse post inteiro, que seja essa.

O CLAUDE.md é o centro do sistema de memória do Claude Code. Ele é injetado em toda sessão, antes de qualquer interação, como contexto prioritário. Não é documentação. Não é README. É contexto operacional: o equivalente a um documento de onboarding pra um dev novo que vai começar a trabalhar no seu projeto agora.

A maioria dos devs ignora o CLAUDE.md ou joga anotações aleatórias lá. Isso é um desperdício do input de maior alavancagem que você tem.

O que o código revela sobre o sistema de memória: existem múltiplas camadas. Memória no nível do usuário (preferências globais), CLAUDE.md no nível do projeto (contexto do repositório), memórias extraídas automaticamente de conversas anteriores, e até sincronização de memória de equipe. O CLAUDE.md é a camada que você controla diretamente e que tem mais peso.

Aqui está o modelo que eu uso no meu:

# Projeto: [nome]

## Stack
- TypeScript strict mode, sempre
- Next.js 15 com App Router
- Drizzle ORM + PostgreSQL
- pnpm (nunca npm ou yarn)
- Tailwind CSS + shadcn/ui

## Convenções
- Testes ficam em __tests__/ ao lado do arquivo fonte
- Nomes de arquivo: kebab-case
- Componentes: PascalCase
- Variáveis de ambiente: validadas via zod no env.ts
- Commits seguem Conventional Commits

## Regras invioláveis
- Nunca modificar schema do banco sem migration
- Nunca commitar .env ou credenciais
- Nunca usar any. Se não souber o tipo, pergunte
- Nunca deletar testes existentes sem aprovação explícita

## Arquitetura
- /src/app: rotas Next.js (App Router)
- /src/lib: lógica de negócio e utilitários
- /src/components: componentes React reutilizáveis
- /src/db: schema Drizzle, migrations, seeds

## Contexto atual
- Estamos migrando autenticação de next-auth v4 pra v5
- A API de pagamentos usa Stripe webhooks em /api/webhooks/stripe
- O módulo de notificações está sendo reescrito, não mexer sem alinhar

Repare no padrão: frases curtas, opinativas, sem ambiguidade. Não é documentação pra humanos. É instrução pra um agente. Cada linha é um constraint que evita que o Claude Code tome decisões erradas.

A seção “Contexto atual” é especialmente poderosa. Ela evita que o Claude Code mexa em coisas que estão em fluxo ou que têm dependências que ele não consegue inferir só olhando o código.

Atualize esse arquivo regularmente. Eu reviso o meu toda segunda-feira de manhã. 5 minutos que economizam horas de retrabalho na semana.

4. Permissões: a razão real pela qual ele parece lento

Se você usa Claude Code, já passou por isso: pede algo e ele fica pedindo permissão pra cada micro-ação. “Posso rodar git status? Posso ler esse arquivo? Posso editar essa função? Posso executar esse teste?” Cinco perguntas antes de fazer qualquer coisa. É frustrante. É lento. E faz você perder o fluxo.

A maioria dos usuários acha que a solução é escrever prompts mais específicos. Não é. A solução está no sistema de permissões.

O código revela um sistema com múltiplos modos: default (pergunta tudo), plan (planeja antes de executar), e modos como bypass/auto onde ele executa sem perguntar. Além dos modos, existem regras granulares com wildcard.

Aqui está um exemplo real do meu settings.json:

{
  "permissions": {
    "allow": [
      "bash:git *",
      "bash:pnpm test*",
      "bash:pnpm lint*",
      "bash:pnpm build*",
      "bash:ls *",
      "bash:cat *",
      "edit:src/**",
      "edit:tests/**"
    ],
    "deny": [
      "bash:rm -rf *",
      "bash:git push --force*",
      "edit:.env*",
      "edit:drizzle/migrations/**"
    ]
  }
}

A lógica é simples: allow pra tudo que você faz repetidamente e confia, deny pra o que nunca deve acontecer sem supervisão. O resto continua pedindo permissão.

Com essa configuração, tarefas que antes levavam 3 minutos de “sim, pode, sim, pode, sim, pode” agora fluem sem interrupção. O Claude Code roda git status, lê os arquivos, edita o código, roda os testes. Tudo automático. Só para pra perguntar quando tenta algo fora do escopo permitido.

A conexão com o ponto anterior é direta: um bom CLAUDE.md reduz erros, e boas permissões reduzem fricção. Juntos, eles transformam a experiência.

5. Arquitetura multi-agente: pare de fazer prompts gigantes

Essa me surpreendeu. O código revela um subsistema completo de coordenação multi-agente: agent tools, team tools, e um sistema de tarefas desenhado pra trabalho paralelo e em background.

Na prática, a arquitetura suporta decomposição: dividir trabalho entre múltiplos agentes rodando em paralelo. Um agente explorando o codebase, outro implementando mudanças, outro validando testes. Não é ficção. É a infraestrutura real que está lá.

Antes de entender isso, meu padrão era o prompt monstro:

Refatora o módulo de autenticação inteiro, atualiza todos os testes,
arruma a documentação, e garante que nada quebrou.

O resultado era inconsistente. O Claude Code tentava fazer tudo de uma vez, perdia contexto no meio, e o output era medíocre.

Agora eu decomponho em fases, e cada fase tem um objetivo claro:

1. Fase de pesquisa: “Analise o módulo de autenticação. Liste todos os arquivos envolvidos, dependências externas, e testes existentes. Não mude nada.”

2. Fase de planejamento: “Com base na análise, monte um plano de refatoração. Quais arquivos mudam, em que ordem, e quais riscos existem?”

3. Fase de execução: “Execute o plano aprovado. Comece pelo [arquivo X].”

4. Fase de verificação: “Rode todos os testes. Compare o comportamento antes e depois. Liste qualquer regressão.”

Os resultados são drasticamente melhores. Não porque o modelo é mais inteligente numa fase do que na outra, mas porque cada fase tem contexto limpo e objetivo definido. O agente não precisa manter na cabeça simultaneamente o que está investigando, o que está mudando, e o que está validando.

Isso se conecta diretamente com o /plan e o /compact: use /plan pra estruturar, execute, use /compact pra limpar o contexto, e passe pra próxima fase.

6. MCP, plugins e skills: o Claude Code como camada de integração

Se você acompanha o ecossistema, já ouviu falar de MCP (Model Context Protocol). O que o código confirma: MCP não é um recurso secundário. Está embutido na arquitetura fundamental. O Claude Code é tanto cliente quanto servidor MCP simultaneamente.

Isso significa duas coisas:

Como cliente MCP, o Claude Code pode se conectar a qualquer servidor MCP externo. Banco de dados, APIs internas, ferramentas de monitoramento, sistemas de documentação, plataformas de deploy. Se tem um servidor MCP, o Claude Code acessa.

Como servidor MCP, o Claude Code expõe suas próprias capacidades pra outros sistemas. Outros agentes, IDEs, pipelines de CI/CD podem chamar o Claude Code como ferramenta.

Mas vai além do MCP. O código também revela uma camada de skills e plugins que permite criar workflows repetíveis e capacidades customizadas. Dá pra construir extensões específicas pro seu domínio que o Claude Code executa como comandos nativos.

É aqui que a ferramenta para de ser “IA que escreve código” e vira uma camada de integração do seu ambiente de desenvolvimento. Quanto mais sistemas você conecta, mais contexto o agente tem, e melhores são as decisões.

Um exemplo prático: se você conecta seu banco de dados via MCP, o Claude Code pode consultar o schema real antes de sugerir uma query. Se você conecta seu sistema de tickets, ele pode ler a spec da task antes de começar a implementar. Se você conecta seu APM, ele pode ver os erros de produção antes de debugar.

Cada conexão elimina uma rodada de “deixa eu te explicar o contexto”. O agente já sabe.

7. Features escondidas atrás de flags internas

O código inclui verificações de userType, e um dos valores é ant, que representa Anthropic. Existem funcionalidades inteiras atrás de feature flags que só usuários internos acessam: voice mode, um sistema chamado Chyros, daemon mode, coordinator mode.

Não dá pra saber exatamente o quanto a experiência interna difere da nossa. Alguns podem ser protótipos em teste. Outros podem estar a semanas de lançar publicamente. Mas isso explica um padrão que quem acompanha já notou: o Claude Code tem lançado features num ritmo absurdo nos últimos meses. Elas não estavam sendo construídas do zero. Estavam prontas internamente, sendo testadas, e agora estão sendo liberadas.

A implicação prática: fique de olho nas atualizações. Quando features como daemon mode ou coordinator mode chegarem, quem já entende a arquitetura subjacente, o sistema de agentes, o pipeline de execução, as camadas de permissão, vai conseguir adotar imediatamente. Quem trata o Claude Code como uma caixa preta vai precisar reaprender do zero.

E tem mais: investir tempo entendendo a ferramenta que você usa todo dia tem retorno composto. Cada insight se acumula e amplifica os próximos.

8. O maior insight: ambiente operacional > prompts melhores

Se eu tivesse que condensar tudo que o código fonte revelou em uma única frase: os melhores usuários do Claude Code não escrevem prompts melhores. Eles projetam ambientes operacionais melhores.

Prompt é input de uma interação. Ambiente operacional é infraestrutura que funciona em toda interação.

Pense na diferença: você pode gastar 5 minutos escrevendo o prompt perfeito pra uma tarefa, e isso melhora aquela tarefa específica. Ou você pode gastar 30 minutos configurando CLAUDE.md, permissões, conexões MCP, e workflows, e isso melhora toda tarefa que você fizer pelos próximos meses.

É composição, não repetição. Um bom CLAUDE.md faz o agente tomar decisões melhores, o que reduz retrabalho, o que reduz custo de contexto, o que permite sessões mais longas e produtivas. Boas permissões eliminam fricção, o que mantém seu fluxo, o que te permite decompor tarefas melhor, o que produz resultados melhores. Cada camada amplifica a outra.

Aqui está o checklist que eu sigo:

1. CLAUDE.md como multiplicador: Curto, opinativo, atualizado toda semana. É o documento mais importante do seu repositório pra trabalho com IA.

2. Domine os comandos de operação: /plan antes de tarefas complexas. /compact quando a conversa ficar longa. /context pra gerenciar o que está carregado. /cost pra monitorar gasto. /review antes de PRs. /resume entre sessões.

3. Configure permissões uma vez: 10 minutos no settings.json eliminam horas de fricção acumulada. Permita o que você faz todo dia, bloqueie o que nunca deve acontecer automaticamente.

4. Decomponha em fases: Pesquisa, planejamento, execução, verificação. Cada fase com contexto limpo e objetivo claro. O agente trabalha melhor quando sabe exatamente o que precisa fazer.

5. Gerencie contexto como orçamento: Porque literalmente é. Cada arquivo carregado, cada mensagem no histórico, cada output intermediário custa tokens. Use /compact, use /context, seja intencional.

6. Conecte tudo que puder via MCP: Banco de dados, APIs, ferramentas internas. Cada conexão é contexto que você não precisa explicar manualmente.

7. Trate como infraestrutura, não como ferramenta: O Claude Code tem configuração pra roteamento de modelo, override de sub-agentes, controles de privacidade, e roteamento por backends como AWS Bedrock e Google Vertex. É infraestrutura de desenvolvimento. Trate como tal.

A lógica por trás de tudo isso é contra-intuitiva pra quem vem do mundo de “prompt engineering”. No modelo mental de prompts, o valor está na formulação. No modelo mental de agentes, o valor está no ambiente. O prompt é efêmero. O ambiente persiste.

Quando você configura um ambiente operacional bem montado, até prompts mediocres produzem bons resultados. Quando o ambiente é pobre, até prompts brilhantes produzem resultados inconsistentes. O código fonte do Claude Code deixou isso cristalino: a arquitetura inteira foi desenhada pra ser configurada, estendida e composta. Os prompts são só a ponta do iceberg.

FAQ

O código fonte ainda está disponível?

A Anthropic já disparou DMCA takedowns pros repositórios espelhados no GitHub. Os mirrors principais foram removidos. Mas as análises, threads, e insights que as pessoas extraíram continuam circulando. Os conceitos arquiteturais que descrevi aqui são visíveis no comportamento público da ferramenta.

Preciso acessar o código fonte pra aproveitar esses insights?

Não. Tudo que cobri nesse post são funcionalidades que existem no Claude Code público. O código fonte só revelou a profundidade, deu nome aos sistemas internos, e confirmou coisas que muitos suspeitavam mas não tinham como verificar.

Vale a pena configurar tudo isso se eu uso Claude Code esporadicamente?

Se você usa pelo menos uma vez por dia, configurar o CLAUDE.md e as permissões já compensa. São 15 minutos de setup que mudam a experiência de forma permanente. Se você usa mais que isso, conectar servidores MCP e dominar os slash commands é o próximo passo natural.

Isso funciona com outros modelos além do Claude?

Os conceitos de ambiente operacional se aplicam a qualquer agente de código. Mas os detalhes de implementação: CLAUDE.md, slash commands, sistema de permissões, MCP integrado. São específicos do Claude Code.