Sandbox de Codex: modos, --yolo, Docker y nube

Un sandbox de Codex limita dónde pueden escribir los comandos y si pueden acceder a la red. Para el trabajo local, comienza con workspace-write; usa --yolo solo dentro de un sandbox externo, ya que desactiva tanto el sandbox de Codex como las solicitudes de aprobación.

Probamos Codex CLI 0.162.1 en macOS y en Docker, además de una tarea de Codex en Lizard Sandboxes. Esta guía cubre esos resultados, los ajustes que importan y cómo elegir una configuración.

Los ejemplos usan las versiones probadas. Nuestra revisión de fuentes del 21 de octubre de 2026 indicaba que 0.163.0 era la última versión estable. Comprueba tu versión instalada antes de aplicar ajustes de otra versión. Consulta la lista de versiones.

Qué protege el sandbox integrado de Codex

Codex aplica límites del sistema operativo a los comandos que inicia, incluidos los ejecutores de pruebas, Git y los gestores de paquetes. Esos límites controlan la escritura de archivos y el acceso a la red. Los servidores MCP, los conectores y las herramientas de navegador usan sus propios controles; el sandbox de comandos no contiene todas las herramientas que conectas. Consulta el alcance del sandbox y los controles de herramientas de OpenAI.

En nuestras pruebas de workspace-write en macOS, la escritura en el proyecto funcionó, la escritura en el directorio de inicio falló y .git/ siguió siendo de solo lectura. Las escrituras en /tmp y $TMPDIR funcionaron. La lectura de ~/.zshrc también funcionó: workspace-write no limita las lecturas a tu proyecto.

La documentación también protege los directorios existentes .codex, .agents y .aws dentro de las raíces con permisos de escritura. La protección abarca su contenido, y la de .git incluye un gitdir vinculado. Probamos .git; las otras rutas protegidas proceden de la documentación de OpenAI.

Habilitar el modo sandbox de Codex

Inicia una sesión interactiva en tu proyecto con:

codex --sandbox workspace-write --ask-for-approval on-request

Esto selecciona Auto: permite editar el espacio de trabajo y ejecutar comandos de rutina; un acceso más amplio requiere aprobación. Codex interactivo recomienda Auto para carpetas bajo control de versiones y solo lectura para las demás. Puede iniciar en modo de solo lectura hasta que confíes en la carpeta. En cambio, codex exec se ejecuta en modo de solo lectura por defecto. Para permitir cambios:

codex exec --sandbox workspace-write "<task>"

Reemplaza <task> con tu solicitud. Consulta los valores predeterminados interactivos y los permisos de exec; nuestra guía de codex exec cubre las tareas mediante scripts.

En macOS, Codex usa Seatbelt. En Linux y WSL2, usa bubblewrap para aislar el sistema de archivos y seccomp para filtrar llamadas al sistema. bubblewrap pasó a ser la opción predeterminada en 0.115.0. En Debian o Ubuntu, instálalo:

sudo apt install bubblewrap

Sin bwrap en PATH, Codex puede usar su herramienta auxiliar incluida, que requiere espacios de nombres de usuario sin privilegios. Ubuntu 24.04 también puede necesitar el perfil de AppArmor bwrap-userns-restrict. Sigue los requisitos previos.

Windows nativo admite MXC, la opción recomendada en las compilaciones compatibles de Windows 11: 24H2 compilación 26100.9278 o 25H2 compilación 26200.9278 y posteriores. Las alternativas antiguas son elevated y unelevated; WSL2 usa el sandboxing de Linux. Consulta los requisitos de Windows.

Configurar el acceso a la red y la escritura

El acceso a la red empieza desactivado en workspace-write. Para habilitarlo en tu configuración de Codex:

[sandbox_workspace_write]
network_access = true

Para una sola ejecución, usa -c sandbox_workspace_write.network_access=true. Con ese ajuste, nuestra prueba de red pasó de un fallo de DNS a HTTP 200. Habilita el acceso saliente; las reglas por dominio requieren el proxy de red separado. Consulta los ajustes de red.

Estos controles regulan la red de los comandos. Las solicitudes al modelo y de autenticación de Codex usan una vía aparte, por lo que una solicitud curl bloqueada no significa que la CLI no pueda acceder a su modelo. El proxy tampoco filtra las conexiones MCP ni el tráfico del navegador. Consulta el tráfico fuera del proxy de comandos.

Para otra carpeta con permisos de escritura, usa --add-dir con la ruta necesaria:

codex --add-dir <DIR>

Reemplaza <DIR> con esa carpeta. OpenAI recomienda agregar un directorio cuando eso es todo lo que necesita la tarea.

Comprobar el límite antes de una ejecución larga

Desde la carpeta del proyecto, ejecutamos estas cuatro pruebas:

codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ./inside && echo inside-ok || echo inside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'touch ~/codex-probe-outside && echo outside-ok || echo outside-blocked'
codex sandbox -c sandbox_mode="workspace-write" -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'
codex sandbox -c sandbox_mode="workspace-write" -c sandbox_workspace_write.network_access=true -- sh -c 'curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com || echo net-blocked'

En ese orden, obtuvimos inside-ok, outside-blocked, net-blocked (después de curl: (6) Could not resolve host: example.com) y 200.

Algunos documentos muestran codex sandbox macos|linux. La versión 0.162.1 no los acepta como subcomandos del sistema operativo: el host selecciona el mecanismo. Usa la forma sin subcomandos que mostramos arriba. El código fuente de la versión lo confirma.

Comprueba también los límites mediante la herramienta de shell del agente. Nuestra invocación a nivel del agente fue:

codex exec -s workspace-write -c approval_policy="never" \
  --ephemeral --json \
  "Run exactly these three shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry, do not use workarounds, do not ask for approval: 1) touch ./agent-inside  2) touch ~/codex-agent-probe  3) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

La solicitud ejecutó estos tres comandos:

touch ./agent-inside
touch ~/codex-agent-probe
curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com

En nuestra prueba, la escritura en el proyecto devolvió el código de salida 0. La escritura en el directorio de inicio falló con Operation not permitted, y curl devolvió el código de salida 6, Could not resolve host. No apareció ningún archivo en el directorio de inicio. Ejecutar estos comandos en una terminal separada, sin sandbox, no comprobaría los límites del agente.

Modos de sandbox y políticas de aprobación

El modo de sandbox fija los límites de los comandos. La política de aprobación decide cuándo Codex puede pedir permiso para superarlos.

En 0.162.1, la opción interactiva de aprobación acepta on-request y never. La primera pide permiso cuando necesita un acceso más amplio; la segunda impide los avisos y mantiene los límites del sandbox elegido. La configuración también admite una tabla de políticas detalladas. codex exec usa never por defecto y no acepta la opción interactiva -a. Consulta las opciones de aprobación y el valor predeterminado de exec.

Ten cuidado con los ejemplos antiguos: untrusted se retiró en 0.149.0, on-failure está obsoleto y --full-auto se eliminó de codex exec en 0.147.0. Nuestra ejecución de 0.162.1 rechazó --full-auto. Usa --sandbox workspace-write para tareas de exec que necesiten cambios.

Qué hace el modo Codex --yolo

--yolo es un alias de --dangerously-bypass-approvals-and-sandbox. Desactiva ambos controles, con el efecto de danger-full-access más la política de aprobación never. OpenAI indica que solo debe usarse en un entorno con un sandbox externo. Consulta la advertencia de la opción.

Repetimos la comprobación del agente con:

codex exec --yolo \
  --ephemeral --json \
  "Run exactly these two shell commands, one at a time, with your shell tool, and report the exit code and output of each. Do not retry and do not run anything else: 1) touch ~/codex-agent-probe  2) curl -sS -m 5 -o /dev/null -w '%{http_code}' https://example.com"

Los dos comandos eran la escritura en el directorio de inicio y la solicitud curl anteriores. Esta vez, el archivo apareció en nuestro directorio de inicio y la solicitud devolvió HTTP 200. Después eliminamos el archivo de prueba. El modo yolo de Codex otorga acceso fuera del proyecto.

Tanto Lizard como Docker Sandboxes inician Codex con la opción larga de omisión dentro de una microVM. Eso coincide con el uso previsto: la VM proporciona el límite externo. No protege del agente los archivos dentro de esa VM. Docker Sandboxes documenta su comando predeterminado de Codex; observamos el comando de Lizard durante nuestra prueba.

Ejecutar Codex en Docker

Probamos este Dockerfile:

FROM node:22-bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends git python3 ca-certificates curl \
 && rm -rf /var/lib/apt/lists/*
RUN npm install -g @openai/codex@0.162.1
WORKDIR /workspace

Compílalo como codex-sandbox-test. Nuestro proyecto estaba en la carpeta local app. CODEX_DIR apuntaba a una carpeta separada y existente que contenía una copia de nuestro inicio de sesión de ChatGPT. Ejecutamos:

docker run --rm \
  -v "$PWD/app:/workspace/app" \
  -v "$CODEX_DIR:/codex-home" \
  -e CODEX_HOME=/codex-home \
  -w /workspace/app \
  codex-sandbox-test codex exec -s workspace-write --ephemeral \
  "Run python3 -m unittest. Fix the failing test with the smallest reasonable change to the code under test, not the test. Run the tests again and report what changed."

En nuestro ejemplo de prueba, add(a, b) restaba sus entradas. Codex cambió return a - b por return a + b; tanto su ejecución de pruebas como una ejecución independiente en el host pasaron. El montaje del proyecto con permisos de escritura permitió que esos cambios llegaran al host.

El sandbox de Linux también funcionó en este contenedor predeterminado de Docker Desktop sin capacidades adicionales ni un paquete bubblewrap instalado. La herramienta auxiliar incluida de Codex permitió escribir en el proyecto, bloqueó una escritura en /root con Read-only file system y bloqueó el acceso a la red.

Ese resultado no abarca todos los hosts. OpenAI advierte que los ajustes de Docker pueden bloquear los espacios de nombres, bubblewrap con setuid o las operaciones de seccomp que Codex necesita. Si el sandbox interno no puede ejecutarse, configura el contenedor como límite y luego usa:

codex --sandbox danger-full-access

Primero comprueba los montajes, los privilegios y la política de red. La guía de contenedores de OpenAI advierte que un proyecto malicioso puede enviar al exterior cualquier cosa disponible dentro de un contenedor de desarrollo, incluidas las credenciales de Codex.

Autenticarse dentro del contenedor

Para la automatización, CODEX_API_KEY proporciona una clave a los procesos no interactivos de Codex. Limítala a la ejecución que la necesite. Para guardar un inicio de sesión con clave API desde una variable de entorno existente:

printenv OPENAI_API_KEY | codex login --with-api-key

Para iniciar sesión con un código de dispositivo:

codex login --device-auth

Debes habilitar el inicio de sesión con dispositivo en los ajustes de tu cuenta o espacio de trabajo. Otra opción es copiar auth.json desde una máquina con la sesión iniciada, como hicimos en la prueba. Trata auth.json como una contraseña: contiene tokens de acceso. Un inicio de sesión respaldado por un llavero puede no dejar un archivo útil para copiar. Consulta la autenticación y CODEX_API_KEY.

Los contenedores de Docker y Docker Sandboxes difieren

Docker Sandboxes usa la CLI separada sbx:

sbx run codex ~/my-project

Cada sandbox tiene su propio kernel de Linux y un Docker Engine privado. Un proxy en el host mantiene las credenciales del modelo fuera de la VM y las agrega a las solicitudes salientes. Las reglas de red deniegan el tráfico salvo que esté permitido; los perfiles del primer inicio son Open, Balanced y Locked Down. Balanced permite sitios comunes de desarrollo; Locked Down necesita una regla explícita para el proveedor del modelo. Consulta el aislamiento, el manejo de credenciales y los perfiles.

Los requisitos locales son macOS Sonoma 14+ en Apple silicon; Windows 11 en Intel/AMD con Windows Hypervisor Platform; o Ubuntu 24.04+ en x86-64/arm64 con KVM y pertenencia al grupo kvm. Docker Desktop no es necesario. Ejecutar sandboxes locales de sbx dentro de una VM requiere virtualización anidada. Consulta la guía de instalación.

No probamos Docker Sandboxes. Su opción de omisión predeterminada deja los archivos montados del proyecto con permisos de escritura, incluidos los hooks de Git; revísalos después de una ejecución.

Cuándo ayuda un sandbox en la nube

La computación remota ayuda cuando una tarea debe continuar después de que tu computadora portátil se desconecta o cuando varios agentes necesitan espacios de trabajo separados. Comparte solo el código y las credenciales que necesita cada tarea.

La documentación actual de Codex Cloud describe una VM por tarea. Un control de internet a nivel de entorno ofrece listas de permitidos para gestores de paquetes y dominios o acceso sin restricciones. Las variables de entorno llegan directamente a los programas; los secretos de red usan marcadores que un proxy reemplaza para destinos HTTPS permitidos en el puerto 443. Las funciones de nube requieren un plan compatible de ChatGPT: Plus, Pro, Business o Enterprise. La autenticación con clave API no las incluye. No probamos Codex Cloud. Consulta los entornos de nube, los planes y nuestra guía de Codex Cloud.

Lizard Sandboxes ejecuta tareas en microVMs de Firecracker, cada una con su propio kernel. Vendemos Lizard Sandboxes. Los recomendamos cuando necesitas espacios de trabajo remotos que puedas crear, ejecutar y pausar mediante una CLI; para el trabajo local, comienza con el sandbox integrado de Codex.

Ejecutar Codex en Lizard Sandboxes

Instala Lizard CLI, inicia sesión y elige un proyecto. Conecta una suscripción de ChatGPT:

lizard agents login chatgpt

O registra una clave API de OpenAI:

lizard agents add openai

Comprueba la conexión:

lizard agents status

Nuestra prueba usó una suscripción de ChatGPT ya conectada; no repetimos el inicio de sesión.

Crear y copiar el proyecto

Reemplaza el marcador del proyecto:

lizard sandbox create --project YOUR_PROJECT_ID --template codex --size small --timeout 3600000 --json

Establece SB con el ID del sandbox recibido y BUNDLE_DIR con una carpeta temporal local existente. El tiempo de espera le da a este espacio de trabajo una hora. La vida útil predeterminada es de cinco minutos; los comandos no la extienden.

Desde tu repositorio local:

git bundle create "$BUNDLE_DIR/app.bundle" HEAD
lizard sandbox files put "$SB" "$BUNDLE_DIR/app.bundle" /workspace/app.bundle
lizard sandbox exec "$SB" -- git clone /workspace/app.bundle /workspace/app

El paquete contiene el historial confirmado, incluidos los secretos confirmados, y excluye los archivos no confirmados. Revisa lo que envías.

Ejecutar la tarea

lizard sandbox prompt "$SB" --agent codex --cwd /workspace/app "Run the tests. Fix one failing test with the smallest reasonable change. Report what changed and which tests passed."

Mantén --agent codex explícito. Durante nuestra ejecución, la lista de procesos mostró:

codex exec --json --skip-git-repo-check --dangerously-bypass-approvals-and-sandbox -C /workspace/app "<prompt>"

El sandbox y las aprobaciones de Codex estaban desactivados; la microVM de Firecracker proporcionaba el aislamiento. El código dentro puede acceder a las credenciales disponibles para el proceso. Limita su alcance. La VM no oculta esas credenciales al agente.

Revisar, descargar y pausar

Revisa el diff, vuelve a ejecutar las pruebas de tu proyecto y guarda los archivos que necesites antes del último comando de pausa:

lizard sandbox exec "$SB" -- git -C /workspace/app status --short
lizard sandbox exec "$SB" -- git -C /workspace/app diff
lizard sandbox files get "$SB" /workspace/app/calc.py ./calc.py.review
lizard sandbox pause "$SB"

Nuestro ejemplo de prueba usó calc.py; elige tu archivo modificado al repetir el proceso. Codex corrigió el error de resta, nuestra ejecución separada de unittest mostró OK y el archivo descargado coincidió. Confirmamos el estado paused.

Guarda los resultados antes de que expire. Una pausa exitosa detiene la facturación de computación; los costos de almacenamiento de Persistent Volumes siguen siendo aparte. Usa la guía de inicio rápido y la referencia de la CLI de sandbox para los detalles del ciclo de vida.

Cuánto cuesta el espacio de trabajo en la nube

Tarifas de computación de Lizard el 21 de octubre de 2026:

La computación se factura por segundo mientras el espacio está en ejecución, incluido el tiempo inactivo. Una pausa exitosa detiene los cargos de computación; el almacenamiento de Persistent Volumes se factura por separado.

Lizard Pro cuesta $19 al mes, impuestos incluidos, con $19 de uso incluido. El uso adicional es pay as you go. Las cuentas nuevas obtienen una prueba de siete días con $5 de uso; se requiere una tarjeta. Los cargos de ChatGPT o de la API de OpenAI son aparte. Revisa los precios antes de una ejecución.

Problemas comunes de configuración

Qué probamos

El 21 de octubre de 2026, probamos Codex CLI 0.162.1 de npm en macOS 26.6.2, Apple silicon (arm64), en un nuevo repositorio de Git dentro del directorio de inicio. Comprobamos comandos de sandbox y llamadas de shell del agente con inicio de sesión de ChatGPT, incluida la comparación al omitir los controles.

Las pruebas de Docker usaron Docker Desktop, Docker Engine 28.1.1, arm64 y el kernel LinuxKit 6.10. Comprobamos los límites del sandbox y la corrección de una prueba de Python, y luego volvimos a ejecutar la prueba en el host.

Las pruebas de Lizard usaron Lizard CLI 4.0.65. La plantilla codex incluía Codex CLI 0.159.2, Node.js 22.23.2, Python 3.11.2 y git 2.39.5. Cubrimos la subida del paquete, la clonación, la tarea, las pruebas separadas, la revisión del diff, la descarga y la pausa.

No probamos Docker Sandboxes, Codex Cloud, Windows/WSL2 nativo, run_in_container.sh de OpenAI ni el registro de una cuenta nueva. Estas comprobaciones cubren las configuraciones registradas; no son una auditoría de seguridad.

Qué configuración deberías elegir

Usa workspace-write para el trabajo local con archivos y herramientas conocidos. Elige Docker para un entorno de ejecución repetible y prueba si el sandbox interno de Codex funciona allí. Considera Docker Sandboxes para el aislamiento local con microVM y credenciales guardadas en el host, o Codex Cloud para tareas dentro de ChatGPT.

Elige Lizard Sandboxes cuando necesites espacios de trabajo remotos mediante Lizard CLI. Comienza con una pequeña corrección de una prueba, revisa el diff, descarga el resultado y pausa el espacio de trabajo.