OpenAI mostra como construiu o sandbox seguro do Codex para Windows

A OpenAI explicou como criou um sandbox completo para o Codex no Windows, permitindo que o agente execute comandos localmente sem acesso total ao sistema. A meta era simples: manter a praticidade da programação autônoma, mas impedir que o modelo grave arquivos onde quiser ou acesse a internet sem permissão explícita do usuário.

Por que não funcionou

No início, quem usava Windows tinha duas opções ruins. Ou aprovava quase todos os comandos, inclusive a simples leitura de arquivos, ou ativava o Full Access e, na prática, dava ao agente o mesmo nível de permissões do próprio desenvolvedor. No caso do Codex, isso é especialmente delicado: o agente funciona via CLI, IDE e aplicativo desktop, pode rodar testes, editar código, criar branches no Git e chamar as ferramentas de desenvolvimento de sempre.

A OpenAI testou primeiro os mecanismos de isolamento nativos do Windows, mas nenhum atendeu sem concessões sérias. O AppContainer oferece uma fronteira de segurança robusta, mas foi pensado para aplicativos descritos de antemão, e não para um conjunto aberto de cenários com Git, Python, gerenciadores de pacotes e binários de terceiros. O Windows Sandbox se mostrou um mundo "isolado" demais: o Codex precisa trabalhar no checkout real do usuário, não em 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 só parecia bom no papel, porque alterava o modelo de confiança do sistema de arquivos real do host.

O primeiro esquema de proteção

O primeiro protótipo funcional foi montado sem exigir privilégios de administrador. Ele usava um SID sintético e um write-restricted token — um token especial que só permite gravar dados onde as permissões normais do usuário coincidem com uma permissão específica para o sandbox. Assim, o Codex conseguia ler quase tudo, mas só gravava em raízes de projeto bem definidas.

• era criado um SID dedicado, `sandbox-write`
• esse SID recebia permissões de escrita, execução e exclusão no diretório de trabalho atual e em `writable_roots`
• dentro desses diretórios, era possível bloquear separadamente a escrita em `.git`, `.codex` e `.agents`
• cada comando rodava com um token restrito que considerava `Everyone`, o SID da sessão atual e `sandbox-write`

Com arquivos, a abordagem funcionou bem, mas a rede continuou sendo o ponto fraco. A equipe tentou "quebrar" os caminhos de rede mais comuns com variáveis de ambiente como `HTTPS_PROXY`, `ALL_PROXY` e `GIT_SSH_COMMAND`, além de substituir `ssh` e `scp` por binários stub. Para comandos Git comuns e instaladores de pacotes, isso muitas vezes bastava, mas a proteção era mais uma recomendação: qualquer processo podia ignorar as variáveis de ambiente, contornar o PATH ou abrir um socket diretamente.

Como funciona a versão lançada

Por causa das limitações de rede, a OpenAI abandonou a ideia de um sandbox totalmente sem privilégios de administrador e adotou o esquema atual, mais rígido. Agora, durante a configuração, o Codex cria dois usuários locais: `CodexSandboxOffline`, para processos sem rede, e `CodexSandboxOnline`, para cenários que precisam de acesso. Os comandos continuam rodando com token restrito, mas não mais em nome do usuário real, e sim de um usuário de sandbox específico, ao qual é possível aplicar regras do Windows Firewall.

Isso exigiu um processo de setup separado. Ele cria o SID sintético, registra as contas de sandbox, criptografa as credenciais via DPAPI e define regras de firewall que bloqueiam o tráfego de saída do usuário offline. Ao mesmo tempo, o sistema concede aos usuários de sandbox permissão de leitura em diretórios comuns como `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` e `C:\ProgramData`; sem isso, o agente não conseguiria nem ler direito os arquivos e ferramentas do usuário. Parte da configuração de ACL roda de forma assíncrona para não atrasar a instalação inicial.

Outro problema surgiu na etapa de inicialização de processos. A equipe descobriu que o `codex.exe` não consegue percorrer de forma confiável todo o caminho, do login como usuário de sandbox até `CreateProcessAsUserW(...)`, a partir do contexto do usuário real. Por isso, a OpenAI transferiu a execução de comandos para um binário separado, o `codex-command-runner.exe`: primeiro, o `codex.exe` o inicia como usuário de sandbox; depois, o runner cria o restricted token dentro da própria sessão e dispara o processo filho final. A arquitetura final tem quatro camadas: o próprio `codex.exe`, o binário de setup elevado, o command runner e o processo-alvo.

O que isso significa

Para desenvolvedores Windows, é uma mudança importante: agentes de programação locais ficam não só mais práticos, mas também mais previsíveis do ponto de vista de segurança. Na prática, a OpenAI mostrou que não existe uma API "mágica" única para programação com agentes no Windows, e que o problema exige uma combinação de ACLs, tokens, usuários dedicados, regras de firewall e binários adicionais. Isso aumenta a complexidade da implementação, mas aproxima o modelo de funcionamento do Codex das necessidades reais de equipes que querem automatizar tarefas repetitivas sem abrir mão totalmente do controle.