OpenAI explica cómo construyó el sandbox seguro de Codex para Windows

OpenAI ha explicado cómo creó un sandbox completo para Codex en Windows, de modo que el agente pueda ejecutar comandos en local sin acceso total al sistema. El objetivo era sencillo: mantener la comodidad de la programación autónoma, pero sin permitir que el modelo escriba libremente donde quiera ni se conecte a internet sin el permiso explícito del usuario.

Por qué no funcionó Al principio, los usuarios de Windows tenían dos opciones malas.

O bien aprobaban casi cada comando, incluida la simple lectura de archivos, o bien activaban Full Access y, en la práctica, concedían al agente el mismo nivel de permisos que el propio desarrollador. En Codex esto es especialmente delicado: el agente funciona a través de la CLI, el IDE y la aplicación de escritorio, y puede ejecutar tests, editar código, crear ramas de Git e invocar las herramientas de desarrollo habituales. OpenAI probó primero los mecanismos de aislamiento estándar de Windows, pero ninguno encajaba sin concesiones importantes.

AppContainer ofrece una frontera de seguridad sólida, pero está pensado para una aplicación definida de antemano, no para un conjunto abierto de escenarios con Git, Python, gestores de paquetes y binarios de terceros. Windows Sandbox resultó ser un mundo demasiado «aparte»: Codex necesita trabajar con el checkout real del usuario, no con una máquina virtual desechable, y además este modo no está disponible en Windows Home. El mecanismo de niveles de integridad también solo parecía atractivo sobre el papel, porque alteraba el modelo de confianza del sistema de archivos real del host.

El primer esquema de protección

OpenAI construyó el primer prototipo funcional sin requerir permisos de administrador. Utilizaba un SID sintético y un write-restricted token: un token especial que solo permite escribir donde coinciden a la vez los permisos normales del usuario y un permiso específico para el sandbox. Así, Codex podía leer casi en cualquier parte, pero escribir solo en las raíces del proyecto claramente definidas.

se creaba un SID independiente `sandbox-write` a este SID se le concedían permisos de escritura, ejecución y borrado en el directorio de trabajo actual y en `writable_roots` * dentro de esos directorios se podía prohibir por separado la escritura en `.git`, `.codex` y `.

agents` * cada comando se ejecutaba con un token restringido que tenía en cuenta `Everyone`, el SID de la sesión actual y `sandbox-write` Con los archivos, el enfoque funcionó razonablemente bien, pero la red siguió siendo el punto débil. El equipo intentó «romper» las rutas de red típicas mediante variables de entorno como `HTTPS_PROXY`, `ALL_PROXY` y `GIT_SSH_COMMAND`, además de sustituir `ssh` y `scp` por binarios stub. Para los comandos habituales de Git y los instaladores de paquetes esto solía bastar, pero la protección era más bien orientativa: cualquier proceso podía ignorar las variables de entorno, saltarse el PATH o abrir un socket directamente.

Cómo funciona la versión final

Por las limitaciones de red, OpenAI abandonó la idea de un sandbox completamente sin administrador y pasó al esquema actual, más estricto. Ahora, durante la configuración, Codex crea dos usuarios locales: `CodexSandboxOffline` para los procesos sin red y `CodexSandboxOnline` para los escenarios en los que sí se necesita acceso. Los comandos siguen ejecutándose con un token restringido, pero ya no en nombre del usuario real, sino de un usuario de sandbox específico al que se pueden aplicar reglas de Windows Firewall.

Esto exigió un proceso de setup independiente. Este crea el SID sintético, da de alta las cuentas de sandbox, cifra sus credenciales mediante DPAPI y establece reglas de firewall que bloquean el tráfico saliente del usuario offline. Al mismo tiempo, el sistema concede a los usuarios de sandbox permisos de lectura en directorios típicos como `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` y `C:\ProgramData`; de lo contrario, el agente ni siquiera podría leer con normalidad los archivos y herramientas del usuario.

Parte de la configuración de ACL se ejecuta de forma asíncrona para no retrasar la instalación inicial. Surgió otro problema en el arranque de procesos. Resultó que `codex.

exe` no puede recorrer de forma fiable todo el camino desde el inicio de sesión como usuario de sandbox hasta `CreateProcessAsUserW(...)` desde el contexto del usuario real. Por eso OpenAI trasladó la ejecución de comandos a un binario aparte, `codex-command-runner.

exe`: primero `codex.exe` lo lanza como usuario de sandbox y después es el runner, dentro de su propia sesión, quien crea el restricted token y lanza el proceso hijo final. La arquitectura definitiva tiene cuatro capas: el propio `codex.

exe`, el binario de setup con privilegios elevados, el command runner y el proceso de destino.

Qué significa

Para los desarrolladores de Windows supone un cambio importante: los agentes de programación locales se vuelven más cómodos y, además, más predecibles en materia de seguridad. En la práctica, OpenAI ha demostrado que para la programación agéntica en Windows no basta con una API «mágica», y que el problema hay que resolverlo combinando ACL, tokens, usuarios independientes, reglas de firewall y binarios adicionales. Esto aumenta la complejidad de la implementación, pero acerca el modelo de funcionamiento de Codex a las necesidades reales de los equipos que quieren automatizar tareas rutinarias sin renunciar por completo al control.