Meu primeiro problema logo depois da instalação não foi um pedido de aprovação. Foi que o npm install não funcionava no Codex CLI.
Os arquivos eram editados normalmente, mas a instalação de dependências ficava parada. Por um bom tempo, achei que era problema do próprio npm.
Vou direto à conclusão. Não convém forçar com sudo.
Além disso, aprovação e sandbox são dois eixos completamente diferentes. Sem separar os dois, a confusão se repete: “Eu permiti, por que não roda?”
Por que o npm install não funciona no Codex CLI com workspace-write?
O modo workspace-write permite escrever arquivos, mas o acesso à rede é uma configuração separada. Por isso, um comando que precisa de rede, como o npm install, pode ser bloqueado mesmo com as edições funcionando.
No começo, achei que o npm estava estranho. Afinal, os arquivos de código continuavam sendo editados sem problema.
Com a instalação concluída, coloquei o Codex para fazer trabalho real. As mudanças de código passavam bem.
Só a etapa de instalar dependências travava, várias vezes.
Por um tempo, desconfiei da configuração do npm. A causa real era a condição de acesso à rede do sandbox.
Desde então, trato “pode escrever arquivos?” e “pode usar a rede?” como duas permissões totalmente separadas.
Segundo a documentação oficial, o workspace-write trata a escrita no sistema de arquivos e o acesso à rede como limites diferentes (Documentação da OpenAI: Sandbox).
Mas não consegui confirmar na documentação o nome exato da chave de configuração. Por isso, aqui só digo que o acesso à rede é controlado por uma configuração separada.
Vale usar sudo quando o npm install -g dá EACCES?
No meu caso, não: com sudo o pacote instala na hora, mas depois as permissões ficam mais emaranhadas. O que resolveu foi organizar o caminho de instalação do Node e reinstalar num ambiente Node do usuário.
Esse EACCES foi um problema separado, do começo da instalação.
Na mesma máquina conviviam o Node do sistema e um gerenciador de versões do Node que eu tinha instalado à parte. Ao instalar um pacote global do npm, apareceu um problema de permissão.
Minha primeira reação foi sudo npm install -g .... Parei ali, porque já tinha passado por isso antes.
Depois de organizar o caminho do Node e reinstalar, o problema sumiu.
O que tirei dessa tentativa e erro: aparecer EACCES não quer dizer que se deva partir para o sudo sem pensar.
Aprovação vs sandbox no Codex CLI: o que muda de fato?
A opção approval_policy decide quando perguntar a uma pessoa, e a sandbox_mode decide até onde o agente pode executar sem perguntar. São dois eixos independentes, então uma aprovação permissiva não libera o sandbox.
No começo, eu não tinha essa distinção clara.
Por que entendi never como “liberar tudo”
Quando vi approval_policy = "never", meu primeiro pensamento foi simples: “Agora tudo vai ser permitido automaticamente.”
Não foi assim. Mesmo com never, as ações fora do sandbox continuaram restritas.
Segundo a documentação oficial, --ask-for-approval never foi projetado para funcionar com todos os modos de --sandbox.
A documentação também diz que as restrições do sandbox continuam valendo, seja qual for a aprovação (Documentação da OpenAI: Agent approvals & security).
O que observar em setembro de 2026
O que conto aqui foi verificado em setembro de 2026. Os nomes de flags e os valores de configuração do Codex CLI vêm mudando de uma versão para outra.
Opções copiadas de um tutorial antigo podem não bater com a versão mais recente.
Por exemplo, o valor approval_policy = "untrusted" foi removido por um PR mesclado em agosto de 2026. A partir da 0.149.0, se o arquivo de configuração ainda tiver esse valor, o Codex nem inicia e dá erro (openai/codex PR #39630).
Hoje, a documentação oficial lista três valores de approval_policy: on-request, never e granular, de controle detalhado. Não consegui confirmar o valor “unless-trusted”, citado com frequência.
Por isso, sempre que mexo de novo no config.toml, acho mais seguro reabrir a ajuda da CLI e a referência oficial de configuração.
Quanto tempo as aprovações custam com workspace-write e danger-full-access?
Repeti a mesma refatoração 5 vezes: workspace-write + on-request levou 14–16 minutos, e danger-full-access em ambiente isolado, 11–13 minutos. É uma medição pessoal, não um número geral.
Rodei tudo num repositório pessoal/POC, num macOS com Apple Silicon. Mudei só duas condições.
| Condição | Tempo (média, faixa em 5 execuções) | Aprovações |
|---|---|---|
| workspace-write + on-request | 14–16 min | 2–4 |
| danger-full-access (ambiente isolado) | 11–13 min | Nenhuma (sem pedido de aprovação) |
De onde vieram as 2–4 aprovações?
Com workspace-write + on-request, cada execução teve em geral umas 2–4 intervenções de permissão. As edições de arquivos dentro do workspace e os testes normais seguiam quase sem pausa.
Na maioria das vezes, as pausas vinham em momentos parecidos: quando algo precisava de acesso à rede ou de um arquivo fora do workspace.
14–16 min contra 11–13 min, e por que não generalizo
Com danger-full-access num ambiente isolado, o tempo parado por aprovações quase desaparece (veja a tabela).
Não vou transformar isso em “danger-full-access é 20% mais rápido” como número geral. A diferença real dependia muito de quanto acesso fora do sandbox a tarefa exigia.
Também não medi com timestamps precisos. São cinco repetições pessoais, nada mais.
Em quais ambientes eu uso danger-full-access?
Meu critério é usar só em ambientes que dá para descartar inteiros, como Docker, uma VM descartável ou um worktree separado. O modo read-only, o mais conservador, nem permite escrita, então fica fora desta comparação.
Segundo a documentação oficial, o danger-full-access é um modo que remove por completo os limites do sistema de arquivos e da rede (Documentação da OpenAI: Sandbox).
Na documentação, a flag --dangerously-bypass-approvals-and-sandbox (alias --yolo) não aparece como “EXTREMELY DANGEROUS”. O rótulo é [Elevated Risk] No sandbox; no approvals (not recommended), com um aviso para usar com cuidado (Documentação da OpenAI: Agent approvals & security).
As flags --sandbox/-s e --profile aparecem na documentação. Para --worktree e --approve-for-me, não achei respaldo no que verifiquei desta vez, então não trato delas aqui.
Repositório pessoal, POC da empresa e experimentos de automação
Na prática, separo três ambientes. No repositório pessoal, uso workspace-write + on-request no host macOS.
Na POC da empresa, fico principalmente em workspace-write, num repositório de desenvolvimento. O acesso a credenciais e à produção fica totalmente separado, em outras ferramentas e ambientes.
Só experimentos de automação de baixo risco ganham permissões mais amplas, em Docker ou num worktree descartável.
Meu padrão é sempre workspace-write.
O critério não é velocidade. A pergunta é: “Se este agente executar algo errado, tudo bem o efeito chegar fora do workspace?”
Na maioria dos casos, a resposta é não. Nos meus repositórios de desenvolvimento do dia a dia no host, não deixo uma opção de bypass como padrão só por ser cômodo.
Poucos perfis, de propósito
Não crio perfis demais. Deixo a configuração padrão conservadora e, além dela, mantenho mais ou menos um perfil separado: o de ambientes isolados.
Codex CLI vs Antigravity CLI: qual pediu menos aprovações?
Na minha comparação pessoal, o Codex com workspace-write + on-request pareceu pedir menos intervenções que o Antigravity CLI (pode variar com a ferramenta e o momento). Na mesma tarefa, o Antigravity levou cerca de 18 minutos no modo de aprovação e cerca de 12 no modo automático.
| Ferramenta / modo | Tempo | Aprovações | Bloqueios |
|---|---|---|---|
| Antigravity CLI, modo de aprovação | ~18 min | 6–7 | 4 |
| Antigravity CLI, modo automático | ~12 min | – | – |
| Codex workspace-write + on-request | 14–16 min | 2–4 | – |
Comparado com meus testes do Antigravity, no Codex tive relativamente menos a sensação de aprovar um por um até os comandos normais do workspace.
Para o uso diário de um agente de programação, essa combinação foi mais cômoda.
Nos dois casos, julguei pelo mesmo critério: o blast radius (até onde o estrago chega) e a reversibilidade.
Uma coisa não mudou. Sem distinguir sandbox e aprovação, a confusão é a mesma em qualquer ferramenta.
Qual combinação do Codex equivale exatamente ao --dangerously-skip-permissions do Claude Code é algo que não trato a fundo neste post.
Para mim, o sandbox não é algo que ligo por desconfiar do agente
Por melhores que os modelos fiquem, sobram caminhos de falha que não dependem do raciocínio deles. Por exemplo: comandos de shell, scripts de pacote, um caminho errado ou uma limpeza de teste inesperada.
Meu padrão é confinar o blast radius de um erro dentro do workspace, não poupar alguns cliques de aprovação.
Referências
- Documentação da OpenAI: Sandbox: como os modos do sandbox separam os limites do sistema de arquivos e da rede, e como o danger-full-access os remove
- Documentação da OpenAI: Agent approvals & security: independência entre approval_policy e sandbox_mode, rótulo de aviso da flag de bypass e flags da CLI
- openai/codex PR #39630: Retire the untrusted approval policy: remoção de
approval_policy = "untrusted"e erro de inicialização a partir da 0.149.0
Este artigo foi localizado a partir do original em coreano: https://jjeongil.tistory.com/3566.