Modo YOLO de Codex CLI: aprobaciones full-auto explicadas y cómo ejecutarlo con seguridad

Qué significa "modo YOLO" en Codex CLI

"Modo YOLO" es el apodo de la comunidad para ejecutar Codex CLI con las aprobaciones desactivadas, para que trabaje en full auto sin pararse a preguntarte. OpenAI no lo llama así. El nombre cuajó porque capta la sensación: solo se vive una vez, así que apaga las peticiones y deja que el agente corra.

La motivación es la misma con la que se topa cualquier agente de código. Cuando Codex itera sobre una funcionalidad, arregla un bug o refactoriza, se detiene antes de cada acción: escribir un archivo, ejecutar un test, instalar un paquete, tocar la red. En una tarea real son decenas de confirmaciones, y la mayoría acaba dándole a que sí de todas formas, lo que en silencio tira por tierra el sentido de tener aprobaciones.

Ejecutar sin aprobaciones elimina todo eso. Codex lee, escribe y ejecuta comandos por su cuenta. Para trabajo repetitivo o muy acotado se siente como si el agente por fin funcionara a toda velocidad. El precio es que quitas todos los guardarraíles a la vez, incluidos los que sí querrías conservar.

Si lo que de verdad buscas es ejecutar varios agentes de Codex a la vez y no solo uno en full auto, la guía del enjambre de agentes Codex cubre ese lado, y la visión general del enjambre de agentes CLI de IA lo compara en todas las CLI.

Qué hacen en realidad los modos de aprobación de Codex

Codex CLI no tiene un único interruptor de encendido/apagado. Tiene un abanico de comportamientos de aprobación que deciden cuánto pregunta antes de actuar, junto a un sandbox que decide cuánto puede tocar. Las etiquetas exactas y los nombres de los flags cambian entre versiones de Codex, así que toma los nombres de abajo como la forma del sistema y no como algo que memorizar. Mira siempre codex --help para los flags que usa tu versión instalada.

El espectro de aprobaciones

• Sugerir / preguntar - Codex propone cambios y comandos pero espera a que apruebes cada uno. El extremo más cauto, y el más lento.
• Auto / al fallar - Codex hace el trabajo rutinario por su cuenta y solo se para a preguntar cuando algo parece más arriesgado o cuando un comando falla. Un punto medio que recorta casi todas las peticiones.
• Full auto - Codex actúa sin preguntar, ejecutando comandos y editando archivos por su cuenta. Este es el nivel al que se refiere la gente cuando dice "modo YOLO".

Codex CLI expone un nivel de full auto mediante un flag, normalmente --full-auto, que le deja trabajar sin pararse a por aprobaciones. También hay una forma de saltarse las aprobaciones por completo para tiradas totalmente sin supervisión, pensada para entornos en sandbox o desechables. Como los nombres exactos de los flags cambian entre versiones, confírmalos con la salida de ayuda en lugar de copiar un flag que viste en un post antiguo.

# Comprueba qué admite de verdad tu versión instalada
codex --help

# Tirada estilo full-auto (verifica el flag exacto de tu versión)
codex --full-auto "refactoriza el módulo de auth"

El dial del sandbox

Las aprobaciones deciden si Codex pregunta. El sandbox decide qué puede alcanzar Codex cuando sí actúa. Codex puede ejecutarse con el acceso al sistema de archivos y a la red limitado, así que incluso en full auto queda restringido a un área de trabajo definida en vez de a toda tu máquina. Apretar el sandbox es una de las formas más seguras de correr en full auto, porque acota el radio de impacto aunque no haya un humano en el bucle.

El modelo mental importante son dos diales independientes. Uno controla cada cuánto se para Codex a preguntar. El otro controla hasta dónde puede llegar cuando no pregunta. El "modo YOLO" suele girar el primer dial hasta el tope, a full auto. El error es dejar también el segundo dial abierto de par en par al mismo tiempo.

Los riesgos reales de ejecutar Codex sin aprobaciones

Esto no son hipótesis. Cuando ejecutas Codex en full auto sobre un repo en uso con un historial de Git de verdad y datos de verdad, cualquiera de estas cosas puede pasar dentro de una sola sesión, sin ninguna petición que la frene antes.

• Push de Git a la rama equivocada - Codex decide hacer commit y push de trabajo a medias a main, o hace force-push y machaca a un compañero.
• Borrado de archivos o directorios - Una instrucción malinterpretada se convierte en rm -rf sobre una ruta que no querías eliminar.
• Comandos de shell irreversibles - DROP TABLE, docker system prune o cualquier cosa que no se pueda deshacer una vez se ejecuta.
• Instalar la dependencia equivocada - npm install sobre un paquete con typosquatting o comprometido que a simple vista parecía correcto.
• Llamadas de red no deseadas - Golpear endpoints de producción, enviar datos a servicios externos o disparar webhooks que no esperabas.
• Sobrescribir trabajo sin commitear - Codex edita archivos que estabas tocando y tu trabajo sin commitear desaparece antes de que te des cuenta.

El full auto no es malo en sí. Es el ajuste correcto para mucho trabajo. El riesgo viene de ejecutarlo sin una capa que mantenga frenadas las operaciones de verdad peligrosas mientras todo lo seguro pasa de largo. La siguiente sección va sobre construir esa capa.

Cómo ejecutar Codex en full auto con seguridad

Hay varios enfoques, del menos controlado al más. El objetivo es el mismo en todos: mantener la velocidad del full auto en las operaciones seguras sin dejar nunca que un comando destructivo se ejecute sin supervisión.

Método 1: el flag de full auto en crudo (vale para trabajo desechable)

codex --full-auto "renombra este símbolo en todas partes"

Esto va bien para tareas rápidas y aisladas en las que confías en que no puede pasar nada destructivo, sobre una rama desechable o un proyecto de pruebas. Para cualquier cosa que toque Git, borrados o la red en un repo real, ejecutar el flag en crudo con el sandbox abierto de par en par es una apuesta.

Método 2: full auto más un sandbox apretado

Un punto de partida mejor es combinar full auto con un sandbox restringido, para que aunque Codex no pregunte, no pueda salir de un área de trabajo definida ni hacer llamadas de red arbitrarias. Esto acota el radio de impacto. La pega es que el sandbox es tosco: limita dónde puede actuar Codex, pero no entiende que "git push" es distinto de "git status", así que no puede bloquear de forma selectiva el único comando peligroso de Git mientras permite los seguros.

Método 3: Turbo Mode de CodeAgentSwarm más permisos por terminal (recomendado)

CodeAgentSwarm se coloca por encima de Codex CLI y añade la capa que les falta a los flags en crudo. Ejecutas Codex en cada terminal, activas Turbo Mode para la velocidad del full auto y luego usas los permisos por terminal para decidir exactamente qué operaciones se autoaprueban y cuáles se paran siempre. Es la diferencia entre un interruptor tosco y una política de verdad. Eliges codex cli en el selector SELECT AI AGENT que aparece al principio de esta guía, y el interruptor Enable Turbo Mode justo al lado es lo que activa ese full auto rápido pero con guardarraíles.

Esto es lo que te da esa capa por encima de Codex:

• Alcance por terminal - Cada terminal de Codex tiene su propia política de permisos. Puedes tener un agente abierto de par en par en una rama desechable y otro bien candado sobre el repo principal, en la misma ventana.
• Permisos granulares por categoría - Pon Permitir, Preguntar o Denegar de forma independiente para operaciones de archivos, comandos de shell, acciones de Git y acceso de red, en lugar de un único encendido/apagado global.
• Guardarraíles de Git - Mantén status, diff y log en autoaprobado mientras bloqueas push, force-push, merge y borrado de ramas. Este único ajuste evita los desastres más comunes del full auto.
• Diffs de archivos en vivo - Observa qué está cambiando cada agente de Codex en tiempo real, por terminal, para que una tirada en full auto nunca sea una caja negra.

El efecto práctico es que consigues la velocidad de ejecutar Codex sin aprobaciones, sin la parte en la que una instrucción malinterpretada te vuela la rama. Configuras la política una vez y Codex pasa de largo por el trabajo seguro mientras los comandos peligrosos siguen parándose para ti. Para un recorrido paso a paso del mismo sistema de permisos del lado de Claude Code, la guía de Turbo Mode YOLO de Claude Code cubre cada pantalla de configuración, y funciona igual tanto si el agente es Codex como Claude Code.

Buenas prácticas para tiradas de Codex en full auto

Sea cual sea el método que uses, estos hábitos mantienen fuera de la mesa los peores accidentes del full auto:

• Trabaja siempre en una rama de feature, nunca en main. Si Codex la lía, tiras la rama. Si la lía en main, lo nota todo el equipo.
• Haz commit antes de empezar una tirada en full auto. Un punto de restauración limpio significa que git checkout . te devuelve al instante si algo sale mal.
• Bloquea las operaciones peligrosas de Git. Push, force-push, merge y borrado de ramas deberían pararse siempre a pedir confirmación, incluso en full auto. Son las acciones de mayor impacto y más difíciles de deshacer.
• Aprieta el sandbox. Restringe el acceso al sistema de archivos y a la red para que ni siquiera una tirada sin supervisión pueda salir del área de trabajo.
• Vigila el diff. Una vista de cambios de archivos en vivo y por terminal convierte el full auto de caja negra en algo que de verdad puedes supervisar.
• Mantén los prompts acotados. "Refactoriza el middleware de auth para usar JWT" es mucho más seguro en full auto que "mejora el código". Cuanto más estrecho el alcance, menos margen tiene Codex para irse por las ramas.