Claude Code com 29 Ferramentas vs Codex com 7: As Filosofias de Design São Opostos Polares

Cansei de acompanhar as atualizações semanais do Claude Code e do Codex, então voltei aos princípios fundamentais. Abri cada definição de tipo do SDK, cada system prompt, cada schema de configurações que consegui encontrar. Queria entender não apenas o que cada ferramenta faz, mas por que a contagem de ferramentas diverge de forma tão dramática.

O Claude Code expõe 29 ferramentas. O Codex expõe 7. Essa proporção ficou me incomodando, porque não pode ser simplesmente uma lacuna de funcionalidades. Duas equipes bem financiadas com engenheiros de alto nível não chegam acidentalmente a uma proporção de 4:1. A diferença é intencional, e o raciocínio por trás dela revela duas filosofias genuinamente distintas sobre como a IA deve interagir com o seu ambiente de desenvolvimento.

Granularidade de Ferramentas É uma Decisão de Segurança

A diferença mais marcante está em como cada ferramenta lida com operações de arquivo. O Claude Code divide a manipulação de arquivos em quatro ferramentas separadas: Read, Write, Edit e MultiEdit. A busca também tem suas próprias ferramentas dedicadas, com Grep e Glob completamente independentes do Bash. Isso significa que você pode configurar o settings.json para permitir Read mas bloquear Write. Você pode deixar o agente pesquisar sua base de código sem nunca conceder permissão para modificar um único arquivo. O controle de permissões acontece no nível da ferramenta.

O Codex segue um caminho diferente. Ele fornece ao agente shell, apply_patch e file_read como primitivas centrais. Tudo mais passa pelo shell. Quer pesquisar arquivos? É um comando shell. Quer listar diretórios? Shell novamente. A segurança não vem de permissões no nível da ferramenta, mas de regras execpolicy que fazem correspondência de padrões em comandos shell específicos, classificando-os nas categorias allow, prompt ou block.

Nenhuma abordagem está errada. O modelo do Claude Code oferece travas granulares, mas exige manter uma superfície maior de ferramentas. O modelo do Codex é mais simples de raciocinar, mas transfere a aplicação de segurança para correspondência de strings em comandos shell, o que fica frágil quando os comandos ficam criativos. Já vi casos em que uma cadeia de pipes bem elaborada contorna uma regra execpolicy que foi escrita para a versão direta do mesmo comando.

O detalhamento completo:

• Claude Code (29 ferramentas): 4 ferramentas de arquivo (Read/Write/Edit/MultiEdit), 3 ferramentas de busca (Glob/Grep/LS), 2 ferramentas web, 3 ferramentas de cron, 4 ferramentas MCP, Bash e mais
• Codex (7 ferramentas): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

A Distribuição de Skills Divide o Ecossistema

Ambas as ferramentas adotaram o padrão aberto Agent Skills, onde um único arquivo SKILL.md define o comportamento de uma skill. A estrutura é idêntica. O modelo de distribuição não é.

O Codex criou um sistema de distribuição centralizado. Executar $skill-installer baixa skills curadas do repositório oficial de skills da OpenAI. Passe uma URL do GitHub e você pode instalar skills de terceiros também. Há até o $skill-creator para gerar novas skills de forma interativa através de conversa. A experiência parece com npm: um comando, um registry, disponibilidade imediata.

O Claude Code foi na direção oposta. Você cria arquivos SKILL.md em .claude/skills/ manualmente, ou instala bundles de repositórios git através de /plugin marketplace add. Não existe um registry oficial único. As skills são descobertas através de repositórios da comunidade, links compartilhados e boca a boca.

Inicialmente preferi o modelo centralizado do Codex porque a descoberta é melhor. Mas depois de usar os dois por várias semanas, a abordagem descentralizada tem uma vantagem genuína: posso editar um arquivo de skill durante a sessão e as alterações se aplicam imediatamente sem reiniciar. Com as skills instaladas do Codex, as alterações exigem reinstalação. Quando você está iterando em um fluxo de trabalho personalizado, essa diferença importa mais do que eu esperava.

Comparação rápida:

• Invocação: Claude Code usa /skill-name, Codex usa $skill-name
• Armazenamento: .claude/skills/ vs .agents/skills/
• Skills integradas: Claude Code vem com /simplify, /batch, /loop, /claude-api; Codex vem com $skill-installer, $skill-creator
• Distribuição: Marketplace descentralizado vs repositório centralizado

Diagnósticos de Sessão É Onde a Diferença Fica Real

Ambas as ferramentas compartilham o básico: /model, /plan, /review, /clear, /fast. A divergência aparece na introspecção de sessão.

O Claude Code investiu muito em deixar você entender o que está acontecendo dentro da sua sessão. /compact aciona manualmente a compressão de contexto. /context mostra o que está carregado. /cost rastreia o gasto de tokens em tempo real. /doctor diagnostica problemas de configuração. /rewind reverte para um estado anterior da conversa. /insights analisa um mês de padrões de uso e sugere melhorias. /usage mostra o consumo acumulado entre sessões. São sete comandos dedicados puramente a entender e gerenciar o estado da sessão.

O Codex focou em outro lugar. /personality ajusta o estilo de comunicação do agente. /theme muda a aparência visual. /apps gerencia aplicativos conectados. Esses são recursos de personalização de UX, não ferramentas de diagnóstico.

Isso reflete uma divisão filosófica mais profunda. O Claude Code trata a sessão como algo que você deve monitorar e direcionar ativamente. O Codex a trata como algo que deve simplesmente funcionar em segundo plano enquanto você se concentra em personalizar a experiência. Depois de meses de uso, percebo que quero os dois. Os diagnósticos me salvam quando uma sessão dá errado, mas também aprecio poder ajustar a personalidade quando alterna entre trabalho detalhado de arquitetura e correções rápidas de bugs.

• Claude Code (aproximadamente 35 comandos + 4 skills integradas): forte em diagnósticos de sessão como /compact, /context, /cost, /doctor, /rewind, /insights, /usage
• Codex (aproximadamente 19 comandos): mais forte em personalização de UX com /personality, /theme, /copy, /apps, /skills, /agent, /tools

Arquiteturas de Times Partem de Premissas Diferentes

A forma como cada ferramenta lida com colaboração multi-agente revela talvez a diferença de design mais profunda.

Os Agent Teams do Claude Code usam comunicação ponto a ponto. Os membros da equipe enviam mensagens diretamente uns para os outros sem passar por um agente líder. Eles compartilham uma lista de tarefas e se coordenam de forma autônoma. Você pode executar de 2 a 16 agentes, e eles negociarão entre si quem cuida de quê. Testei isso com três agentes em uma tarefa de refatoração, e o consumo de tokens foi de 3 a 7 vezes maior do que uma única sessão fazendo o mesmo trabalho. O overhead de coordenação é real. Mas quando a tarefa genuinamente se beneficia de exploração paralela (como depurar uma race condition onde você quer agentes investigando hipóteses diferentes simultaneamente), o modelo P2P encontra respostas mais rapidamente.

O Codex usa um modelo hub-spoke. Agentes filhos se reportam apenas ao pai. Não há comunicação lateral. O comando spawn_agents_on_csv cria agentes em massa a partir de um arquivo CSV, otimizado para tarefas paralelizáveis independentes onde cada unidade de trabalho é independente. Pense em: “aplique esta migração em 200 arquivos” ou “execute esta verificação em cada endpoint desta lista.”

P2P não é universalmente melhor. Desperdicei tokens significativos em uma tarefa de lote simples porque os agentes do Claude Code ficavam discutindo seus trabalhos sobrepostos entre si. O hub-spoke do Codex teria sido a escolha certa para aquele trabalho específico.

• Claude Code: mensagens P2P com lista de tarefas compartilhada, 2 a 16 agentes, suporte a tmux split-pane
• Codex: arquitetura hub-spoke, criação de agentes em massa via CSV com spawn_agents_on_csv

Granularidade de Hooks Determina a Profundidade de Automação

O Claude Code permite interceptar a execução de ferramentas em múltiplos pontos do ciclo de vida. PreToolUse é acionado antes de uma ferramenta ser executada, permitindo validar ou modificar a chamada. PostToolUse é acionado depois, para que você possa anexar um formatador que executa automaticamente em cada salvamento de arquivo. Hooks de Notification capturam comunicações do agente. PreCompact é acionado antes da compressão de contexto, dando a você a chance de preservar informações críticas. HTTP Hooks podem enviar JSON via POST para URLs externas, conectando o Claude Code a pipelines de CI, Slack ou dashboards personalizados.

O Codex mantém simples. Um arquivo execpolicy com regras allow/prompt/block aplicadas a comandos shell. Essa é toda a superfície de extensibilidade para controlar o comportamento do agente.

Configurei um hook PostToolUse que executa o Prettier após cada operação Write. Levou cinco minutos e eliminou uma categoria inteira de prompts de acompanhamento relacionados a formatação. Esse tipo de automação cirúrgica não é possível no modelo do Codex, onde você precisaria incluir “e execute o prettier após escrever” em cada prompt ou incorporá-lo a uma skill.

Mas a simplicidade do Codex também tem valor. Nunca quebrei acidentalmente minha configuração do Codex com um hook mal configurado. Fiz isso duas vezes com o Claude Code, uma vez com um hook PreToolUse que silenciosamente bloqueava leituras legítimas de arquivos e causou vinte minutos de depuração confusa.

• Claude Code: PreToolUse, PostToolUse, Notification, PreCompact e HTTP Hooks
• Codex: arquivo de regras execpolicy com três níveis (allow/prompt/block)

Escolha a Arquitetura, Não a Lista de Funcionalidades

A comparação de 29 vs 7 não é sobre uma ferramenta ser mais capaz do que a outra. É sobre duas respostas diferentes para a mesma pergunta de design: quanto um agente de IA para código deve decompor suas capacidades em unidades individualmente controláveis?

O Claude Code diz “tudo.” Cada operação tem sua própria ferramenta, sua própria superfície de permissões, seus próprios pontos de hook. Isso oferece controle máximo ao custo de complexidade de configuração. O Codex diz “apenas o essencial.” Operações centrais têm ferramentas dedicadas; tudo mais passa pelo shell com guardrails baseados em políticas. Isso oferece simplicidade ao custo de granularidade.

Quando escolho qual ferramenta usar para um projeto, a lista de funcionalidades mal importa. O que importa é se o projeto precisa de controle de permissões granular (base de código regulada, múltiplos colaboradores com diferentes níveis de acesso) ou de simplicidade leve (projeto solo, iteração rápida, configuração mínima). A arquitetura sobre a qual você constrói molda cada decisão de fluxo de trabalho que vem depois.