Claude Code ou Codex: qual agente te dá mais controle antes de mexer no código?

Fala aí, beleza? Agente de IA com terminal aberto no repositório de produção é o tipo de coisa que tira o sono de quem já viu um git reset --hard mandar duas horas de trabalho pro além

O problema que os dois resolvem é o mesmo: onde fica o freio antes da ação

A arquitetura é que muda. O Claude Code organiza tudo em modos de permissão, uma escada do mais travado ao mais solto. O Codex separa em dois eixos independentes: política de aprovação de um lado, modo de sandbox do outro

Então aqui a comparação Claude Code vs Codex é bem específica, nada de vencedor genérico: o que cada agente PERGUNTA antes de agir, e o que ele roda direto sem te consultar

Claude Code x Codex: o que cada um pede antes de agir

Os modos do Claude Code, do mais travado ao mais solto

A documentação de modos de permissão lista os modos disponíveis assim: default, acceptEdits, plan, auto, dontAsk e bypassPermissions

Bora do mais travado pro mais solto

plan: o agente pensa e não toca

O plan é somente leitura

Ele lê arquivos, roda comando pra explorar o projeto e escreve um plano, mas as edições ficam bloqueadas até você aprovar o plano

É o modo de "me conta o que você faria" antes de qualquer linha mudar de lugar

default: pergunta antes de quase tudo

No default (o Manual) o agente para e pergunta antes da maioria das ações que mexem em alguma coisa: editar arquivo, rodar comando de shell ou acessar a rede

Leitura é livre

É o modo mais chato de usar e o mais previsível de auditar, os dois ao mesmo tempo

acceptEdits: edita sozinho, para no arriscado

O acceptEdits aprova automaticamente edições de arquivo e comandos comuns de sistema de arquivos, tipo mkdir, touch, mv e cp

Leitura também segue livre

Mas ele continua parando no que é mais arriscado, então não é carta branca

auto mode: quem revisa não é você

Aqui muda o jogo

No auto mode quem avalia as ações é um segundo modelo, um classificador rodando em Sonnet 4.6, que analisa cada ação antes da execução e bloqueia o que for irreversível, destrutivo ou direcionado pra fora do seu ambiente

Tem ainda uma sonda server-side de prompt injection que varre as saídas de ferramenta antes delas entrarem no contexto

E se liga nisso: desde 14 de agosto o auto mode virou o modo de permissão padrão de novas sessões nos planos Pro, Max e Team. Quem já tinha definido um modo padrão manteve o seu, e padrão gerenciado pela organização não mudou

O que o classificador bloqueia por padrão dá uma boa ideia da régua dele:

• operações de git que descartariam trabalho não commitado: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop e git stash clear
• git commit --amend quando o commit em HEAD não foi criado na sessão ou já foi enviado
• commit ou push que mandaria segredo ou dado sensível pra fora do repositório, incluindo workflow de CI ou config de deploy que entrega segredo a um destino novo, script que lê cofre de segredos e envia dados pra fora, e mudança de config que amplia o que o deploy publica

Ou seja: o freio não é sobre "comando perigoso", é sobre perda irreversível e coisa saindo do seu ambiente

bypassPermissions: pula os prompts, mas não pula tudo

Esse pula os prompts de permissão, inclusive pra escrita em caminhos protegidos como .git e .claude

E ele nem aparece de graça: só depois de iniciar com --permission-mode bypassPermissions, --dangerously-skip-permissions ou --allow-dangerously-skip-permissions

A própria doc recomenda usar isso só em ambiente isolado, container ou VM

Agora, "sem prompt" não é o mesmo que "sem nenhuma trava": regras deny e ask continuam valendo aqui, e um hook PreToolUse que devolve deny bloqueia a ferramenta mesmo nesse modo. Já já a gente detalha essas duas camadas

Mesmo assim, tome cuidado, esse é o modo dos rm -rf da vida 😛

Trocando de modo no meio do caminho

A troca durante a sessão é no Shift+Tab, e o ciclo é definido: a partir do auto, o primeiro toque leva ao default, e depois é default → acceptEdits → plan → default

Dá pra fixar no start também:

claude --permission-mode plan

Ou deixar fixo como padrão nos arquivos de settings:

{ "permissions": { "defaultMode": "acceptEdits" } }

Os dois eixos do Codex: aprovação e sandbox

O Codex não pensa em escada, pensa em duas perguntas separadas

Uma é approval_policy, que aceita untrusted, on-failure, on-request e never

A outra é sandbox_mode, que aceita read-only, workspace-write e danger-full-access

A sacada é essa: "quando ele pergunta" e "onde ele pode escrever" são coisas independentes, e você combina as duas

Os presets prontos

O preset Auto é a combinação --sandbox workspace-write --ask-for-approval on-request

Na prática o Codex lê, edita e roda comando dentro do diretório de trabalho sozinho, e pede aprovação pra editar fora do workspace ou rodar comando que precisa de rede

O Read Only deixa a leitura livre e exige aprovação pra editar, rodar comando e acessar rede

O Full Access corresponde ao sandbox danger-full-access: lê, edita e roda comando com acesso à rede sem aprovação, escrevendo em qualquer lugar

Trocando de preset e planejando antes

A troca é pelo seletor dentro da sessão: digite /permissions e pressione Enter pra escolher o preset

Os modos internos são :read-only, :workspace e :danger-full-access

Tem também o Plan Mode, pra reunir contexto, tirar dúvidas e montar um plano antes de implementar. Alterna com /plan ou Shift+Tab

Onde isso fica salvo

A configuração persistente vive no config.toml, e é lá que entram os dois eixos:

approval_policy = "never"
sandbox_mode = "workspace-write"

Um detalhe que pega muita gente: no workspace-write a rede fica desligada por padrão

Se você precisa dela, tem que habilitar no ~/.codex/config.toml, na seção de configuração do workspace-write, com network_access = true

Pela extensão de IDE dá pra abrir esse arquivo em Codex Settings > Open config.toml

E se você ainda usa --full-auto em script, se liga: ela virou flag de compatibilidade deprecada e imprime aviso. A referência de configuração e a doc de aprovações recomendam a flag explícita, --sandbox workspace-write (ou --sandbox danger-full-access quando você precisa mesmo de acesso amplo)

Quando a revisão deixa de ser humana: auto mode x auto-review

Esse é o ponto mais decisivo pra quem trabalha em código de produção

Nos dois agentes existe hoje a opção de tirar VOCÊ do meio e botar outro modelo pra aprovar

No Claude Code isso é o auto mode: o classificador em Sonnet 4.6 avalia cada ação antes da execução e bloqueia o que for irreversível, destrutivo ou direcionado pra fora do ambiente

No Codex isso é o auto-review. Com approvals_reviewer = "auto_review", um revisor separado decide se a ação roda e devolve uma justificativa. Se negar, o agente principal é instruído a achar um caminho materialmente mais seguro ou parar e perguntar

O que o auto-review olha

Ele avalia exatamente as ações que parariam pra um humano:

• chamadas de shell ou exec que pedem escalonamento de sandbox
• requisições de rede bloqueadas pela política atual
• edições de arquivo fora dos writable roots
• chamadas MCP ou de apps que exigem aprovação

E o que ele NÃO faz

Aqui mora a confusão mais comum: auto-review é troca de revisor, não concessão de permissão

Ele não amplia writable_roots, não habilita acesso à rede e não enfraquece caminhos protegidos

Só muda como o Codex trata ações que já precisavam de aprovação, beleza?

E quando ele nega, a negativa não é tratada como erro comum de sandbox. A justificativa volta pro agente principal com instrução extra: não perseguir o mesmo resultado por contorno, execução indireta ou burla de política, e só seguir com alternativa materialmente mais segura

Se a revisão automática negou algo recente e você discorda, existe o /approve, que serve pra retentar uma ação negada pela revisão automática. Só pra isso

Camadas extras de trava que só existem em um dos dois

Até aqui parece empate técnico. Não é, porque cada um tem camada que o outro não tem

Do lado do Claude Code

As regras de permissão se sobrepõem ao modo

Regras deny e ask valem em TODOS os modos, inclusive bypassPermissions. Já as regras allow não têm efeito ali, porque naquele modo tudo já está aprovado mesmo

Tem outra camada acima disso: um hook PreToolUse que devolve permissionDecision como deny dentro de hookSpecificOutput bloqueia a ferramenta mesmo em bypassPermissions e mesmo com --dangerously-skip-permissions. As decisões aceitas são allow, deny ou ask

É por isso que lá em cima eu disse que nem o modo mais solto fica sem rede de segurança: ela só sai do prompt e vai pra regra e pro hook

Se você quer entender melhor essa camada, dá pra ir fundo em automatizar bloqueios com hooks antes e depois do agente editar

E tem o Bash em sandbox, com isolamento de sistema de arquivos e de rede aplicado pelo sistema operacional: por padrão os comandos em sandbox só escrevem no diretório de trabalho atual e no diretório temporário da sessão, e a rede sai por um proxy que restringe domínios e pede confirmação pra domínio novo

A Anthropic relata que, no uso interno, o sandbox reduziu os prompts de permissão em 84%

O porém: esse sandbox roda em macOS, Linux e WSL2, sem suporte a Windows nativo. No Windows você precisa rodar o Claude Code dentro de uma distro WSL2

Do lado do Codex

O Codex usa mecanismo nativo de cada sistema operacional pra aplicar o sandbox

No macOS são perfis Seatbelt. No Linux e no WSL, bubblewrap e seccomp, com Landlock em caminhos de compatibilidade. No Windows nativo, o sandbox elevado usa usuários de menor privilégio, limites de permissão de arquivo e regras de firewall, e o não elevado é um fallback com isolamento de rede mais fraco

E o comportamento quando não dá pra aplicar a política é o melhor detalhe: ele recusa rodar, em vez de rodar sem sandbox

Tem ainda um recurso que não tem equivalente do outro lado: marcar um PROJETO como não confiável

Cuidado pra não confundir: aqui untrusted não é o valor de approval_policy que a gente viu lá em cima, é uma marcação de confiança do projeto. Projeto marcado assim pula as camadas .codex/ daquele projeto, incluindo config local, hooks e rules

Isso é ULTRA útil quando você clona repositório de terceiro e não quer que a config dele mande no seu agente

Veredito: qual escolher para código de produção

Não tem vencedor absoluto aqui, tem perfil

Se você quer trava que nenhum modo derruba, o Claude Code leva. Regras deny e ask valem acima do modo escolhido, e o hook PreToolUse com deny bloqueia até nos modos que pulam prompt. É o desenho mais próximo de "essa linha ninguém cruza, nem eu no cansaço das 23h"

Se você quer separar "onde pode escrever" de "quando pergunta", o Codex encaixa melhor. Os dois eixos independentes deixam montar combinações que a escada de modos não expressa, tipo sandbox apertado com aprovação frouxa, ou o contrário

Se você está no Windows nativo, o Codex tem sandbox lá, com mecanismo próprio, enquanto no Claude Code o sandbox exige WSL2. Isso sozinho já decide muita coisa em time que roda Windows

E tem o ponto de atenção comum aos dois: delegar a revisão a um modelo muda QUEM aprova, não o que pode acontecer se a aprovação falhar

No Claude Code isso já é o padrão de novas sessões em Pro, Max e Team, então vale saber em que modo você está antes de sair rodando

Se o repositório nem é seu, a conversa fica mais delicada ainda, e aí vale alinhar antes de usar o agente em projeto de cliente

Conclusão

O próximo passo é bem concreto e leva dois minutos

Antes de abrir o repositório de produção, confira em qual modo sua sessão está: no Claude Code o Shift+Tab te mostra o ciclo, no Codex o /permissions abre o seletor

Depois fixa o que você quer de verdade: defaultMode nos settings do Claude Code, ou approval_policy e sandbox_mode no config.toml do Codex

E se você quer trava que sobrevive a qualquer modo, incluindo os que pulam prompt, é regra deny no Claude Code

Roda os dois no mesmo projeto por uma semana e compara o que cada um te perguntou. É o único teste que vale, porque a resposta depende do seu repositório e do seu nível de paranoia 😀

até o próximo post!