Como a OpenAI criou um sandbox do Codex no Windows sem um recurso nativo do sistema

A lacuna que começou com um recurso ausente no sistema

Quando David Wiesen entrou para o time de engenharia do Codex em setembro de 2025, o agente de codificação simplesmente não tinha sandbox no Windows. Isso deixava os usuários de Windows com duas opções ruins: aprovar quase todo comando que o agente quisesse executar, incluindo leituras, ou ativar o modo Full Access e deixar o Codex rodar qualquer coisa sem supervisão.

O motivo era simples, mas decisivo. O modo padrão do Codex — ler quase tudo, escrever só dentro do workspace, sem acesso à internet a menos que solicitado — depende do sistema operacional para impor esses limites. O macOS tem o Seatbelt; o Linux tem seccomp e bubblewrap. O Windows não vem com nada equivalente de fábrica.

Então o trabalho do time não era configurar um sandbox existente, mas construir um do zero a partir de peças do Windows que não foram feitas para isso. Essa é a razão pela qual o sistema final acabou tão elaborado.

Três opções nativas do Windows, três becos sem saída

O time avaliou AppContainer, Windows Sandbox e a rotulagem do Mandatory Integrity Control, e rejeitou as três por motivos concretos e bem diferentes entre si.

O AppContainer oferece uma barreira real do sistema, mas foi feito para apps que declaram suas capacidades de antemão — o formato errado para um agente que comanda shells, Git, Python, gerenciadores de pacotes e qualquer binário que decida precisar. O Windows Sandbox é uma caixa mais robusta, uma VM descartável, mas o Codex precisa atuar sobre o checkout e as ferramentas reais do usuário, não em uma área de trabalho descartável; além disso, não está disponível nas versões Home do Windows, o que já elimina a opção na prática.

A rotulagem de integridade do MIC parecia elegante — rodar o Codex com integridade baixa e rotular as raízes graváveis assim — mas marcar um workspace como de baixa integridade significa que qualquer processo de baixa integridade na máquina pode escrever ali, transformando o checkout real do desenvolvedor em um ponto de escrita aberto para todo o sistema. A mudança de comportamento era grande demais para valer a pena.

O prototipo sem privilégios elevados e a única coisa que ele não conseguia fazer

O primeiro design funcional evitava pedir privilégios de administrador ao usuário. Ele se apoiava em dois recursos do Windows: identificadores de segurança sintéticos (SIDs) e tokens com restrição de escrita. Um SID sintético chamado sandbox-write recebia permissão de escrita, execução e exclusão no diretório de trabalho e em qualquer writable_roots configurado, e tinha escrita explicitamente negada em caminhos sensíveis como .git, .codex e .agents. Os comandos rodavam sob um token com restrição de escrita cuja lista de SIDs restritos incluía Everyone, o SID da sessão e sandbox-write.

A parte de escrita de arquivos foi resolvida com elegância. O acesso à rede, não. Sem privilégios de administrador, o Windows Firewall estava fora de cogitação, então o time só conseguia definir sobrescritas de variáveis de ambiente — apontando proxies para um endpoint morto (HTTPS_PROXY=http://127.0.0.1:9), forçando o GIT_SSH_COMMAND a sair com código 1, e colocando um diretório denybin no início do PATH.

O autor é direto sobre o limite dessa abordagem.

Isso bloqueava boa parte do tráfego comum gerado por ferramentas, mas ainda era só uma sugestão, não uma imposição. Um processo podia ignorar as variáveis de ambiente, contornar o PATH, ou simplesmente abrir sockets diretamente — risco demais.Montana Labs

O ponto crucial é que até binários bem-comportados que implementam sua própria pilha de rede passariam por essa barreira sem problema. Foi essa fragilidade específica — e não o custo de configurar as ACLs nem a dificuldade de mudar semânticas — que levou o time a abandonar a restrição de não usar privilégios elevados.

Por que a imposição real de rede exigiu quatro binários e dois usuários falsos

O Windows Firewall conseguia bloquear tráfego de saída, mas só se os processos em sandbox rodassem como um principal distinto. Regras de firewall não conseguem identificar o SID sintético de um token restrito, não conseguem diferenciar uma invocação em sandbox do python.exe de qualquer outra, e bloquear uma porta como a 443 seria a política errada de qualquer forma — o objetivo era bloquear o acesso arbitrário de saída de uma árvore de processos específica.

A solução foi criar dois usuários locais, CodexSandboxOffline (alvo das regras de firewall) e CodexSandboxOnline (fora do alcance delas), com credenciais armazenadas e criptografadas via DPAPI de forma que os usuários do sandbox não conseguem lê-las. Como esses usuários não são o usuário real do Windows, eles perderam acesso de leitura a diretórios normalmente compartilhados com Authenticated Users, então a etapa de configuração também concede ACLs de leitura em caminhos como o perfil do usuário, C:\Windows e Program Files — executado de forma assíncrona por ser lento.

Iniciar comandos como outro usuário bateu numa barreira de privilégios no CreateProcessAsUserW, que não conseguia lançar de forma confiável um processo filho com token restrito a partir do lado do usuário real da fronteira. A solução foi criar o codex-command-runner.exe: o codex.exe inicia o runner como o usuário sandbox via CreateProcessWithLogonW, e o runner — já do lado do usuário sandbox — gera o token restrito e lança o processo filho real. Junto com um binário de configuração elevado dedicado, isso resulta em quatro camadas: codex.exe, o binário de configuração, o command runner e o processo filho.

A implicação: a paridade de plataforma do Codex veio com o custo de uma etapa de configuração como administrador

O resultado principal é bem específico e limitado: para fazer o Codex se comportar da mesma forma no Windows que no macOS e no Linux, a OpenAI teve que exigir permissões elevadas de administrador na etapa de configuração — exatamente a restrição que o time tentou evitar no primeiro prototipo. O bloqueio de rede que resistisse a código malicioso se mostrou inegociável, e no Windows isso significava regras de firewall, que significavam um principal separado, que significava privilégios elevados.

Para times que constroem agentes que executam comandos locais, a lição prática aqui é que a fronteira de imposição de segurança define a arquitetura, e não o contrário. Um design conveniente e sem privilégios elevados era tecnicamente viável para escrita de arquivos, mas não sobreviveu ao único requisito que não podia ser apenas uma sugestão — bloquear a exfiltração de dados. Tudo o que veio depois, das credenciais armazenadas via DPAPI ao binário command-runner, existe para atender a essa única exigência inegociável.

Como Wiesen coloca, o Windows não deu a eles nenhum recurso que correspondesse a 'agente de codificação autônomo seguro', então o time teve que construir um. O resultado, é verdade, não é simples, mas cada peça — o SID sintético, os dois usuários, as concessões assíncronas de ACL de leitura, o fluxo dividido de inicialização — remonta a uma falha específica de uma abordagem mais simples.