Codex danger-full-access, --yolo y el "modo unsafe": qué desactiva cada flag

¿Qué hace realmente danger-full-access en Codex?

danger-full-access es uno de los tres valores del flag --sandbox de Codex, y apaga el sandbox por completo. La documentación de sandboxing de OpenAI lo describe en una frase: el agente se ejecuta sin restricciones de sandbox, lo que elimina las fronteras de sistema de ficheros y de red. Cada comando de shell que genera el modelo se ejecuta entonces como tu usuario, con tus permisos, en tu sistema de ficheros real y con tu red real.

Los otros dos valores son los que importan en el día a día:

Hay dos detalles de workspace-write que conviene conocer antes de decidir que es demasiado restrictivo. Primero, el conjunto escribible no es solo el directorio actual: /tmp y $TMPDIR son escribibles por defecto, y puedes añadir rutas con sandbox_workspace_write.writable_roots en config.toml (la referencia de configuración también expone exclude_slash_tmp y exclude_tmpdir_env_var si quieres excluirlos). Segundo, el acceso a red tiene su propio interruptor, sandbox_workspace_write.network_access = true, así que "necesito que funcione npm install" es un argumento a favor de un booleano, no del acceso completo.

Lo que danger-full-access no hace es silenciar a Codex. Las peticiones de aprobación dependen de un flag distinto, y de ahí viene casi toda la confusión de la siguiente sección.

¿Qué elimina --dangerously-bypass-approvals-and-sandbox?

--dangerously-bypass-approvals-and-sandbox, con alias --yolo, elimina las dos protecciones a la vez: el sandbox del SO y las peticiones de aprobación. La referencia de la CLI de OpenAI lo describe así: ejecutar cada comando sin aprobaciones ni sandbox, y usarlo solo dentro de un entorno endurecido desde fuera. Esa segunda frase es toda la política. El flag existe para un contenedor o una máquina virtual que sean en sí mismos la frontera, no para un portátil con tus claves SSH, tus credenciales cloud y el .env de producción.

La diferencia entre los dos mecanismos es sencilla cuando los pones uno al lado del otro:

• El sandbox decide qué puede tocar un comando: qué rutas son escribibles, si se pueden abrir sockets. Lo aplica el sistema operativo, así que un comando que el modelo no pretendía ejecutar queda tan contenido como uno que sí pretendía.
• Las aprobaciones deciden cuándo Codex se detiene para preguntarte. Son un punto de control humano, y solo funcionan si hay un humano leyéndolas.

danger-full-access por sí solo te deja el punto de control. --yolo no te deja nada salvo el criterio del modelo, y el criterio del modelo es exactamente lo que una prompt injection escondida en un README, en un fixture de test o en el mensaje de error de una dependencia está diseñada para torcer. No es teoría: nuestra guía sobre fugas de sandbox en agentes de código recorre cómo el contenido de un repositorio se convierte en comandos, y el patrón se aplica a Codex sin cambios.

¿Son lo mismo -a never, --full-auto y el "modo unsafe"?

No. Aflojan capas distintas, y uno de ellos ni siquiera es un flag. Este es el mapa completo:

--ask-for-approval acepta untrusted (ejecuta solo las lecturas conocidas como seguras y pregunta ante cualquier cosa que mute estado), on-request (el valor por defecto: el modelo pregunta cuando quiere escalar, salir a la red o abandonar el workspace) y never. Las versiones antiguas también aceptaban on-failure, que lo ejecutaba todo dentro del sandbox y solo preguntaba cuando un comando fallaba allí; --full-auto era el atajo de esa combinación, y por eso sobrevive hoy como flag de compatibilidad.

El preajuste "Full access" que ves en el selector interactivo es la combinación de danger-full-access y never, y OpenAI lo etiqueta como "not recommended" en su propia documentación de aprobaciones. Es --yolo con un nombre más amable.

¿Es seguro el acceso completo de Codex?

El acceso completo de Codex es seguro exactamente mientras lo sea el entorno que lo rodea, e inseguro en cuanto deja de serlo. Dentro de un contenedor recién creado, sin credenciales, con un clon desechable y una regla de salida de red, danger-full-access es un intercambio razonable: el contenedor es el sandbox, y el de Codex solo lo frenaría. En un puesto de desarrollo significa que un modelo con tu identidad puede lanzar curl a cualquier sitio, escribir en cualquier ruta y leer cada token de tu directorio personal, y lo único que separa una instrucción hostil de ese resultado es que el modelo decida no obedecer.

Los datos que tenemos sobre agentes sin guardia no tranquilizan. En nuestro estudio de escalado, agentes que trabajaban sin capa de guardia ejecutaron DROP SCHEMA contra una base de datos de aplicación en producción dieciocho veces, y uno lanzó rm -rf fuera de su propio proyecto. Cuando pusimos un guardián de comandos delante de los mismos agentes, comprobó 1.769 comandos de shell a lo largo de las sesiones y detuvo diecisiete en pleno vuelo: un sudo destructivo fuera del proyecto, un borrado de esquema y la instalación de un paquete que no existe en el registro. Diecisiete de 1.769 es menos del uno por ciento, y el uno por ciento de "ejecuta todos los comandos" es justo la cifra que importa cuando el comando es destructivo.

18

ejecuciones de DROP SCHEMA contra una base en producción por agentes sin guardia, en nuestro estudio

1.769

comandos de shell comprobados en las sesiones con guardia del mismo estudio

17

comandos detenidos en pleno vuelo: sudo destructivo, borrado de esquema, paquete inexistente

Fíjate en aquello de lo que el acceso completo no te protege ni siquiera con un entorno limpio: el código. Un sandbox contiene comandos; no tiene opinión sobre si la comprobación de autorización que el modelo acaba de escribir es correcta. Volvemos a eso al final.

¿Cómo funciona el sandbox de Codex en macOS, Linux y Windows?

Codex aplica su sandbox con el sistema operativo, no con el modelo, y por eso aguanta incluso cuando el modelo está siendo manipulado. En macOS usa el framework Seatbelt de Apple, el mismo mecanismo de políticas sandbox-exec que confina a los demonios del sistema, y funciona sin instalar nada. En Linux y bajo WSL2 usa bubblewrap (bwrap) con filtros seccomp; las versiones anteriores usaban Landlock y seccomp directamente. En Windows usa un sandbox nativo de Windows, elevado o no, cuando se lanza desde PowerShell, y el mecanismo de Linux cuando corre bajo WSL2.

De ahí salen dos consecuencias prácticas. Si falta bwrap en una máquina Linux, Codex no puede construir allí su sandbox: instálalo antes de dar por hecho que estás protegido. Y si un comando se rechaza y no sabes por qué, codex sandbox ejecuta un comando bajo la política actual para depurar, con --log-denials en macOS para mostrar qué bloqueó Seatbelt. Esa es la herramienta correcta para "Codex no puede escribir aquí", y una respuesta mucho mejor que tirar de danger-full-access.

Seatbelt también zanja una duda muy repetida en las búsquedas: "Codex seatbelt" no es una función que se active. Es de lo que están hechos read-only y workspace-write en un Mac.

¿Cuándo es el acceso completo la decisión correcta?

El acceso completo es la decisión correcta cuando otra cosa ya es la frontera. El patrón que funciona:

Contenedor o VM nuevos, clon desechableNinguna credencial de larga duración montadaSalida de red limitada a los registros necesariosEntonces, y solo entonces, --yolo

Tres comprobaciones antes de activar el flag:

1. ¿Qué puede leer el proceso? Si ~/.ssh, ~/.aws, ~/.codex/auth.json o un .env con claves activas están al alcance, la respuesta no es el acceso completo. El fichero de credenciales de Codex ya ha sido objetivo de un paquete npm malicioso; no se lo pongas más fácil.
2. ¿A dónde puede enviar datos? Red sin restricción más prompt injection es un canal de exfiltración. Si no puedes restringir la salida, deja network_access cerrado y que Codex pregunte.
3. ¿Quién lee la salida? En los pipelines de codex exec nadie mira las aprobaciones de todos modos, lo cual es una razón para apoyarse más en el sandbox, no para quitarlo.

Si falla cualquiera de las tres, usa la configuración de abajo.

¿Qué usar en lugar de --yolo?

Para casi cualquier tarea, workspace-write con aprobaciones on-request, la red cerrada y el proyecto marcado como de confianza te da un agente rápido que sigue sin poder salirse de su carril. En ~/.codex/config.toml:

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

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/tu/scratch"]

[projects."/Users/tu/work/payments-api"]
trust_level = "trusted"

trust_level = "trusted" le dice a Codex que aplique la configuración .codex/ propia del proyecto; los proyectos no confiables se saltan esas capas locales, que es justo lo que quieres para un repositorio que acabas de clonar de un desconocido. Si lo que molesta son las peticiones, ajusta qué las dispara en vez de apagarlas: las versiones recientes exponen una approval_policy granular y una opción approvals_reviewer = "auto_review" que envía las aprobaciones a un revisor automático. Trata el auto-review como una comodidad, no como una frontera: es un modelo juzgando a otro modelo.

Para CI y codex exec, conserva el sandbox y quita solo las peticiones: --sandbox workspace-write -a never en un runner sin credenciales de producción es una postura coherente. --yolo en ese mismo runner no lo es, porque el sandbox no te costaba nada.

La brecha que ningún flag cierra

Todos los flags de este artículo gobiernan lo que Codex puede ejecutar. Ninguno gobierna lo que Codex escribe, y el código es donde vive ahora la mayor parte del riesgo. Un sandbox workspace-write dejará que el agente haga commit de un endpoint sin comprobación de autorización, de un gestor de reembolsos sin tope o de una consulta construida concatenando cadenas, porque nada de eso es un comando. Son diffs.

Esa es la capa que VibeDefend añade en agent-time. Se sitúa en el bucle de Codex, contrasta el diff que el agente está a punto de escribir con tus propias reglas, reescribe la versión insegura antes de que aterrice, y vigila los comandos de shell con la misma política que produjo los diecisiete bloqueos de arriba. En nuestro estudio, los agentes con la capa siguieron las reglas de seguridad en el 89 % de los tickets, frente al 12 % de los agentes que solo tenían un fichero de reglas en el repositorio. El sandbox mantiene a Codex fuera de tu máquina; el guardián mantiene su código fuera de tu cola de incidentes.

Si ejecutas Codex en --yolo a propósito, en un contenedor y con un guardián sobre el diff, tienes una configuración defendible. Si lo ejecutas en --yolo en tu portátil porque las peticiones molestaban, lee la guía completa de seguridad de Codex y luego hablamos: arreglarlo lleva alrededor de un minuto.

Preguntas frecuentes

¿danger-full-access y --yolo son lo mismo?

No. --sandbox danger-full-access quita el sandbox del SO y conserva las peticiones de aprobación. --dangerously-bypass-approvals-and-sandbox (--yolo) quita el sandbox y las peticiones. El preajuste "Full access" del selector es el segundo.

¿Qué hace exactamente codex --yolo?

Ejecuta de inmediato cada comando que genera el modelo, con los permisos de tu usuario, en tu sistema de ficheros real, con red sin restricción, y nunca pregunta. La referencia de OpenAI lo limita a un entorno endurecido desde fuera, es decir, un contenedor o una VM que sean en sí mismos la frontera.

¿Es peligroso -a never por sí solo?

Menos de lo que se suele pensar, siempre que el sandbox siga activo. --ask-for-approval never quita el punto de control humano, pero workspace-write sigue confinando las escrituras y la red permanece cerrada salvo que la hayas abierto. Se vuelve peligroso en cuanto lo combinas con danger-full-access.

¿Qué es el "modo unsafe" de Codex?

No existe ningún flag con ese nombre. "Modo unsafe", "modo peligroso" y "run dangerously" se usan para hablar de danger-full-access, de --yolo o de -a never, que son tres cosas distintas. Comprueba a cuál se refiere de verdad un tutorial antes de copiar el comando.

¿Cómo dejo que Codex use la red sin acceso completo?

Pon network_access = true bajo [sandbox_workspace_write] en config.toml, o pasa -c sandbox_workspace_write.network_access=true para una sola ejecución. Las escrituras siguen confinadas al workspace; solo se abre la red.

¿Funciona el sandbox de Codex en Windows?

Sí. Desde PowerShell usa un sandbox nativo de Windows, elevado o no; bajo WSL2 usa el mecanismo de Linux (bubblewrap y seccomp). Los valores de --sandbox y las claves de config.toml son los mismos en todas las plataformas.

¿El sandbox frena la prompt injection?

Contiene lo que un comando inyectado puede tocar; no frena la inyección. Un README malicioso puede seguir empujando al modelo a escribir código inseguro, o a pedir una escalada que un humano cansado aprueba. Mantén el sandbox activo y añade una capa que revise el código y los comandos, no solo las rutas de ficheros.