OpenAI mostrou como construiu um sandbox seguro do Codex para Windows

OpenAI revelou como criou uma sandbox completa para o Codex no Windows, permitindo que um agente execute comandos localmente sem acesso total ao sistema. O objetivo era simples: preservar a conveniência da codificação autônoma enquanto impede o modelo de escrever livremente em qualquer lugar e acessar a internet sem permissão explícita do usuário.

Por Que Não Funcionou

Inicialmente, os usuários do Windows tinham duas opções ruins. Ou confirmar quase cada comando, incluindo leituras simples de arquivos, ou ativar o Full Access e essencialmente confiar ao agente o mesmo nível de permissão do desenvolvedor. Para o Codex, isso é particularmente sensível: o agente funciona através de CLI, IDE e aplicativos desktop, pode executar testes, editar código, criar branches Git e invocar ferramentas de desenvolvimento regulares.

OpenAI verificou inicialmente os mecanismos padrão de isolamento do Windows, mas nenhum se adequava sem sérios compromissos. AppContainer fornece um limite de segurança forte, mas é projetado para aplicações pré-definidas em vez de um conjunto aberto de cenários com Git, Python, gerenciadores de pacotes e binários de terceiros. Windows Sandbox se mostrou um mundo muito "separado": Codex precisa trabalhar com o checkout real do usuário, não com uma máquina virtual descartável, além disso esse modo não está disponível no Windows Home. O mecanismo de níveis de integridade também parecia bom apenas no papel porque alterava o modelo de confiança para o sistema de arquivos real do host.

Primeiro Esquema de Proteção

O primeiro protótipo funcional da OpenAI foi construído sem requisitos de direitos de administrador. Usava um SID sintético e um token com restrição de escrita—um token especial que permite escrever dados apenas onde as permissões de usuário regular e uma permissão de sandbox separada coincidem simultaneamente. Isso permitia ao Codex ler quase em qualquer lugar, mas escrever apenas em raízes de projeto estritamente definidas.

• um SID separado `sandbox-write` foi criado
• esse SID recebeu permissões de escrita, execução e exclusão no diretório de trabalho atual e em `writable_roots`
• dentro desses diretórios, escrita em `.git`, `.codex` e `.agents` podia ser separadamente proibida
• cada comando executava com um token restrito que levava em conta `Everyone`, o SID da sessão atual e `sandbox-write`

A abordagem funcionou razoavelmente bem para arquivos, mas a rede permaneceu um ponto fraco. O time tentou "quebrar" caminhos de rede típicos através de variáveis de ambiente como `HTTPS_PROXY`, `ALL_PROXY` e `GIT_SSH_COMMAND`, bem como através de substituição de binários stub para `ssh` e `scp`. Para comandos Git regulares e instaladores de pacotes, isso frequentemente era suficiente, mas a proteção era mais uma recomendação: qualquer processo podia ignorar variáveis de ambiente, contornar PATH ou abrir um socket diretamente.

Como o Lançamento Funciona

Devido a limitações de rede, OpenAI abandonou a ideia de uma sandbox completamente sem privilégios de admin e passou para o esquema atual, mais rigoroso. Agora durante a configuração, Codex cria dois usuários locais: `CodexSandboxOffline` para processos sem acesso à rede e `CodexSandboxOnline` para cenários onde acesso é necessário. Comandos ainda executam com um token restrito, mas não mais sob o nome do usuário real—em vez disso sob um usuário sandbox especial ao qual regras do Windows Firewall podem ser aplicadas. Isso exigiu um processo de setup separado.

Ele cria um SID sintético, configura contas sandbox, criptografa suas credenciais através de DPAPI e configura regras de firewall que bloqueiam tráfego de saída para o usuário offline. Em paralelo, o sistema concede aos usuários sandbox permissões de leitura em diretórios típicos como `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` e `C:\ProgramData`—caso contrário o agente não conseguiria nem mesmo ler corretamente arquivos de usuário e ferramentas. Parte da configuração de ACL é executada de forma assíncrona para evitar atrasar a instalação inicial.

Um problema separado surgiu no limite de inicialização de processos. Descobriu-se que `codex.exe` não consegue completar confiavelmente o caminho inteiro de fazer login como um usuário sandbox até `CreateProcessAsUserW(...)` do contexto do usuário real. Portanto, OpenAI moveu a execução de comandos para um binário separado, `codex-command-runner.exe`: primeiro `codex.exe` o inicia como um usuário sandbox, e o runner dentro de sua própria sessão cria um token restrito e inicia o processo filho final.

Na arquitetura final, quatro camadas estão envolvidas: o próprio `codex.exe`, um binário de setup elevado, o command runner e o processo alvo.

O Que Isso Significa

Para desenvolvedores Windows, isso é uma mudança importante: agentes de codificação locais se tornam não apenas mais convenientes, mas também mais previsíveis do ponto de vista de segurança. OpenAI essencialmente mostrou que para codificação baseada em agentes no Windows, não há uma única "API mágica", e o problema deve ser resolvido através de uma combinação de ACL, tokens, usuários separados, regras de firewall e binários adicionais. Isso aumenta a complexidade de implementação, mas aproxima o modelo operacional do Codex dos requisitos reais de times que querem automatizar trabalho rotineiro sem abandonar completamente o controle.