Modo Automático do Codex: Como Rodar Sem Intervenção (Testado)

Quer deixar o Codex trabalhar de verdade — editar arquivos, rodar comandos e seguir em frente sem interromper você a cada etapa? Ativar o "Full Access" parece ser a resposta, mas ele ainda pode pedir aprovações. O motivo está nos controles separados do Codex. Abaixo está a solução para rodar sem intervenção, testada no Codex CLI v0.145.0.

O motivo: o "modo automático" não é uma configuração única. O Codex separa o sandbox, que define o que ele pode acessar, da política de aprovação, que determina quando ele para para pedir autorização. O acesso à rede é uma terceira barreira independente. Liberar um desses controles não libera os demais, e uma atualização do Codex pode restaurar silenciosamente a política padrão da sessão.

Para não haver intervenção na CLI: --yolo é a única flag que elimina todas as barreiras de uma vez. Se quiser uma opção mais segura, mantendo o sandbox, configure os dois eixos explicitamente. Faça isso no início da sessão e confira novamente depois de qualquer atualização.

# Totalmente sem intervenção — sem sandbox nem prompts (somente em ambiente descartável):
codex --yolo
# Mais seguro — edita livremente no projeto, mas ainda pede autorização para sair dele:
codex --sandbox workspace-write --ask-for-approval on-request

Para não haver intervenção no app: abra o menu de aprovação, escolha Full access e selecione essa opção novamente após cada atualização — upgrades restauram o modo.

Esse é o resumo rápido. A seguir, veja o mapa completo: todos os modos, como eles funcionam internamente e qual faz sentido em cada caso.

Os três modos do Codex em comparação

O sandbox define o que o agente pode acessar, como arquivos e rede. Já a política de aprovação determina em quais situações ele para para perguntar. O modo automático apenas combina essas duas configurações, embora o app desktop e a CLI deem nomes diferentes às mesmas combinações.

Quem usa a CLI pode configurar isso diretamente com --sandbox e --ask-for-approval, ou alternar entre predefinições durante a sessão pelo seletor /permissions. Se você ainda está escolhendo qual cliente usar, essa é outra discussão; comparamos Codex e Claude Code aqui. Este guia trata especificamente dessas configurações.

Por que o "Full Access" ainda pede aprovação?

Há três motivos, e eles podem ocorrer ao mesmo tempo.

Sandbox e aprovação são controles distintos. A combinação workspace-write + on-request deixa o Codex editar livremente dentro do projeto, mas o interrompe nas fronteiras: uma chamada de rede, um arquivo fora do repositório ou um sudo. Se você ampliar o sandbox e mantiver as aprovações sob demanda, os prompts continuarão aparecendo nessas situações.

A rede tem uma barreira própria. Mesmo o Full Access pode tratar o acesso à internet separadamente do sistema de arquivos. Como observou @mxcl (16 de julho de 2026), o Codex "cannot use the Internet without full access, ending task until the user enables full access." Permissão para escrever arquivos e permissão de rede não são a mesma coisa.

Atualizações restauram o modo. Vários usuários encontraram esse problema no fim de julho de 2026: ao atualizar o Codex, sessões ativas voltavam silenciosamente à política padrão. @s_rafcon (22 de julho) relatou que as threads "switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit." Configure o modo no início da sessão e confira-o após cada atualização.

Na CLI, --full-auto saiu de cena: use isto no lugar

Antes, codex --full-auto era o atalho para "trabalhe no meu projeto sem perguntar" — isto é, approval_policy = "on-request" + sandbox_mode = "workspace-write". O comando interativo não aceita mais essa opção. Teste no v0.145.0:

$ codex --full-auto
error: unexpected argument '--full-auto' found

Agora, defina os dois eixos explicitamente — é exatamente o que a flag antiga fazia:

# Substituto atual para --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# Ou, sem interação e sem prompts, mas mantendo o sandbox:
codex -a never -s workspace-write exec "your task"

codex exec --full-auto ainda aceita a flag em scripts; o erro ocorre apenas no comando interativo. Segundo o codex --help, --ask-for-approval aceita untrusted / on-request / never, enquanto --sandbox aceita read-only / workspace-write / danger-full-access. Todo "modo" do app é uma combinação desses dois parâmetros.

--yolo: quando vale eliminar todas as barreiras

--yolo é o atalho para --dangerously-bypass-approvals-and-sandbox. É o verdadeiro modo sem intervenção: danger-full-access com never, sem limites no sistema de arquivos e sem bloqueios de aprovação. Ele continuou disponível após a remoção de --full-auto justamente porque o nome já deixa o risco evidente: codex --yolo funciona normalmente no v0.145.0, enquanto codex --full-auto retorna erro.

Muitos usuários experientes o usam como padrão e, para a tarefa certa, fazem sentido. A condição é que o próprio ambiente seja a proteção. Trate a máquina como descartável:

• Use uma VM ou um dev container descartável, não sua máquina de trabalho diária.
• Remova antes as credenciais de produção do ambiente.
• Mantenha a tarefa bem delimitada e confira o git diff antes de continuar.

Como --yolo remove todas as barreiras, um rm -rf, git push ou DROP TABLE acidental será executado sem pedir confirmação — esse é o preço da velocidade. Usar um endpoint self-hosted ou compatível com Anthropic por meio de um provedor de modelo personalizado não muda nada nesse ponto: o sandbox não se importa com qual modelo está por trás da API.

"Aprovar por mim" / Auto-review: uma IA decidindo as aprovações

O modo mais novo, e atual padrão do app, é o Auto-review. Escalonamentos elegíveis vão para um agente revisor separado — um Codex menor rodando GPT-5.4 Thinking (low) — que aprova ou nega com uma justificativa. A OpenAI o define como "a reviewer swap, not a permission grant": ele não amplia os diretórios nos quais você pode escrever nem libera a rede; muda apenas quem dá o aval.

Os números vêm da avaliação da própria OpenAI, de 30 de abril de 2026: o Auto-review interrompe para um humano cerca de 200x menos vezes do que a aprovação manual e aprova aproximadamente 99.1% dos escalonamentos que revisa (99.93% considerando todas as ações). Na ilustração com 10,000 ações, 9,280 foram executadas sem alterações dentro do sandbox, 720 chegaram ao revisor e apenas 7 foram negadas.

Há proteções contra uma sequência interminável de negativas: o turno é interrompido após 3 negativas consecutivas ou após 10 negativas em uma janela móvel das últimas 50 revisões. Quando ele parar você, execute /approve para abrir o seletor Auto-review Denials e liberar uma ação para nova tentativa.

O ponto fraco é que essas verificações de segurança podem travar execuções longas. Usuários em tarefas /goal de várias horas relataram, no fim de julho de 2026, que o prompt periódico "keep waiting?" interrompeu fluxos que antes rodavam por dias sem supervisão. A OpenAI também afirma claramente que o recurso "should not be treated as a guarantee of security" — o recall em red team é alto, mas imperfeito (90.3% overreach, 99.3% prompt injection, 96.1% misaligned-model). É um bom padrão, mas não substitui um sandbox em trabalhos de alto risco.

Para ativá-lo pela configuração, em vez da interface:

approvals_reviewer = "auto_review"

[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""

Qual modo você deve usar?

• Desenvolvimento local no dia a dia: workspace-write + on-request ("Pedir aprovação"). Você mantém o poder de veto para tudo que sai do repositório, onde está o risco real de dano.
• Execuções longas sem acompanhamento: "Aprovar por mim" (Auto-review). Ele ainda interrompe a execução nas ações que sinalizar, portanto não é uma experiência totalmente sem toque.
• Trabalho pontual e arriscado em ambiente descartável: --yolo. É a opção mais rápida e perigosa; só é segura quando o ambiente não pode ser prejudicado.
• Leitura ou revisão de uma base de código: read-only. Sem escrita, sem surpresas.

O resumo honesto é: não existe uma configuração que seja ao mesmo tempo totalmente autônoma e totalmente segura. Cada passo em direção ao uso sem intervenção troca seu julgamento por um classificador. Essa troca vale a pena em tarefas rotineiras, mas é uma má ideia em infraestrutura de produção. Escolha o modo para cada tarefa, não uma única vez para sempre.

Perguntas frequentes

Existe um modo automático no Codex?

Sim, mas ele é formado por predefinições, não por um único botão. No app, "Pedir aprovação", "Aprovar por mim" e "Acesso total" são os modos automáticos; na CLI, você monta o mesmo comportamento com --sandbox e --ask-for-approval ou usa /permissions.

Como faço para o Codex aprovar todos os comandos automaticamente?

Defina approval_policy = "never". Com workspace-write, ele deixa de exibir prompts dentro do sandbox; com danger-full-access — ou seja, --yolo — ele para de pedir aprovação por completo. A segunda opção remove todas as proteções, então use-a apenas em ambiente isolado.

O que é o modo Auto-review do Codex?

O Auto-review (approvals_reviewer = "auto_review", exibido como "Aprovar por mim") envia decisões de aprovação para um agente revisor de IA, em vez de enviá-las para você. Ele aprova cerca de 99% do que revisa e interrompe para um humano aproximadamente 200x menos vezes, mas não é uma garantia de segurança.

--full-auto ainda funciona?

Não na CLI interativa. No teste com o v0.145.0, codex --full-auto retorna "unexpected argument." Já codex exec --full-auto ainda aceita a opção como um alias obsoleto para scripts. Para uso interativo, use --sandbox workspace-write --ask-for-approval on-request.

O modo --yolo é seguro?

Não. Esse é justamente o sentido do nome. Ele desativa simultaneamente o sandbox e todas as aprovações. Só é razoável dentro de uma VM ou container descartável, sem credenciais de produção e com uma tarefa bem delimitada.