Como Contornar o Sandbox Codex

O Codex — o LLM de codificação da OpenAI — é construído com múltiplas camadas de sandboxing e aprovação por padrão, aplicando fortes salvaguardas para uma execução segura. Mas, às vezes, os desenvolvedores podem querer executar o Codex com menos restrições para fluxos de trabalho confiáveis. Este artigo explica o que é o sandbox do Codex, por que ele existe e como você pode usar o sinalizador --dangerously-bypass-approvals-and-sandbox para desativá-lo.

Aviso: Ignorar o sandbox do Codex pode comprometer medidas de segurança críticas destinadas a proteger seu sistema e código-base. O seguinte é puramente para fins educacionais — prossiga por sua conta e risco e apenas em ambientes controlados.

Instalando o Codex CLI ou Executando-o no Docker Antes de Ignorar o Sandbox do Codex

Antes de tentar ignorar o sandbox do Codex, você deve instalar o Codex CLI ou executá-lo em um ambiente controlado como o Docker:

Instalar o Codex CLI:

# Install via NPM
npm install -g @openai/codex

# Install via Homebrew
brew install --cask codex

Em seguida, basta executar codex em seu terminal para começar com o Codex CLI.

Autenticar o Codex CLI:
Exporte sua chave de API:export OPENAI_API_KEY="" no Windows use o comando set em vez de export.

Ou execute o Codex no Docker
Se você preferir isolamento de contêiner (recomendado ao ignorar o sandbox):

docker run --rm -it -v "$(pwd):/workspace" -w /workspace ghcr.io/openai/codex:latest \ codex --sandbox danger-full-access --ask-for-approval never

Isso dá ao Codex acesso total dentro do contêiner, enquanto o isola do seu sistema host.

O Que É o Sandbox do Codex?

O sandbox do Codex é um mecanismo de segurança que limita o que o Codex pode fazer em sua máquina. De acordo com o guia de segurança do OpenAI Codex:

• Quando você executa o Codex localmente (CLI ou IDE), ele usa sandboxing em nível de SO (por exemplo, Seatbelt no macOS, seccomp / Landlock no Linux). (mais sobre isso em OpenAI Developers)
• Por padrão, o acesso à rede é desativado, e as permissões de escrita são restritas ao seu espaço de trabalho atual.
• Para comandos fora do seu espaço de trabalho, o Codex solicitará sua aprovação.
• Como ilustrado em Documentação da Ferramenta Online, o modo de aprovação padrão é frequentemente Automático, o que significa que o Codex pode escrever em seu espaço de trabalho, mas precisa de aprovação para operações arriscadas.

Essas medidas de sandboxing visam proteger os usuários de ações não intencionais: execução de código malicioso, vazamento de dados ou alterações prejudiciais ao sistema.

Por Que o Sandbox do Codex Existe

Aqui estão as principais razões pelas quais o Codex é sandboxed por padrão:

1. Segurança: Impede que o Codex escreva arbitrariamente em sua máquina fora do espaço de trabalho.
2. Segurança de Rede: Desabilita o acesso à rede, a menos que explicitamente permitido, reduzindo o risco de exfiltração de dados ou chamadas de API inseguras.
3. Execução Controlada: Como mostrado em Fossies, o Codex requer aprovação do usuário para ações que podem ser perigosas (executar comandos, modificar arquivos do sistema).
4. Isolamento: Garante que o Codex seja executado em um ambiente controlado, minimizando o dano potencial de prompts com bugs ou maliciosos.

Quando Você Pode Querer Ignorar o Sandbox do Codex

Existem cenários legítimos para desabilitar o sandbox, especialmente em ambientes confiáveis:

1. Você executa o Codex dentro de um contêiner Docker ou VM isolada onde o risco já é gerenciado.
2. Você precisa que o Codex execute comandos de shell, instale dependências ou automatize tarefas completamente sem aprovação repetida do usuário.
3. Você está usando o Codex em um pipeline de CI/CD confiável e quer conceder-lhe permissões mais altas.
4. Você entende os riscos e quer experimentar ou prototipar recursos que exigem acesso total ao sistema de arquivos ou à rede.

Como Ignorar o Sandbox do Codex — Com Configurações e Comandos

Veja como configurar e executar o Codex sem restrições de sandbox, usando flags CLI e config.toml:

Ignorando via Comando CLI

Execute o seguinte comando para ignorar completamente o sandboxing e os prompts de aprovação:

codex --dangerously-bypass-approvals-and-sandbox

Isso é equivalente ao modo de acesso total: sem sandbox, sem confirmações. Use apenas em ambientes controlados.

Ignorando via ~/.codex/config.toml

Você pode definir a configuração persistente em seu config.toml para pular o sandboxing:

# ~/.codex/config.toml

model = "gpt-5-codex"
approval_policy = "never"
sandbox_mode = "danger-full-access"

[sandbox_workspace_write]
network_access = true

# (Optional) define additional writable roots
writable_roots = ["/workspace", "/tmp"]

approval_policy = "never" desativa quaisquer prompts de aprovação.

sandbox_mode = "danger-full-access" remove o isolamento do sandbox.

[sandbox_workspace_write].network_access = true permite que o Codex faça chamadas de rede quando estiver no modo de escrita de espaço de trabalho.

Com essa configuração (assumindo que você está ciente desses riscos), o Codex será executado sem pedir sua confirmação e com privilégios completos de sistema de arquivos e rede (mais sobre isso em OpenAI Developers).

Testando o Comportamento do Sandbox

Você pode testar como o Codex se comporta sob diferentes configurações de sandbox usando seus comandos de depuração:

# On macOS:codex
sandbox macos --full-auto ls / 

# On Linux:codex
sandbox linux --full-auto ls /

Esses comandos executam comandos arbitrários de shell sob a política de sandbox imposta pelo Codex, ajudando você a observar o que é e o que não é permitido.

Riscos de Ignorar o Sandbox do Codex

Com o bypass ativado, o Codex pode:

• Executar qualquer comando de shell, incluindo os arriscados ou destrutivos (excluir arquivos, modificar a configuração do sistema)
• Ler e escrever em qualquer lugar no disco
• Potencialmente fazer chamadas de rede, dependendo da configuração

Use o bypass apenas quando:

• Você estiver executando o Codex em uma VM ou contêiner Docker seguro e isolado
• Você confia nos prompts e está confortável com acesso total
• Você estiver automatizando fluxos de trabalho confiáveis (por exemplo, CI), não permitindo que prompts de LLM não verificados sejam executados arbitrariamente

Vulnerabilidades Conhecidas e Histórico de Bugs do Sandbox do Codex

Vale a pena notar que houve uma vulnerabilidade de bypass de sandbox devido a um bug na lógica de configuração de caminho do Codex (conforme declarado em GitHub e GitLab Advisory Database). Certas versões do Codex CLI tratavam um diretório de trabalho gerado pelo modelo como gravável, mesmo que devesse estar isolado.

• Isso permitia escritas fora do limite do sandbox pretendido.
• O problema foi corrigido no Codex CLI v0.39.0.
• Se você está pensando em ignorar o sandbox, certifique-se de que sua versão esteja atualizada para evitar a exploração por meio de falhas de segurança conhecidas.

Perguntas Frequentes

P1. É recomendado ignorar o sandbox do Codex para uso geral?
Não — é recomendado apenas em um ambiente controlado e confiável. Ignorar remove as redes de segurança.

P2. Ignorar o sandbox desabilita todos os prompts de segurança?
Sim. A flag --dangerously-bypass-approvals-and-sandbox desabilita tanto as restrições do sandbox quanto os prompts de aprovação.

P3. Posso executar com segurança o modo de bypass dentro do Docker?
É mais seguro — o Docker oferece isolamento. Se seu contêiner estiver bem configurado, ignorar o sandbox pode ser aceitável para cargas de trabalho confiáveis.

P4. E se eu estiver usando uma versão antiga do Codex CLI?
Versões mais antigas (≤ 0.38.0) podem ter bugs de sandbox, incluindo vulnerabilidades de escape de caminho. Atualize para a versão mais recente antes de usar o modo de bypass.

P5. Como faço para voltar ao modo sandbox?
Basta executar o Codex sem a flag perigosa, ou definir explicitamente o modo sandbox via:

codex --sandbox workspace-write --ask-for-approval on-request

Conclusão

A flag --dangerously-bypass-approvals-and-sandbox dá ao Codex a máxima liberdade — mas essa liberdade vem com sérios riscos. O sandbox do Codex existe para proteger seu sistema, dados e fluxo de trabalho de comportamentos não intencionais ou maliciosos. Ignore-o apenas se você entender completamente as implicações, estiver executando em um ambiente confiável ou precisar de acesso irrestrito para automação.

Se você estiver trabalhando em um contexto compartilhado, de produção ou sensível, é quase sempre mais seguro manter o sandbox e os prompts de aprovação. Mas para experimentos controlados, pipelines de CI ou contêineres confiáveis, ignorar pode desbloquear casos de uso poderosos — apenas não o faça levianamente.