Usa Codex en Windows con la aplicación de escritorio de ChatGPT nativa para Windows, la CLI o la extensión para el IDE.
La aplicación de escritorio de ChatGPT para Windows te permite trabajar con chats en paralelo, worktrees, tareas programadas, funciones de Git, el navegador integrado, vistas previas de archivos, complementos y habilidades.
La aplicación puede ejecutarse de forma nativa en PowerShell con un sandbox de Windows sin necesidad de usar WSL ni una máquina virtual. Así puedes usar Codex en flujos de trabajo nativos de Windows con permisos limitados de acceso al sistema de archivos y a la red.
Para instalar Codex en tu empresa, consulta la guía de implementación en Windows.
Codex admite tres implementaciones del sandbox de Windows:
mxc: es el sandbox recomendado para dispositivos Windows compatibles. Usa el aislamiento nativo de procesos sin requerir la aprobación de un administrador para la configuración, cuentas adicionales de Windows ni reglas de firewall locales.elevated: es la alternativa heredada preferida cuando MXC no está disponible o está deshabilitado. Un administrador debe aprobar la configuración. Los comandos se ejecutan en el sandbox sin privilegios de administrador.unelevated: es una alternativa heredada que puedes usar cuando no se puede realizar la configuración con privilegios elevados y la política de la organización lo permite. Ofrece menos aislamiento de red queelevatedy no permite denegar la lectura de rutas específicas.
Configurar el sandbox de Windows
El sandbox de Windows aplica los permisos activos del sistema de archivos y de la red a los comandos y a sus procesos secundarios. El perfil de permisos determina en qué rutas se puede leer o escribir y si se permite el acceso a la red. Por separado, la política de aprobación determina cuándo Codex solicita ejecutar comandos con permisos más amplios. Consulta Sandbox y aprobaciones.
Habilitar MXC
Para las cuentas de uso personal, la aplicación de escritorio da preferencia automáticamente a MXC si el dispositivo es compatible. Para las implementaciones empresariales o el uso independiente de la CLI, puedes habilitar el mismo comportamiento con la siguiente configuración.
En config.toml:
[features]
prefer_mxc = true
Con prefer_mxc = true, Codex usa MXC para ejecutar comandos de Windows si el dispositivo es compatible y la política lo permite. En caso contrario, sigue el procedimiento existente para seleccionar y configurar una implementación heredada.
Si en tu empresa la compatibilidad o la política varían según el dispositivo, mantén windows.sandbox configurado con la implementación heredada que permita tu organización, elevated o unelevated, como alternativa.
Los administradores pueden distribuir esta configuración como valor predeterminado o exigir features.prefer_mxc = true mediante requirements.toml. En ambos casos se puede recurrir a una implementación heredada. Consulta la configuración administrada para conocer la diferencia entre los valores predeterminados y los requisitos.
Mantener MXC deshabilitado
Para impedir que se use MXC en tu organización, agrega lo siguiente al archivo requirements.toml administrado:
[windows]
allow_mxc = false
Esto bloquea tanto la selección automática de MXC como la selección explícita mediante windows.sandbox = "mxc". La configuración y los requisitos existentes del sandbox heredado siguen vigentes.
Compatibilidad con MXC
El host ya debe contar con las capacidades necesarias de Microsoft Execution Containers (MXC), que Microsoft está habilitando gradualmente en dispositivos con Windows 11. Microsoft introdujo el aislamiento de procesos con MXC en Windows 11 24H2 (compilación 26100.9278) y 25H2 (compilación 26200.9278). Usa el siguiente comando para verificar si tu dispositivo admite MXC.
En Codex CLI 0.162.0 y versiones posteriores, puedes probar MXC con un solo comando sin cambiar el sandbox guardado en la configuración. Desde el directorio de tu proyecto, ejecuta:
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODE
La salida esperada es MXC_OK y el código de salida es 0. Esta prueba verifica que el comando se inicie con el perfil de permisos del espacio de trabajo y los requisitos administrados.
La selección explícita mediante windows.sandbox = "mxc" falla si las capacidades nativas necesarias no están disponibles o si la política bloquea MXC.
Ten en cuenta estas limitaciones de compatibilidad:
- Para usar la red administrada, el valor efectivo debe ser
allow_local_binding = true. MXC permite conexiones hacia y desde los servicios que usan la interfaz de loopback del host. Las reglas de dominio del proxy siguen aplicándose al tráfico que pasa por él, pero se eliminan las comprobaciones adicionales que realiza el proxy para destinos en redes privadas. - Cuando finaliza el comando en primer plano, se detienen los procesos secundarios que siguen activos. Prueba los flujos de trabajo que dependen de servidores de desarrollo que se ejecutan de forma independiente del comando que los inició.
- Al igual que en Linux y WSL, los patrones glob que deniegan la lectura se aplican a los archivos que coinciden cuando se inicia cada proceso en el sandbox. El proceso en ejecución puede leer los archivos coincidentes que se creen después si sus demás permisos le dan acceso. Las shells, los scripts, los monitores de cambios y los servidores de desarrollo de larga duración conservan esa lista de coincidencias mientras se ejecutan. La lista es específica de cada proceso y no abarca toda la sesión de Codex. Consulta cuándo se evalúan los patrones glob que deniegan la lectura.
Configurar una alternativa heredada
Selecciona la implementación alternativa en config.toml:
[windows]
sandbox = "elevated" # or "unelevated"
elevated es la alternativa heredada preferida. Usa cuentas de usuario exclusivas del sandbox con privilegios reducidos, límites de acceso al sistema de archivos, reglas de firewall y los cambios de política local necesarios para los comandos que se ejecutan en el sandbox.
Al igual que MXC, elevated identifica los archivos que coinciden con los patrones glob de denegación de lectura cuando se inicia cada proceso en el sandbox. El proceso en ejecución puede leer los archivos coincidentes que se creen después si sus demás permisos le dan acceso. Consulta cuándo se evalúan los patrones glob que deniegan la lectura para saber cómo afecta esto a los procesos de larga duración.
unelevated es una alternativa heredada. Ejecuta comandos con un token restringido de Windows derivado de tu cuenta de usuario actual, limita el acceso al sistema de archivos mediante listas de control de acceso (ACL) y usa controles del entorno para impedir la conexión a la red en lugar de la regla de firewall específica para el usuario sin conexión. Ofrece menos aislamiento de red que elevated y no permite denegar la lectura de rutas específicas, pero resulta útil cuando la política local o empresarial bloquea la configuración que requiere la aprobación de un administrador.
Usa MXC si el dispositivo es compatible y la política lo permite. En caso contrario, da preferencia a elevated y usa unelevated como segunda alternativa.
Los administradores de empresas pueden limitar las implementaciones heredadas del sandbox que Codex puede usar mediante requirements.toml:
[windows]
allowed_sandbox_implementations = ["elevated"]
Este ejemplo permite elevated e impide que se use unelevated como alternativa. No restringe mxc cuando MXC está disponible. Los demás requisitos administrados de permisos y red siguen vigentes. Para permitir cualquiera de las dos implementaciones heredadas, incluye ambos valores. Si no se selecciona ningún modo, Codex da preferencia a elevated.
Consulta la referencia de requirements.toml para conocer los valores admitidos. Para bloquear también MXC, usa el requisito independiente windows.allow_mxc.
De forma predeterminada, ambos modos heredados del sandbox también usan un escritorio privado para reforzar el aislamiento de la interfaz de usuario.
Aprovisionamiento del sandbox heredado con privilegios elevados por parte del equipo de TI
Si un empleado no tiene derechos de administrador local, el equipo de TI puede instalar la CLI y aprovisionar el sandbox con privilegios elevados antes de que el empleado inicie Codex. Desde un proceso de implementación con privilegios elevados, ejecuta:
codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'
Reemplaza la identidad y la ruta por la identidad de Windows del empleado y la ruta de su CODEX_HOME. El comando lee la configuración de ese usuario, aprovisiona el sandbox y guarda windows.sandbox = "elevated". Luego, el empleado ejecuta Codex desde una terminal sin privilegios elevados.
Permisos del sandbox
Si ejecutas Codex en modo de acceso completo, puede operar fuera del directorio de tu proyecto y realizar acciones destructivas involuntarias que provoquen la pérdida de datos. Para automatizar tareas de forma más segura, conserva los límites del sandbox y usa reglas para definir excepciones específicas. También puedes configurar la política de aprobación para que nunca solicite aprobación y así hacer que Codex intente resolver los problemas sin solicitar permisos elevados, según tu configuración de aprobación y seguridad.
Compatibilidad por versión de Windows
| Versión de Windows | Nivel de compatibilidad | Notas |
|---|---|---|
| Windows 11 | Recomendado | Es la mejor base para usar Codex en Windows. Usa esta versión si vas a estandarizar una implementación empresarial. |
| Windows 10 reciente con todas las actualizaciones | Sin garantías | Puede funcionar, pero es menos confiable que Windows 11. En Windows 10, Codex depende de funciones modernas de la consola, como ConPTY. En la práctica, se requiere Windows 10 versión 1809 o posterior. |
| Compilaciones anteriores de Windows 10 | No recomendado | Es más probable que falten componentes necesarios de la consola, como ConPTY, y que se produzcan fallas en entornos empresariales. |
Otras condiciones del entorno que debes tener en cuenta:
wingetdebe estar disponible. Si falta, actualiza Windows o instala el Administrador de paquetes de Windows antes de configurar Codex.- El sandbox heredado
elevatedrequiere que un administrador apruebe la configuración. - Algunos dispositivos administrados por empresas bloquean los pasos de configuración necesarios incluso si la versión del sistema operativo es compatible.
- MXC también requiere las capacidades nativas descritas en Compatibilidad con MXC. La tabla no indica si MXC está disponible en un dispositivo específico.
Comprobar el acceso de lectura del sandbox
Si un comando no puede leer un directorio, revisa el perfil de permisos activo, los requisitos administrados y los permisos de archivos de Windows. En la CLI, usa /status y /debug-config para inspeccionar la sesión activa y la configuración. Pídele a tu administrador que revise la restricción administrada en lugar de deshabilitar el sandbox.
Usa el sandbox nativo de Windows como opción predeterminada. Elige WSL si necesitas herramientas nativas de Linux, si tu flujo de trabajo ya se ejecuta en WSL2 o si las implementaciones nativas disponibles en Windows no se ajustan a tus necesidades.
Solución de problemas y preguntas frecuentes
Si estás resolviendo un problema en un equipo Windows administrado, revisa primero el modo del sandbox nativo, la versión de Windows y cualquier error de política que muestre Codex. Para MXC, comprueba la compatibilidad y la política de red efectiva. Los problemas del sandbox heredado pueden deberse a la configuración, a los derechos de inicio de sesión o a los permisos del sistema de archivos.