Codex no para de pedir Retry Without Sandbox

La mayoría está a una instalación o una línea de configuración de la solución. Ejecútalas en orden; la primera que devuelva algo malo es tu solución.

Corre estas tres comprobaciones

codex --version            # anota la versión; 0.115–0.118 tuvieron regresiones
command -v bwrap           # Linux/WSL2: espera una ruta; vacío = el sandbox no arranca
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml   # revisa tus ajustes

Este artículo trata de errores de ejecución y de sandbox/aprobación en tiempo de ejecución — el aviso command failed; retry without sandbox y el bucle de "cada comando necesita aprobación". Si tu problema es codex: command not found justo después de instalar, eso es un problema de PATH, no de sandbox. Para el conjunto completo de claves de config.toml que tocamos aquí, la referencia de config.toml de Codex CLI es la fuente de verdad.

Codex ejecuta los comandos de tu modelo detrás de dos controles separados. La gente los confunde, y esa confusión es la mitad de por qué este aviso resulta tan molesto.

El sandbox — el límite técnico

La política de aprobación — cuándo Codex se detiene a preguntar

La documentación oficial de sandboxing de Codex lo dice directamente: el sandbox define los límites técnicos y la política de aprobación decide cuándo Codex debe detenerse y preguntar antes de cruzarlos. Los dos trabajan juntos.

De dónde sale el aviso

el modelo quiere correr un comando
        |
        v
  sandbox_mode aplica el límite  -->  el comando corre limpio  -->  listo
        |
        v  (el comando sale con código no cero bajo el sandbox)
  approval_policy reacciona
        |
        v
  "command failed; retry without sandbox?"  -->  apruebas  -->  reejecuta sin sandbox

Así que un comando corrió, la capa del sandbox hizo que saliera con código no cero, y la política de aprobación reaccionó ofreciendo volver a correr el mismo comando fuera del sandbox cuando digas que sí. La redacción sugiere "tu código necesita más permiso", pero muy a menudo el comando habría estado bien. El propio sandbox no pudo arrancar, o una regresión etiquetó una edición normal como denegación. Ten esa separación presente — casi todas las soluciones de abajo son "que el sandbox pueda hacer su trabajo" o "decirle a la política de aprobación que deje de interrumpir el trabajo rutinario".

Antes de cambiar nada, decide en qué grupo estás. Esto te ahorra reescribir una configuración que nunca fue el problema.

Empareja tu síntoma con la causa antes de cambiar un ajuste. Elegir mal es por qué la gente se pasa una tarde reescribiendo una config que nunca fue el problema.

La causa raíz más común en Linux es la primera fila. La documentación de Codex es explícita en que en Linux y WSL2 se instala bubblewrap primero; Codex usa el primer bwrap que encuentra en PATH y, si no, recurre a un helper incluido que necesita user namespaces sin privilegios. Si no hay ninguno, Codex imprime un aviso de arranque y, desde entonces, cada comando sandoboxed falla hacia el aviso de reintentar. Eso es exactamente el comportamiento reportado en el issue #19162, donde cada edición de archivo fallaba a partir de la versión 0.115.0, y la primera pregunta de un maintainer fue si bubblewrap estaba instalado según los prerrequisitos de sandboxing.

Qué mecanismo aplica el sandbox depende por completo de tu plataforma, y eso decide si tienes algo que instalar o no.

Si estás en macOS o Windows PowerShell y aún así ves el aviso en cada comando, la causa casi nunca es el mecanismo del sandbox; salta a la Solución 2 (política de aprobación) o a la Solución 5 (regresión de versión). Las soluciones de "instalar algo" son un asunto de Linux y WSL2.

Ve de arriba abajo. La Solución 1 es la que más usuarios de Linux tienen pendiente. El resto cubre configuración, red, la regresión de versión y el caso de raíces escribibles.

LINUX / WSL2

# Debian / Ubuntu / WSL2 (Ubuntu)
sudo apt-get update && sudo apt-get install -y bubblewrap

# Fedora
sudo dnf install -y bubblewrap

# Arch
sudo pacman -S bubblewrap

command -v bwrap   # espera /usr/bin/bwrap

cat /proc/sys/kernel/unprivileged_userns_clone   # espera 1 (o el archivo ausente en kernels nuevos)

POLÍTICA DE APROBACIÓN

approval_policy = "on-request"
sandbox_mode   = "workspace-write"

MODO DE SANDBOX

sandbox_mode = "workspace-write"

RED

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

REGRESIÓN DE VERSIÓN

# fijar a una versión concreta
npm install -g @openai/codex@0.117.0

# o actualiza al último y vuelve a probar
npm install -g @openai/codex@latest
codex --version

MACOS / MULTIPLATAFORMA

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/Users/you/.cache/mytool"]

Dos flags aparecen constantemente en respuestas de foros, y uno de ellos es ahora una trampa.

codex --sandbox workspace-write --ask-for-approval never

Estos son los issues públicos detrás del aviso, con sus versiones y estado. Todos estaban cerrados al momento de escribir, lo que significa que llegó una solución o workaround, pero los números de versión te dicen qué builds evitar.

El patrón es claro: un cluster de regresiones entre 0.115 y 0.118 donde la ruta de apply_patch disparaba de más el aviso, encima de la causa perenne de Linux (bubblewrap no instalado). Si lees solo uno, #19162 es el reporte canónico de "cada comando", y la respuesta del maintainer apunta directo a los prerrequisitos de sandboxing.

Tras aplicar una solución, verifica en lugar de adivinar. Un bucle rápido:

codex --version                         # fuera del rango de regresión
command -v bwrap                        # Linux: resuelve a una ruta
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml

Luego arranca Codex y observa si aparece un aviso de arranque del sandbox. Sin aviso más una edición trivial que aplica sin pedir permiso significa que el límite funciona. Los builds recientes traen un diagnóstico estilo codex doctor; corre codex --help para ver los subcomandos que tu versión expone, ya que cambian entre releases.

Captura un setup que funcione como perfil

Cuando tengas un setup que funcione, captúralo como un perfil con nombre para no volver a escribir flags. Los archivos de perfil viven junto a config.toml como $CODEX_HOME/profile-name.config.toml y se eligen con --profile profile-name. Mantén un default estricto en config.toml y un perfil más suelto para repos que ya confías:

# ~/.codex/trusted.config.toml
approval_policy = "never"
sandbox_mode   = "workspace-write"

La mayoría de los casos de retry-without-sandbox son locales: bubblewrap, config o una regresión de versión. Pero a veces el comando subyacente está bien y el modelo es la parte lenta o fallida del bucle — y quieres un backend más rápido o más barato detrás del mismo flujo de Codex.

Codex CLI habla con cualquier endpoint compatible con OpenAI. Lo apuntas al gateway o proveedor en el que ya confías — el tuyo, uno alojado, un proxy self-hosted —, mantienes los ajustes de sandbox y aprobación exactamente como arriba y enrutas al modelo que quieras:

# apunta Codex a cualquier endpoint compatible con OpenAI que elijas
export OPENAI_BASE_URL="https://your-gateway.example/v1"
export OPENAI_API_KEY="your-key"
# luego corre Codex normalmente; la config de sandbox/aprobación no cambia
codex --sandbox workspace-write --ask-for-approval on-request

Esto no cambia nada del aviso del sandbox; eso es un control local. Solo significa que el backend detrás del bucle lo eliges tú. Un gateway unificado mantiene un base_url y una key entre muchos modelos, así que cambiar de modelo es editar una cadena en vez de un bloque nuevo por proveedor — y tus controles locales de seguridad se mantengan sin importar a qué backend enrutes.

Si el modelo de sandbox no encaja con tu flujo, estas son las opciones realistas.

El default honesto para la mayoría es la primera o la segunda opción: mantener el sandbox, arreglar la causa raíz y solo aflojar controles de forma deliberada. La opción del gateway va por la flexibilidad del backend — no por quitar seguridad.

Las soluciones de arriba silencian el aviso. El resto es la parte que vale la pena actuar antes de la próxima regresión.

Puedes leer este aviso de dos formas. La estrecha: instala bubblewrap, pon on-request, sigue. La útil: una herramienta de la que dependes tiene una capa de seguridad que no es tuya, y la única señal de que se rompió fue que cada comando rutinario se detuvo a pedir permiso.

Vemos una versión de esto en casi todo sistema de IA que auditamos. Un equipo construye sobre un cliente y un modelo por defecto, y una regresión de sandbox, una deprecación o un default de config silencioso convierten un setup que funcionaba en media jornada de adivinar. El aviso del sandbox de Codex es solo la instancia más reciente y más específica.

Tres cosas hacen que un setup sobreviva a estos cambios:

Si tu flujo se detiene porque el sandbox de una herramienta regredió, el flujo reprobó la prueba de diseño — no la herramienta.