Claude Code, Codex e Cursor: o que muda de fato

Os três leem AGENTS.md. Os três rodam Agent Skills no mesmo formato. Os três conectam MCP. A comparação de features, que era o assunto em 2025, empatou.

O que restou de diferença é mais interessante e menos discutido: onde cada um guarda o contexto persistente, e quando ele decide carregar. É aí que o trabalho diário muda.

Antes de qualquer tabela, o escopo.

Isto é uma comparação da documentação oficial dos três produtos, lida e citada. Não é um teste controlado. Não medi velocidade, não contei tarefas concluídas, não rodei o mesmo problema nos três para ver quem resolve melhor.

Comparação de agente de código sem metodologia é opinião com aparência de dado, e o mercado está cheio disso. O que dá para fazer com honestidade é comparar o que cada fornecedor documenta, porque isso é verificável e é o que decide como você organiza o projeto.

Vale registrar o tamanho da mudança. Há um ano, escolher um agente de código significava escolher um ecossistema fechado de configuração. Hoje:

O formato Agent Skills foi criado pela Anthropic e liberado como padrão aberto. Hoje aparece na lista de clientes compatíveis ao lado de Cursor, Gemini CLI, Copilot, OpenCode, Goose e dezenas de outros.

O efeito prático para quem escreve: uma skill bem feita vale nos três. Se você ficar dentro dos seis campos da spec (name, description, license, compatibility, metadata e allowed-tools), ela é portável. Usar campo específico de um cliente é o que prende.

O formato completo está em como escrever a sua primeira Agent Skill, incluindo os seis campos que garantem portabilidade.

Esta é a diferença que muda o dia a dia, e os três resolvem de formas distintas.

Claude Code, hierarquia que concatena. Sobe a árvore de diretórios a partir do diretório atual e junta tudo que encontra: política gerenciada, usuário, projeto e local. Os arquivos não se sobrescrevem, se somam, na ordem da raiz para baixo. O alvo oficial é abaixo de 200 linhas por arquivo, porque tudo entra no contexto de toda sessão. O que passa disso vai para .claude/rules/ com paths ou vira skill.

Cursor, quatro tipos de gatilho. As regras de projeto vivem em .cursor/rules como arquivos .mdc, markdown com frontmatter. E aqui está a diferença de modelo: o frontmatter define quando a regra entra.

Note o segundo. "Apply Intelligently" delega ao agente a decisão de relevância da própria regra, algo que o CLAUDE.md não tem, porque lá tudo carrega sempre. É um modelo diferente de economia de contexto: em vez de você decidir o que sempre carrega, o agente decide o que é pertinente agora.

O Cursor também aceita AGENTS.md como alternativa simples, sem metadados, e suporta aninhamento: um AGENTS.md em subdiretório dá instrução mais específica para aquela área do código. Arquivos .md comuns são ignorados — só AGENTS.md escapa da regra.

Codex, AGENTS.md como configuração central. A documentação descreve o arquivo como definidor de comportamento e capacidades do agente. É o modelo mais enxuto dos três.

Vale a comparação direta:

A anatomia de um CLAUDE.md que funciona detalha os quatro escopos e o que fazer quando o arquivo passa do teto.

O SKILL.md é idêntico. Onde cada um procura, não.

O Cursor procura em dois caminhos de cada nível, e um deles é o .agents/skills/, o diretório neutro do padrão aberto. Isso tem uma consequência prática boa: skill instalada ali é encontrada pelos dois clientes sem duplicação.

O Cursor também tem campos próprios de frontmatter que o Claude Code não usa, como icon e color para badges de modo customizado, e um comando /migrate-to-skills para converter regras existentes em skills.

E há a assimetria de precedência que vale conhecer se você mantém as duas coisas: no Claude Code, skill pessoal sobrepõe skill de projeto, enquanto subagente de projeto sobrepõe subagente pessoal. Mesma estrutura de pastas, comportamento invertido entre as duas features.

A assimetria está detalhada em subagentes: quando delegar e quando não.

Suportado nos três, com documentação de profundidade diferente.

O Claude Code é o que documenta mais detalhe público: três escopos de instalação com precedência definida, quatro transportes, expansão de variável de ambiente no .mcp.json, limites de saída com números explícitos e um mecanismo de tool search que adia as definições de ferramenta.

Codex e Cursor documentam suporte a MCP sem esse nível de especificação pública. Isso não significa que implementam menos — significa que a comparação nesse eixo não é possível de fazer com honestidade a partir de documentação.

É o tipo de limite que uma comparação séria precisa declarar em vez de preencher com suposição.

Os detalhes do lado do Claude Code estão em MCP na prática.

Aqui está a distinção mais profunda que encontrei, e ela não é de feature — é de camada onde a restrição acontece.

O Codex separa em dois eixos independentes. O sandbox_mode define o que ele é tecnicamente capaz de fazer; o approval_policy define quando ele precisa perguntar.

E o ponto que muda a natureza da garantia: a restrição é aplicada pelo sistema operacional. Seatbelt com sandbox-exec no macOS, bwrap mais seccomp no Linux, sandbox próprio no Windows nativo, semântica de Linux no WSL2. Caminhos como .git, .agents e .codex ficam somente-leitura independentemente do modo.

O Claude Code tem as duas camadas, com padrões diferentes. A de aplicação vem ligada: permissions.deny nas configurações bloqueia ferramenta, comando ou caminho, e os seis modos de permissão (default, acceptEdits, auto, dontAsk, bypassPermissions e plan) definem quanto ele pergunta. Regras de configuração são aplicadas pelo cliente independentemente do que o modelo decidir, e um hook PreToolUse saindo com código 2 bloqueia a chamada de forma determinística.

A camada de sistema operacional também existe, e é opcional. O sandbox do Bash usa Seatbelt no macOS e bubblewrap no Linux e no WSL2, com o SO aplicando o limite a todo comando e a todo processo filho. Windows nativo não é suportado. Você liga com /sandbox.

É aí que a diferença real aparece, e ela é de padrão, não de capacidade: no Codex o sandbox é o estado inicial, no Claude Code alguém precisa escolher ligar. O detalhamento de cada camada e de como elas se combinam está em permissões e auto mode.

Sandbox de SO é mais difícil de contornar; permissão de aplicação é mais fácil de ajustar por caso. Quem roda agente em ambiente sensível provavelmente prefere a primeira; quem precisa de regra fina por comando, a segunda.

Para o Cursor, não encontrei documentação pública com profundidade comparável nesse eixo. Como nos outros pontos deste post, prefiro registrar a ausência a preencher com suposição.

Superfícies documentadas:

O Codex descreve a maior variedade: aplicativo desktop, CLI, extensão de IDE, ambiente na nuvem, interface web e conexões remotas.

O Claude Code roda no terminal, em aplicativo desktop, na web e em extensões de IDE.

O Cursor é, na origem, um editor — a superfície é o próprio IDE.

Modelos:

Aqui há uma diferença estrutural. O Codex usa modelos da OpenAI, com seleção conforme o caso de uso. O Claude Code usa modelos Claude. O Cursor se posiciona como agnóstico de modelo.

Essa é a única diferença desta lista que não muda com a próxima release: o Cursor é o único dos três que não é o cliente oficial de um laboratório. Se independência de fornecedor é critério para você, ela pesa aqui.

Não vou dizer qual é melhor, porque não testei os três de forma controlada e ninguém deveria confiar em quem diz sem ter testado.

O que dá para oferecer são critérios de decisão, ancorados no que está documentado:

Se o seu contexto é grande e estável, o modelo do Claude Code favorece você: hierarquia que concatena, previsível, com escopo por caminho para o que não é universal.

Se o seu contexto é grande e situacional, o modelo de quatro gatilhos do Cursor endereça isso diretamente — principalmente o "Apply Intelligently", que não tem equivalente nos outros dois.

Se você trabalha em superfícies variadas (terminal num dia, nuvem no outro, IDE no terceiro), a lista do Codex é a mais longa que encontrei documentada.

Se independência de fornecedor de modelo é requisito, o Cursor é o único que se posiciona assim.

E se você já tem skills escritas, a resposta é confortável: dentro dos seis campos da spec aberta, elas funcionam nos três. A escolha ficou reversível, o que não era verdade um ano atrás.

Qual é o melhor dos três?

Não sei, e desconfie de quem responde sem mostrar metodologia. Este post compara o que os três documentam, não o que eles entregam sob teste. A diferença documentada mais relevante é o modelo de contexto, e ela favorece perfis de projeto diferentes.

Minha skill funciona nos três?

Se usar apenas os seis campos da spec Agent Skills (name, description, license, compatibility, metadata e allowed-tools), sim. Campo específico de um cliente, como context: fork do Claude Code ou icon do Cursor, prende a skill àquele cliente e pode até falhar no empacotamento.

Dá para usar AGENTS.md e CLAUDE.md juntos?

Dá, e é o padrão recomendado. O Claude Code não lê AGENTS.md diretamente — a saída é um CLAUDE.md que o importa com @AGENTS.md, e o Next.js 16 gera exatamente esse par automaticamente quando detecta um agente no ambiente.

Vale migrar regras do Cursor para skills?

O Cursor oferece o comando /migrate-to-skills para isso, mas com uma ressalva documentada: regras com alwaysApply: true ou com padrões glob específicos mantêm comportamento próprio. A migração faz mais sentido para o que é procedimento do que para o que é convenção permanente.

• Anthropic — Claude Code Docs: How Claude remembers your project. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Extend Claude with skills. Acesso em 19/08/2026.
• Anthropic — Claude Code Docs: Connect Claude Code to tools via MCP. Acesso em 20/08/2026.
• Cursor — Skills. Acesso em 20/08/2026.
• Cursor — Rules. Acesso em 20/08/2026.
• Codex — Documentação oficial. Acesso em 20/08/2026.
• Codex — Agent approvals & security. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: Settings. Acesso em 20/08/2026.
• Anthropic — Claude Code Docs: Configure the sandboxed Bash tool. Acesso em 20/08/2026.
• Agent Skills — Especificação aberta. Acesso em 19/08/2026.

Verificado em 20 de agosto de 2026.

Correção (02/10/2026): a versão original afirmava que a restrição do Claude Code vive "no cliente" e a do Codex "no sistema operacional". Isso estava errado. O Claude Code tem sandbox com enforcement de SO para o Bash, via Seatbelt e bubblewrap. A diferença entre os dois é qual camada vem ligada por padrão, não qual delas existe. Corrigido no texto e na tabela.

Nota de método: esta comparação usa exclusivamente documentação oficial dos três produtos, lida na íntegra nas seções citadas. Não houve teste controlado, medição de velocidade nem execução da mesma tarefa nos três. Onde a documentação de um produto não permite comparação com a dos outros, isso está declarado no texto em vez de preenchido por suposição.

Gatilho de reavaliação: revisar quando qualquer um dos três alterar o modelo de carregamento de contexto, quando a spec Agent Skills aceitar mais campos, ou quando surgir benchmark público com metodologia aberta comparando os três.