Como a OpenAI construiu uma sandbox do Codex no Windows sem um mecanismo nativo do sistema

A lacuna que começou com uma funcionalidade em falta no sistema operativo

Quando David Wiesen se juntou à equipa de engenharia do Codex em setembro de 2025, o agente de programação não tinha qualquer sandbox no Windows. Isso deixava os utilizadores de Windows com duas más opções: aprovar praticamente todos os comandos que o agente quisesse executar, incluindo leituras, ou ativar o modo Full Access e deixar o Codex executar o que quisesse sem supervisão.

O motivo era prosaico, mas decisivo. O modo predefinido do Codex — ler em quase qualquer lado, escrever apenas dentro do espaço de trabalho, sem acesso à internet salvo pedido explícito — depende de o sistema operativo impor esses limites. O macOS tem o Seatbelt; o Linux tem o seccomp e o bubblewrap. O Windows não vem com nada equivalente por defeito.

Por isso, a tarefa da equipa não foi configurar uma sandbox já existente, mas construir uma a partir de peças do Windows que nada tinham a ver entre si. Esse enquadramento explica por que motivo o sistema final é tão elaborado.

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

A equipa avaliou o AppContainer, o Windows Sandbox e a rotulagem por Mandatory Integrity Control, e rejeitou as três por razões concretas e distintas entre si.

O AppContainer oferece uma verdadeira fronteira a nível de sistema operativo, mas foi concebido para aplicações que declaram as suas capacidades antecipadamente — a forma errada para um agente que controla shells, Git, Python, gestores de pacotes e todos os binários que decidir usar. O Windows Sandbox é uma caixa mais robusta, uma VM descartável, mas o Codex precisa de atuar sobre o checkout e as ferramentas reais do utilizador, não sobre um ambiente de trabalho descartável; além disso, não está disponível nas edições Windows Home, o que o desqualifica logo a nível de produto.

A rotulagem por integridade do MIC parecia elegante — executar o Codex com integridade baixa e reetiquetar as raízes com permissão de escrita — mas marcar um espaço de trabalho como de integridade baixa significa que qualquer processo de integridade baixa no sistema pode escrever ali, transformando o checkout real do desenvolvedor num ponto de despejo à escala do sistema. A alteração semântica era demasiado abrangente para se justificar.

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

O primeiro design funcional evitava pedir privilégios de administrador aos utilizadores. Apoiava-se em dois mecanismos do Windows: identificadores de segurança sintéticos e tokens com restrições de escrita. Um SID sintético chamado sandbox-write recebia permissões de escrita, execução e eliminação sobre o diretório de trabalho e quaisquer writable_roots configuradas, e via explicitamente negada a escrita em caminhos sensíveis como .git, .codex e .agents. Os comandos eram executados sob um token com restrições de escrita cuja lista de SIDs restritos incluía Everyone, o SID da sessão e sandbox-write.

As escritas em ficheiros foram resolvidas de forma limpa. O acesso à rede não. Sem privilégios de administrador, a Windows Firewall estava fora de questão, pelo que a equipa só conseguia definir substituições de ambiente — apontar os proxies para um endpoint morto (HTTPS_PROXY=http://127.0.0.1:9), forçar o GIT_SSH_COMMAND a terminar com erro (exit 1) e antepor um diretório denybin ao PATH.

O autor é direto quanto ao limite dessa abordagem.

Isso apanhava muito do tráfego normal gerado pelas ferramentas, mas continuava a ser meramente indicativo. Um processo podia ignorar o ambiente, contornar o PATH, ou simplesmente abrir sockets diretamente — demasiado arriscado.Montana Labs

Crucialmente, até binários bem comportados que implementassem a sua própria pilha de rede escapariam a este esquema. Foi essa fragilidade por si só, e não o custo de configurar as ACLs nem a dificuldade de alterar a semântica, que levou a equipa a abandonar a restrição de não usar privilégios elevados.

Porque razão a aplicação real de regras de rede exigiu quatro binários e dois utilizadores fictícios

A Windows Firewall conseguia bloquear tráfego de saída, mas apenas se os processos em sandbox fossem executados como um principal distinto. As regras de firewall não conseguem corresponder ao SID sintético de um token restrito, não conseguem distinguir uma invocação em sandbox do python.exe de qualquer outra, e bloquear uma porta como a 443 era completamente a política errada — o objetivo era bloquear o acesso arbitrário à rede para uma árvore de processos específica.

A solução foi criar dois utilizadores locais, CodexSandboxOffline (visado pelas regras de firewall) e CodexSandboxOnline (não visado), com credenciais armazenadas e encriptadas via DPAPI de forma a que os utilizadores da sandbox não as possam ler. Como estes utilizadores não correspondem ao utilizador real do Windows, perdiam acesso de leitura a diretórios normalmente partilhados com Authenticated Users, pelo que o passo de configuração também concede ACLs de leitura em caminhos como o perfil do utilizador, C:\Windows e Program Files — executado de forma assíncrona por ser lento.

Iniciar comandos como outro utilizador esbarrou numa barreira de privilégios na função CreateProcessAsUserW, que não conseguia lançar de forma fiável um processo filho com token restrito a partir do lado do utilizador real da fronteira. A solução encontrada foi introduzir o codex-command-runner.exe: o codex.exe lança o runner como utilizador da sandbox através de CreateProcessWithLogonW, e o runner — já do lado do utilizador da sandbox — gera o token restrito e cria o processo filho real. Juntamente com um binário de configuração dedicado e elevado, isto resulta em quatro camadas: o codex.exe, o binário de configuração, o command runner e o processo filho.

A implicação: a paridade entre plataformas do Codex teve como custo um passo de configuração com privilégios de administrador

O resultado central é restrito e específico: para que o Codex se comportasse da mesma forma no Windows que no macOS e no Linux, a OpenAI teve de exigir permissões de administrador elevadas no momento da configuração — exatamente a restrição que a equipa tentou evitar no seu primeiro prototipo. A supressão de acesso à rede que resistisse a código adversarial revelou-se inegociável, e no Windows isso significava regras de firewall, o que significava um principal separado, o que significava privilégios elevados.

Para equipas que constroem agentes que executam comandos localmente, a lição concreta aqui é que a fronteira de aplicação de regras determina a arquitetura, e não o contrário. Um design cómodo e sem privilégios elevados era tecnicamente viável para escritas em ficheiros, mas falhou no único requisito — bloquear a exfiltração de dados — que não podia ser meramente indicativo. Tudo o que se seguiu, desde as credenciais armazenadas via DPAPI ao binário command-runner, existe para satisfazer esse único requisito incontornável.

Como Wiesen o resume, o Windows não lhes deu nenhum mecanismo que correspondesse a 'agente de programação autónomo e seguro', pelo que a equipa teve de construir um. O resultado, admitidamente, não é simples, mas cada peça — o SID sintético, os dois utilizadores, as concessões assíncronas de ACLs de leitura, o fluxo dividido de criação de processos — remonta a uma falha específica de uma abordagem mais simples.