OpenAI mostró cómo construyó un sandbox seguro de Codex para Windows

OpenAI reveló cómo creó una sandbox completa para Codex en Windows, permitiendo que un agente ejecute comandos localmente sin acceso total al sistema. El objetivo era simple: preservar la conveniencia de la codificación autónoma mientras se impide que el modelo escriba libremente en cualquier lugar y acceda a internet sin permiso explícito del usuario.

Por Qué No Funcionó

Inicialmente, los usuarios de Windows tenían dos opciones malas. O confirmar casi cada comando, incluyendo lecturas simples de archivos, o habilitar Full Access y esencialmente confiar al agente el mismo nivel de permisos que el propio desarrollador. Para Codex, esto es particularmente sensible: el agente funciona a través de CLI, IDE y aplicaciones de escritorio, puede ejecutar pruebas, editar código, crear ramas Git e invocar herramientas de desarrollo comunes.

OpenAI verificó inicialmente los mecanismos estándar de aislamiento de Windows, pero ninguno encajaba sin compromisos serios. AppContainer proporciona un fuerte límite de seguridad, pero está diseñado para aplicaciones predefinidas en lugar de un conjunto abierto de escenarios con Git, Python, gestores de paquetes y binarios de terceros. Windows Sandbox resultó ser demasiado un mundo "separado": Codex necesita trabajar con el checkout real del usuario, no con una máquina virtual desechable, además este modo no está disponible en Windows Home. El mecanismo de niveles de integridad también lucía bien solo en el papel porque alteraba el modelo de confianza para el sistema de archivos actual del host.

Primer Esquema de Protección

El primer prototipo funcional de OpenAI se construyó sin requisitos de derechos de administrador. Utilizaba un SID sintético y un token restringido de escritura—un token especial que permite escribir datos solo donde coinciden simultáneamente los permisos de usuario normales y un permiso de sandbox separado. Esto permitía a Codex leer casi en cualquier lugar pero escribir solo en raíces de proyecto claramente definidas.

• se creó un SID separado `sandbox-write`
• a este SID se le otorgaban permisos de escritura, ejecución y eliminación en el directorio de trabajo actual y en `writable_roots`
• dentro de estos 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 sesión actual y `sandbox-write`

El enfoque funcionó bastante bien para archivos, pero la red siguió siendo un punto débil. El equipo intentó "romper" caminos de red típicos mediante variables de entorno como `HTTPS_PROXY`, `ALL_PROXY` y `GIT_SSH_COMMAND`, así como mediante sustitución de binarios stub para `ssh` y `scp`. Para comandos Git comunes e instaladores de paquetes, esto a menudo era suficiente, pero la protección era más bien recomendatoria: cualquier proceso podía ignorar variables de entorno, eludir PATH o abrir un socket directamente.

Cómo Funciona el Lanzamiento

Debido a limitaciones de red, OpenAI abandonó la idea de una sandbox completamente sin derechos de administrador y pasó al esquema actual, más estricto. Ahora durante la configuración, Codex crea dos usuarios locales: `CodexSandboxOffline` para procesos sin acceso a red y `CodexSandboxOnline` para escenarios donde se necesita acceso. Los comandos siguen ejecutándose con un token restringido, pero ya no bajo el nombre del usuario real, sino bajo un usuario sandbox especial al que se pueden aplicar reglas del Firewall de Windows. Esto requería un proceso de configuración separado.

Crea un SID sintético, establece cuentas sandbox, cifra sus credenciales a través de DPAPI y establece reglas de firewall que bloquean el tráfico saliente para el usuario offline. Paralelamente, el sistema otorga a los usuarios 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 correctamente archivos de usuario y herramientas. Parte de la configuración de ACL se realiza de forma asincrónica para evitar retrasar la instalación inicial.

Un problema separado surgió en el límite de lanzamiento de procesos. Resultó que `codex.exe` no puede completar de manera confiable la ruta completa desde iniciar sesión como usuario sandbox hasta `CreateProcessAsUserW(...)` desde el contexto del usuario real. Por lo tanto, OpenAI movió la ejecución de comandos a un binario separado, `codex-command-runner.exe`: primero `codex.exe` lo inicia como usuario sandbox, y el runner dentro de su propia sesión crea un token restringido e inicia el proceso secundario final.

En la arquitectura final participan cuatro capas: el propio `codex.exe`, un binario de configuración elevado, el command runner y el proceso destino.

Qué Significa Esto

Para desarrolladores de Windows, este es un cambio importante: los agentes de codificación locales se vuelven no solo más convenientes sino también más predecibles desde la perspectiva de seguridad. OpenAI esencialmente mostró que para codificación basada en agentes en Windows, no existe una única "API mágica", y el problema debe resolverse mediante una combinación de ACL, tokens, usuarios separados, reglas de firewall y binarios adicionales. Esto aumenta la complejidad de implementación pero acerca el modelo operativo de Codex a los requisitos reales de equipos que quieren automatizar trabajo rutinario sin abandonar completamente el control.