Crear un sandbox seguro y eficaz para habilitar Codex en Windows

Cuando me uní al equipo de ingeniería de Codex en septiembre de 2025, Codex para Windows no tenía una implementación de entorno aislado, lo que significaba que los usuarios de Windows se veían obligados a elegir entre dos opciones deficientes al usar los agentes de programación de OpenAI:

1. Aprobar casi todos los comandos (incluso las lecturas) que un agente de programación quisiera ejecutar, lo cual es ineficiente y molesto. Una de las principales ventajas de usar Codex es que no tienes que hacer tú todo el trabajo tedioso.
2. Activar el modo de acceso completo: dejar que Codex ejecute todos los comandos sin aprobación ni restricciones, lo que elimina fricción a costa de la supervisión.

Codex⁠, nuestro agente de programación, se ejecuta en los portátiles de los desarrolladores, ya sea a través de la CLI, la extensión del IDE o la aplicación de escritorio. Gestiona una conversación entre una persona frente al teclado y un modelo que se ejecuta en la nube para encargarse de la inferencia.

Codex se ejecuta de forma predeterminada con los permisos de un usuario real, lo que significa que puede hacer todo lo que el usuario puede hacer. Esto es potente y potencialmente peligroso. El modelo de programación puede indicar al arnés que ejecute comandos localmente, desde ejecutar pruebas hasta leer o editar un archivo o crear una rama en Git, por lo que el modo predeterminado de Codex intenta encontrar el equilibrio adecuado entre eficacia y seguridad. Este modo predeterminado permite a Codex leer archivos casi en cualquier lugar y escribir archivos dentro de tu área de trabajo (es decir, el directorio en el que estás ejecutando Codex), sin acceso a internet a menos que especifiques que lo quieres. Para lograr esta restricción automática de la escritura de archivos y del acceso a la red dentro de límites seguros, Codex necesita un entorno aislado que realmente haga cumplir estas restricciones.

Un entorno aislado es un entorno de ejecución restringido. Cuando un desarrollador usa Codex, el sistema operativo de su ordenador inicia un comando con permisos reducidos y esas restricciones se propagan por todo el árbol de procesos. Todos los comandos de Codex se ejecutan en un entorno aislado desde el principio y cada proceso descendiente permanece dentro del mismo límite.

Codex necesita funciones de aislamiento impuestas por el sistema operativo del ordenador para implementar un entorno aislado eficaz. Algunos sistemas operativos proporcionan utilidades que hacen esto bien (por ejemplo, Seatbelt en macOS, seccomp o bubblewrap en Linux); sin embargo, Windows actualmente no ofrece este tipo de capacidad de serie.

Para que usar Codex en Windows fuera igual de seguro y satisfactorio que ya lo es en cualquier otro lugar, necesitábamos implementar nuestro propio entorno aislado.

Windows ofrece algunas herramientas y elementos básicos de aislamiento. Aunque ninguna cumplía del todo nuestros requisitos, estudiamos varias soluciones potenciales: AppContainer, Windows Sandbox y el etiquetado de Mandatory Integrity Control.

AppContainer

• Qué: AppContainer es el entorno aislado nativo de Windows, un modelo de aislamiento basado en capacidades creado para apps que saben, de antemano, exactamente a qué necesitan acceder.
• Por qué: resultaba atractivo porque ofrece un límite real del sistema operativo en lugar de restricciones de mejor esfuerzo.
• Por qué no: Codex no es una aplicación con un alcance muy delimitado. Impulsa flujos de trabajo de desarrollo abiertos: shells, Git, Python, gestores de paquetes, herramientas de compilación y cualquier otro binario que el agente decida que necesita. En la práctica, eso hizo que AppContainer no encajara con el problema. Proporcionaba un aislamiento fuerte, pero para una clase de cargas de trabajo mucho más limitada que «dejar que un agente actúe como un desarrollador».

Windows Sandbox

• Qué: Windows Sandbox es la máquina virtual ligera y desechable de Microsoft. Obtienes un escritorio de Windows nuevo con un límite de aislamiento fuerte y todo lo que hagas dentro desaparece cuando termina la sesión.
• Por qué: era interesante por razones evidentes, al ser mucho más compatible con software arbitrario que AppContainer. Además, desde una perspectiva de seguridad, es un entorno mucho más sólido.
• Por qué no: Codex necesita actuar directamente sobre el checkout, las herramientas y el entorno reales del usuario, no dentro de un escritorio desechable separado que requeriría configuración y una conexión entre host e invitado. También tenía un problema fundamental de producto: Windows Sandbox ni siquiera está disponible en las ediciones Windows Home.

Etiquetado de integridad de Mandatory Integrity Control (MIC)

• Qué: Windows tiene un concepto llamado «niveles de integridad», como bajo, medio y alto, que determinan cuánto confía el sistema en los objetos y procesos. La regla básica es que un proceso con menor integridad no puede escribir en un objeto con un nivel de integridad superior, aunque la ACL normal lo permitiera en otras circunstancias. Por ejemplo, un proceso de baja integridad se considera menos fiable, por lo que Windows le impide escribir en objetos normales de integridad media, salvo que esos objetos se vuelvan a etiquetar explícitamente para permitirlo.
• Por qué: MIC parecía elegante sobre el papel; ejecutar Codex con baja integridad, volver a etiquetar como de baja integridad las raíces con permisos de escritura y dejar que Windows impidiera la escritura en cualquier otro lugar. Eso nos habría dado una vía sin privilegios de administrador respaldada por un mecanismo real del sistema operativo.
• Por qué no: al igual que las ACL, las etiquetas de integridad modifican el sistema de archivos real del host, y en este caso el cambio semántico es especialmente amplio. Marcar un área de trabajo como de baja integridad no significa simplemente que «Codex puede escribir aquí». Significa que los procesos de baja integridad en general pueden escribir allí. En el equipo real de un desarrollador, eso convierte el checkout real del usuario en un coladero de baja integridad para el host, lo que es mucho más arriesgado que conceder ACL cuidadosamente dirigidas a un único diseño del entorno aislado. Aunque las herramientas de desarrollo de integridad media sigan funcionando, el modelo de confianza subyacente del área de trabajo ha cambiado de una manera difícil de contener y aún más difícil de justificar.

Después de evaluar todas las opciones y ver que ninguna era viable, empezamos a diseñar nuestra propia solución para ofrecer una buena experiencia de Codex a los usuarios de Windows.

Nuestro primer prototipo funcional usaba una combinación de conceptos y herramientas de Windows para implementar el aislamiento que necesitábamos. Desde el principio, uno de los objetivos fue lograr que esto funcionara sin requerir permisos de nivel superior, es decir, que Codex no tuviera que pedir al usuario privilegios de administrador solo para configurar o ejecutar el entorno aislado. Eso significaba averiguar cómo imponer límites razonables a dos cosas: la escritura de archivos y el acceso a la red.

Si no limitábamos en absoluto la escritura de archivos, tendríamos un problema de seguridad. Si la limitábamos demasiado, el entorno aislado perjudicaría la productividad del usuario, ya que necesitaría pedir aprobación constantemente. Para resolver este problema, nos apoyamos en dos bloques fundamentales importantes de Windows: los SID y los tokens con restricción de escritura.

Un SID, o identificador de seguridad, es la identidad que Windows asocia a los permisos. Cada usuario tiene un SID, los grupos tienen SID e incluso una sola sesión de inicio de sesión obtiene su propio SID. Por ejemplo, una sesión actual iniciada podría tener un SID como S-1-5-5-X-Y. El SID asignado al grupo de administradores locales podría ser S-1-5-32-544.

Windows también permite crear SID sintéticos que no corresponden a un usuario real pero que aun así pueden aparecer en las ACL (listas de control de acceso), que definen quién puede leer, escribir o ejecutar en archivos o directorios concretos. Eso hace que los SID sean un elemento básico útil para nuestro entorno aislado: podemos crear SID exclusivamente para que los use el entorno aislado de Codex, sin interferir con nada más del equipo.

Los tokens de proceso son objetos de seguridad en Windows que definen la identidad y los privilegios de un proceso en ejecución. Determinan qué acciones puede realizar un proceso. Un token con restricción de escritura es un tipo concreto de token de proceso que hace que Windows realice una comprobación de acceso adicional en las operaciones de escritura.

Para que una escritura se realice correctamente, deben superarse dos comprobaciones:

1. La identidad normal del usuario (el «propietario» del token) debe tener permiso para hacerlo
2. También debe concederse acceso al menos a un SID de la lista de SID restringidos del token

En la práctica, estas comprobaciones nos permitían usar ACL para definir exactamente dónde podía el entorno aislado modificar el sistema de archivos, lo que nos ofrecía la precisión que necesitábamos en torno a las operaciones de escritura.

Con SID y tokens con restricción de escritura, nuestro entorno aislado sin permisos de nivel superior funcionaba así:

1. La configuración del entorno aislado creaba un SID sintético llamado sandbox-write.
2. Al SID sandbox-write se le concedió acceso de escritura, ejecución y eliminación a lo siguiente:
   1. El directorio de trabajo actual
   2. Cualquier elemento adicional de writable_roots configurado en config.toml
3. La configuración del entorno aislado denegaba explícitamente a ese mismo SID el acceso de escritura a ubicaciones de «solo lectura dentro de las ubicaciones con permisos de escritura», como:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex iniciaba comandos con un token con restricción de escritura cuya lista de SID restringidos incluye Everyone, el SID de la sesión iniciada actual y el SID sintético sandbox-write.

Este flujo resolvía de forma eficaz la limitación de la escritura de archivos y parecía prometedor. Ahora necesitábamos una solución para limitar el acceso a la red del entorno aislado.

Limitar el acceso a la red es una parte importante del entorno aislado; sin ello, el código malicioso podría extraer datos del equipo hacia internet. Como queríamos evitar tener que solicitar permisos de nivel superior, teníamos pocas opciones para bloquear de forma contundente el tráfico de red. Las herramientas que queríamos usar, como Windows Firewall, por lo general no podían instalarse sin permisos de administrador.

Sin Windows Firewall como opción, se reducía lo que podíamos controlar. Intentamos hacer que el entorno secundario fallara de forma segura para los tipos de herramientas con acceso a la red que los desarrolladores usan de verdad, de manera que los comandos de Git, los instaladores de paquetes, etc., fallaran en el entorno aislado y el usuario tuviera que aprobar cualquier operación orientada a internet. La idea era envenenar las vías de escape más evidentes: enviar el tráfico compatible con proxy a un punto de acceso muerto, hacer que el transporte HTTP(S) de Git hiciera lo mismo y hacer que Git sobre SSH fallara de inmediato. Además, antepusimos un pequeño directorio denybin a PATH y reordenamos PATHEXT para que los scripts simulados de SSH y SCP se resolvieran antes que los binarios reales.

Por ejemplo, estas son algunas de las variables de entorno concretas que usamos para limitar el acceso a la red:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Eso captaba gran parte del tráfico normal impulsado por herramientas, pero seguía siendo solo orientativo. Un proceso podía ignorar el entorno, eludir PATH o simplemente abrir sockets directamente; era demasiado arriesgado.

Como ocurre con cualquier implementación de software interesante, el primer prototipo tenía ventajas e inconvenientes. Aunque cumplía su función con solo unas pocas capacidades estándar de Windows, permitía escrituras en el sistema de archivos muy explícitas y específicas, y se ejecutaba sin permisos de nivel superior —lo que evitaba que los usuarios tuvieran que aceptar demasiadas solicitudes de obtención de permisos de nivel superior o ser administradores en su equipo local—, tenía algunos inconvenientes importantes, algunos de los cuales impedían que se convirtiera en nuestro diseño final:

• Velocidad de configuración: aplicar ACL al área de trabajo puede resultar costoso según la topología del directorio del área de trabajo.
• Huella: aplicamos ACL reales al sistema del desarrollador, aunque la huella no es especialmente invasiva porque todas las ACL aplicadas pertenecen a un SID sintético personalizado creado y usado solo por el entorno aislado.
• Semántica difícil de cambiar: la dependencia de las ACL para las restricciones basadas en archivos hace que cambiar la semántica del entorno aislado sea costoso y complejo. Mientras que en macOS podemos cambiar dinámicamente cómo generamos el archivo .sbpl usado para configurar Seatbelt, el entorno aislado de Windows podía requerir una operación lenta e intensa para ajustar las ACL.
• La protección de red es débil. Como se ha mencionado antes, era «orientativa», algunos programas que implementaran su propia pila de red la eludirían con toda seguridad y no estaba diseñada para resistir código adversario.

Los tres primeros problemas son inherentes a una implementación de entorno aislado personalizada lo bastante flexible para flujos agénticos. Sin embargo, la cuestión de la supresión de red era distinta.

Además de que un agente malicioso pudiera eludir fácilmente la supresión de red basada en el entorno, mucho código o binarios bienintencionados también la eludirían simplemente si no respetaban las variables de entorno de proxy, o si implementaban su propio código de red basado en sockets. Consideramos que este aspecto era suficiente para justificar la inversión en un modo de entorno aislado mejor.

Para obtener una mejor supresión de red, queríamos usar Windows Firewall, que nos permite bloquear el tráfico saliente de red para usuarios o programas. Por desgracia, no podíamos crear de forma eficaz una regla de firewall funcional que se aplicara solo a los comandos generados por el arnés de Codex por varias razones:

• Windows no permite asociar una regla de firewall con la identidad no principal de un token restringido. Esto significa que no podíamos aplicar una regla de firewall a «cualquier token que incluya nuestro SID sintético en su lista de SID restringidos».
• Aunque podíamos crear una regla de firewall que asociara un binario concreto, eso solo nos permite limitar la red de codex.exe en sí. No se aplicaría a los procesos que el agente genera en nombre del usuario, como los procesos de Git o Python.
• Otras dimensiones de asociación del firewall también tenían la forma equivocada. Las reglas con alcance de usuario seguían asociando el usuario real de Windows en el diseño sin permisos de nivel superior, no solo el proceso secundario restringido. Las reglas por ruta del programa eran demasiado generales: podían bloquear codex.exe o python.exe en general, pero no esta invocación específica en entorno aislado de python.exe. Las reglas basadas en puerto o dirección también respondían a una política completamente distinta. Por ejemplo, no queríamos bloquear el puerto 443; queríamos bloquear el acceso saliente arbitrario para este árbol de procesos restringido específico.

Para aplicar una regla de firewall específicamente a nuestros comandos en el entorno aislado, necesitábamos ejecutarlos como una entidad principal independiente, no como el usuario «real». Este enfoque nos llevó por un nuevo camino, uno en el que relajamos nuestra restricción de «sin permisos de nivel superior».

La siguiente iteración del entorno aislado, que es nuestra implementación actual, requiere permisos de nivel superior de administrador en el momento de la configuración. Por eso me refiero a él como «el entorno aislado con permisos de nivel superior». En el límite donde Codex genera un comando en el sistema, el entorno aislado con permisos de nivel superior se parece al que no tiene permisos de nivel superior. Sigue ejecutando procesos secundarios bajo un token restringido —de forma similar, un token write_restricted con la misma lista de SID restringidos [Everyone, Logon, Synthetic]— sin embargo, el principal de este token ya no es el usuario real de Windows, sino uno de dos usuarios locales creados por el propio Codex:

• CodexSandboxOffline (el que es objetivo de las reglas del firewall)
• CodexSandboxOnline (el que no es objetivo de las reglas del firewall)

Este detalle, aparentemente pequeño, en realidad tiene grandes implicaciones para el entorno aislado, para quién puede usarlo y para la complejidad de su configuración y ejecución en tiempo de ejecución.

Es visualmente similar al prototipo sin permisos de nivel superior, con la incorporación de reglas de firewall y un usuario de Windows dedicado que es quien realmente ejecuta los comandos. (Sin embargo, la introducción de estos nuevos conceptos implica que hay más trabajo de configuración antes de que el entorno aislado pueda empezar a ejecutar y proteger comandos).

El diseño del entorno aislado sin permisos de nivel superior tenía un paso de configuración sencillo, pero relativamente pequeño:

• Crear un SID sintético si es necesario
• Aplicar ACL para el SID sintético sandbox-write

Sin embargo, el entorno aislado con permisos de nivel superior tiene más cosas que hacer.

• Crear un SID sintético, si todavía no se ha creado
• Crear los usuarios del entorno aislado en línea y fuera de línea, si todavía no se han creado
• Almacenar localmente las credenciales de los usuarios recién creados y cifrarlas mediante la Windows Data Protection API (DPAPI) en un lugar al que los usuarios del entorno aislado no puedan acceder
• Crear reglas de firewall que bloqueen todo el tráfico saliente de red para el usuario CodexSandboxOffline o, si ya existen, validar que sean correctas

Hay una complicación adicional en la etapa de configuración. Se espera que el entorno aislado de Codex tenga acceso de lectura equivalente al del usuario real de Windows. En el entorno aislado sin permisos de nivel superior, donde el SID principal del token restringido era el usuario de Windows, esto se lograba. Sin embargo, eso no es tan sencillo cuando el principal pasa a ser un nuevo usuario CodexSandbox. Muchos directorios relevantes en Windows conceden permisos de lectura y ejecución a «usuarios autenticados». Un ejemplo notable es el directorio de perfil del usuario. De forma predeterminada, los usuarios de Windows no pueden leer los directorios de perfil de otros usuarios de Windows, por lo que incluso la simple lectura de archivos fallaría en muchos casos.

Para resolverlo, añadimos otra capa al proceso de configuración del entorno aislado: una para conceder ACL de lectura a los usuarios del entorno aislado donde esas ACL quizá no existieran ya. Por ejemplo, en algunos directorios de Windows de uso común:

• C:\Usuarios\<usuario-real>
• C:\Windows\
• C:\Archivos de programa\
• C:\Archivos de programa (x86)\
• C:\ProgramData\

Como esta lista de directorios se gestiona en base a los mejores esfuerzos posibles y la instalación de ACL en cada uno de ellos puede resultar bastante costosa, ejecutamos esta lógica de forma asíncrona para que el paso de configuración del entorno aislado, que sí bloquea al usuario, no tenga que esperar a que se complete.

Encapsulamos la lógica de configuración en su propio binario en parte para cruzar el límite de UAC solo cuando hiciera falta. Pero la razón más profunda era arquitectónica: la configuración del entorno aislado tiene una función fundamentalmente distinta de la de codex.exe. Mantener la lógica de configuración del entorno aislado en un binario dedicado permitía que codex.exe siguiera siendo un arnés normal sin permisos de nivel superior; evitaba que la maquinaria de configuración exclusiva de Windows inflara codex.exe en otras plataformas; desacoplaba el trabajo de configuración más prolongado del ciclo de vida del proceso principal; y nos daba un único lugar para gestionar las distintas rutas de configuración que necesitaba el entorno aislado.

Debido a cómo funcionan en Windows los límites entre usuarios y el inicio de sesión de tokens, no podíamos seguir creando un token restringido y generar un proceso con él como hacíamos con el entorno aislado sin permisos de nivel superior. Para generar realmente comandos como otro usuario de Windows, nuestra primera idea fue el siguiente flujo:

• codex.exe se ejecuta como el usuario real de Windows. Después, en una secuencia, Codex hace lo siguiente:
  • Llama a LogonUserW(...) para el usuario del entorno aislado.
  • Llama a CreateRestrictedToken(...) sobre ese token del usuario del entorno aislado.
  • Usando ese token restringido del usuario del entorno aislado, llama a CreateProcessAsUserW(...) para iniciar el proceso secundario final.

En la práctica, ese flujo deseado no funcionó debido a un muro de privilegios en CreateProcessAsUserW(...). Esto significa que codex.exe podía crear un token restringido para el usuario del entorno aislado, pero no podía iniciar de forma fiable un proceso secundario con ese token desde el lado del límite correspondiente al usuario real. Necesitábamos un proceso que ya se estuviera ejecutando como el usuario del entorno aislado; eso nos permitiría que el paso de restricción y la generación final ocurrieran del lado del usuario del entorno aislado en vez de en el del usuario real.

Ese requisito dio lugar a codex-command-runner.exe, un nuevo binario cuya única función es acuñar un token restringido y generar el comando solicitado. En lugar de pedir a codex.exe que hiciera por sí solo todo el flujo (usuario real → usuario del entorno aislado → token restringido → proceso secundario), dividimos el flujo en dos:

Parte 1

• codex.exe llama a CreateProcessWithLogonW(...) para iniciar codex-command-runner.exe como el usuario del entorno aislado, sin usar todavía un token restringido.

Parte 2

• Dentro del ejecutor, OpenProcessToken(GetCurrentProcess(), ...) abre el propio token del ejecutor, que ya pertenece al usuario del entorno aislado.
• El ejecutor llama a GetTokenInformation(...) para extraer el SID de inicio de sesión del entorno aislado y luego a CreateRestrictedToken(...) para crear el token restringido final.
• Aún dentro del ejecutor, llama a CreateProcessAsUserW(...) con ese token restringido para iniciar el proceso secundario real.

Albert Einstein dijo: «Todo debe hacerse tan simple como sea posible, pero no más simple». En ese espíritu, nuestro diseño resolvió adecuadamente cada problema. La arquitectura final tiene las cuatro capas que hemos tratado anteriormente:

• codex.exe en sí
• codex-windows-sanbox-setup.exe para gestionar todo el trabajo de configuración con permisos de nivel superior
• codex-command-runner.exe para ejecutar comandos con token restringido
• El proceso secundario

Cuando abordé este proyecto por primera vez, no tenía una idea clara de adónde terminaría llegando. Mi idea fue empezar por implementar la función de entorno aislado en la frontera entre Codex y el sistema operativo. Este enfoque coincide estrechamente con cómo se implementa el entorno aislado de Codex en macOS y Linux.

A medida que fui aprendiendo más sobre las herramientas concretas que ofrece Windows, y tras docenas de decisiones para equilibrar la seguridad y la facilidad de uso, el sistema fue creciendo hasta su forma actual: múltiples binarios, usuarios personalizados, reglas de firewall, un paso de configuración con permisos de nivel superior, procesos asíncronos y más.

No es un sistema especialmente simple, pero cada elemento de complejidad se añadió por necesidad, para construir un entorno aislado que fuera a la vez seguro y, en la medida de lo posible, no se interpusiera en el camino del usuario.

Al trabajar para ofrecer una buena experiencia del usuario a quienes usan Codex en Windows, nuestro objetivo era crear algo seguro que no comprometiera la utilidad: la razón principal para usar Codex es que los agentes puedan hacer trabajo sin requerir tu atención constante.

Una de las mayores lecciones de este proyecto fue que Windows no nos proporcionó un solo elemento básico que se ajustara limpiamente a «agente de programación autónomo seguro». Combinamos varias herramientas y conceptos para crear algo coherente. Algunas ideas iniciales resultaron ser callejones sin salida. El diseño final fue un híbrido de prototipos anteriores, cada uno de los cuales resolvía parte del problema.

La otra lección fue que la seguridad de un agente de programación es distinta de la seguridad de las aplicaciones más clásica. Codex tiene que funcionar para flujos de trabajo reales de desarrolladores. El trabajo de ingeniería consistió en equilibrar la compatibilidad con cargas de trabajo agénticas frente a una aplicación real de las restricciones. Esa tensión dio forma a las concesiones del diseño final.

¿Tienes curiosidad por ver el entorno aislado de Codex en acción? Pruébalo⁠.