Si quieres que Codex avance por su cuenta —editar archivos, ejecutar comandos y seguir trabajando sin pedirte permiso a cada paso—, activar "Full Access" parece la solución obvia. Sin embargo, puede seguir mostrando confirmaciones. La explicación y la forma de dejarlo realmente desatendido, probadas con Codex CLI v0.145.0, van primero.
El motivo: el "modo automático" no es un único interruptor. Codex separa el sandbox, que delimita qué puede tocar, de la política de aprobación, que determina cuándo se detiene a preguntar. El acceso de red es una tercera barrera independiente. Relajar una opción no modifica las demás, y una actualización puede devolver silenciosamente la sesión a la política predeterminada.
Para no intervenir en la CLI: --yolo es la única opción que elimina todas las barreras de una vez. Si prefieres conservar el sandbox, configura ambos ejes de forma explícita. Hazlo al iniciar la sesión y vuelve a comprobarlo después de cada actualización.
# Completamente desatendido: sin sandbox ni confirmaciones (solo en entornos desechables):
codex --yolo
# Más seguro: puede editar libremente en el proyecto, pero pregunta para salir de él:
codex --sandbox workspace-write --ask-for-approval on-requestPara no intervenir en la app: abre el menú de aprobaciones, elige Full access y vuelve a seleccionarlo tras cada actualización: las versiones nuevas restablecen el modo.
Esta es la respuesta corta. A continuación tienes el mapa completo: todos los modos, su equivalencia interna y cuándo conviene usar cada uno.
Los tres modos de Codex, comparados
El sandbox establece qué puede tocar el agente —archivos y red—; la política de aprobación define en qué momento se para a pedir confirmación. El modo automático no hace más que combinar ambas opciones, aunque la app de escritorio y la CLI denominen esas mismas combinaciones de forma distinta.
| Nombre en la app | Qué hace | Equivalente en la CLI |
|---|---|---|
| Ask for approval | Edita archivos del espacio de trabajo, ejecuta comandos locales rutinarios y pide confirmación antes de acceder a Internet o hacer algo fuera del espacio de trabajo | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (valor predeterminado actual de la app) | Mismos límites, pero las solicitudes de aprobación aptas se envían a un revisor de IA en lugar de a ti (esto es Auto-review) | lo anterior + approvals_reviewer = "auto_review" |
| Full access | Sin sandbox ni solicitudes de aprobación; acceso sin restricciones a archivos y red | sandbox_mode = "danger-full-access" + approval_policy = "never" |
Si trabajas habitualmente desde la CLI, puedes definir estos valores directamente con --sandbox y --ask-for-approval, o cambiar de preajuste durante la sesión mediante el selector /permissions. Si aún estás valorando qué cliente usar, esa es otra cuestión: aquí comparamos Codex y Claude Code. Este artículo se centra en los ajustes.
Por qué "Full Access" todavía pide confirmación
Hay tres causas, y pueden coincidir.
Sandbox y aprobaciones son controles distintos. La combinación workspace-write + on-request permite a Codex editar libremente dentro de tu proyecto, pero lo detiene al cruzar sus límites: una llamada de red, un archivo fuera del repositorio o un sudo. Si relajas el sandbox pero mantienes las aprobaciones bajo demanda, seguirá pidiendo permiso en cada límite.
La red tiene su propia barrera. Full Access puede seguir tratando Internet como un permiso separado del sistema de archivos. Como señaló @mxcl (16 de julio de 2026), Codex "cannot use the Internet without full access, ending task until the user enables full access." La escritura de archivos y el acceso a la red no son el mismo permiso.
Las actualizaciones restablecen el modo. Varios usuarios se encontraron con este problema a finales de julio de 2026: al actualizar Codex, las sesiones activas volvían silenciosamente a la política predeterminada. @s_rafcon (22 de julio) indicó que los hilos "switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit." Configura el modo al inicio de la sesión y revísalo tras cada actualización.
La CLI: --full-auto ya no está; usa esto en su lugar
codex --full-auto era el atajo para "trabajar en mi proyecto sin preguntar" (approval_policy = "on-request" + sandbox_mode = "workspace-write"). El comando interactivo ya no lo acepta. Probado en v0.145.0:
$ codex --full-auto
error: unexpected argument '--full-auto' foundEn su lugar, define ambos ejes explícitamente: es exactamente lo que hacía la opción anterior.
# Sustituto actual de --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# O bien, sin interacción ni confirmaciones, pero conservando el sandbox:
codex -a never -s workspace-write exec "your task"codex exec --full-auto sigue aceptando la opción para scripts; el error solo afecta al comando interactivo. Según codex --help, --ask-for-approval admite untrusted / on-request / never, mientras que --sandbox admite read-only / workspace-write / danger-full-access. Cada "modo" de la app es una combinación de esos dos valores.
--yolo: cuándo tiene sentido saltarse todos los controles
--yolo es el alias corto de --dangerously-bypass-approvals-and-sandbox. Es el verdadero interruptor para no intervenir: activa danger-full-access junto con never, sin límites en el sistema de archivos ni barreras de aprobación. Sobrevivió a la retirada de --full-auto precisamente porque su nombre deja claro el riesgo: codex --yolo funciona correctamente en v0.145.0, donde codex --full-auto devuelve un error.
Muchos usuarios con experiencia lo usan por defecto y, para la tarea adecuada, tiene sentido: úsalo cuando el propio entorno sea la barrera de seguridad. Trata la máquina como si fuera desechable:
- Ejecuta Codex en una VM o contenedor de desarrollo desechable, no en tu equipo habitual.
- Elimina antes las credenciales de producción del entorno.
- Limita el alcance de la tarea y revisa
git diffantes de continuar.
Como --yolo elimina todas las barreras, un rm -rf, git push o DROP TABLE accidental se ejecutará sin pedir confirmación: ese es el precio de la velocidad. (Apuntar Codex a un endpoint autoalojado o compatible con Anthropic mediante un proveedor de modelos personalizado no cambia nada aquí; al sandbox no le importa qué modelo haya detrás de la API.)
"Approve for me" / Auto-review: una IA aprueba por ti
El modo más reciente, y el predeterminado actual de la app, es Auto-review. Las escaladas aptas se envían a un agente revisor independiente —un Codex pequeño que ejecuta GPT-5.4 Thinking (low)—, que aprueba o deniega con una justificación. OpenAI lo define como "a reviewer swap, not a permission grant": no amplía los directorios donde puedes escribir ni habilita la red; solo cambia quién da el visto bueno.
Las cifras proceden de la evaluación de OpenAI del 30 de abril de 2026: Auto-review requiere la intervención humana aproximadamente 200x menos que la aprobación manual y aprueba cerca del 99.1% de las escaladas que revisa (99.93% de todas las acciones). En su ejemplo ilustrativo de 10.000 acciones, 9.280 se ejecutaron dentro del sandbox sin cambios, 720 llegaron al revisor y solo 7 fueron denegadas.
Incluye protecciones para evitar una cadena interminable de denegaciones: el turno se interrumpe tras 3 denegaciones consecutivas o después de 10 denegaciones dentro de una ventana móvil de las últimas 50 revisiones. Cuando se detenga, ejecuta /approve para abrir el selector Auto-review Denials y autorizar una acción para volver a intentarla.
El inconveniente es que esas comprobaciones de seguridad pueden frenar ejecuciones largas. Usuarios que trabajaban con tareas /goal de varias horas informaron a finales de julio de 2026 de que el aviso periódico "keep waiting?" interrumpía flujos que antes funcionaban sin supervisión durante días. OpenAI también afirma claramente que "should not be treated as a guarantee of security": la recuperación en red team es alta, pero imperfecta (90.3% overreach, 99.3% prompt injection, 96.1% misaligned-model). Es un buen valor predeterminado, no un sustituto del sandbox en trabajos delicados.
Para activarlo desde la configuración en vez de la interfaz:
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Qué modo deberías usar en cada caso
- Programación local del día a día:
workspace-write+on-request("Ask for approval"). Conservas el veto para todo lo que salga del repositorio, que es donde está el daño potencial. - Ejecuciones largas sin supervisión: "Approve for me" (Auto-review). Ten presente que todavía se detiene ante las acciones que marca, así que no es un modo totalmente desatendido.
- Trabajo puntual y arriesgado en un entorno desechable:
--yolo. Es el más rápido y el más peligroso; solo es seguro cuando el entorno no puede sufrir daños relevantes. - Leer o revisar una base de código:
read-only. Sin escrituras ni sorpresas.
La conclusión honesta es que no existe un ajuste que sea a la vez completamente autónomo y completamente seguro. Cada paso hacia una experiencia sin intervención cambia tu criterio por el de un clasificador. El intercambio merece la pena para trabajo rutinario y es una mala idea sobre infraestructura de producción. Elige según la tarea, no una vez para siempre.
Preguntas frecuentes
¿Hay un modo automático en Codex?
Sí, aunque es un conjunto de preajustes y no un único interruptor. En la app, "Ask for approval", "Approve for me" y "Full access" son los modos automáticos; en la CLI puedes montar el mismo comportamiento con --sandbox y --ask-for-approval, o usar /permissions.
¿Cómo hago que Codex apruebe todos los comandos automáticamente?
Configura approval_policy = "never". Junto a workspace-write, deja de pedir confirmación dentro del sandbox; junto a danger-full-access —es decir, --yolo— deja de preguntar por completo. Esta última combinación elimina todas las barreras, así que solo debes usarla en un entorno aislado.
¿Qué es el modo Auto-review de Codex?
Auto-review (approvals_reviewer = "auto_review", mostrado como "Approve for me") dirige las decisiones de aprobación a un agente revisor de IA en lugar de a ti. Aprueba alrededor del 99% de lo que revisa y requiere intervención humana aproximadamente 200x menos, pero no garantiza la seguridad.
¿Sigue funcionando --full-auto?
No en la CLI interactiva. Probado en v0.145.0, codex --full-auto devuelve "unexpected argument." codex exec --full-auto sigue aceptándolo como alias obsoleto para scripts. Para uso interactivo, configura --sandbox workspace-write --ask-for-approval on-request.
¿Es seguro el modo --yolo?
No. Ese es precisamente el sentido de su nombre. Desactiva simultáneamente el sandbox y todas las aprobaciones. Solo resulta razonable dentro de una VM o contenedor desechable, sin credenciales de producción y con una tarea de alcance limitado.