Codex retira la política untrusted: qué debes cambiar

Codex CLI v0.149.0 (estable, 20 de agosto de 2026) retiró la política de aprobación untrusted en el PR #39630, “Retire the untrusted approval policy” (retirar la política de aprobación untrusted).¹ El PR elimina untrusted “from the CLI, configuration schema, and MCP tool interface” (de la CLI, del esquema de configuración y de la interfaz de herramientas MCP), y un approval_policy = "untrusted" explícito ahora falla “with an actionable error” (con un error accionable).⁴ Reproducido en 0.149.1 el 25 de agosto de 2026: el arranque de una sesión se detiene con Error: approval_policy = "untrusted" is no longer supported; remove this setting, ya sea que el valor esté en config.toml, en un archivo de perfil o en una anulación con -c, y el binario codex rechaza -a untrusted al analizar los argumentos.⁵ Cambia el valor a on-request y deja el modo de sandbox como está; para la configuración más cautelosa, combina --sandbox read-only con on-request.³ El conjunto actual de políticas es on-request, never y la forma de tabla granular.² Vigente a partir de v0.149.1 (24 de agosto de 2026, UTC), el latest de npm.¹ {.answer-block}

TL;DR

• El cambio: el changelog completo de v0.149.0 lista el PR #39630, “Retire the untrusted approval policy”. Las notas de la versión no ofrecen texto de migración más allá de ese título;¹ la descripción del PR sí: untrusted desapareció de la CLI, del esquema de configuración y de la interfaz de herramientas MCP, y las configuraciones explícitas “now fail with an actionable error” (ahora fallan con un error accionable).⁴
• Quién debe actuar: cualquiera que tenga approval_policy = "untrusted" en ~/.codex/config.toml o en un perfil, y cualquiera que pase --ask-for-approval untrusted (o -a untrusted) en scripts, alias o CI.
• El reemplazo: on-request, con el modo de sandbox sin cambios. read-only más on-request es el par que la documentación llama “Safe read-only browsing” (navegación segura de solo lectura).² La antigua combinación de workspace-write más untrusted no tiene sucesor directo; la solicitud de aprobación comando por comando vive ahora en las reglas de exec policy.⁴⁸
• El conjunto actual: on-request, never o approval_policy = { granular = { ... } } para control por categoría. Los modos de sandbox siguen siendo read-only, workspace-write y danger-full-access.²
• Falla rápido, no en silencio: un approval_policy = "untrusted" olvidado detiene la sesión con Error: approval_policy = "untrusted" is no longer supported; remove this setting, esté en config.toml, en un archivo de perfil o en una anulación con -c. codex doctor solo informa que la configuración no se pudo cargar, sin nombrar la clave.⁵

¿Qué cambió en Codex 0.149?

Los elementos destacados son superficies nuevas, entre ellas el panel codex agents, codex queue y un codex doctor más amplio; el cambio en las aprobaciones queda más abajo, en el changelog completo.¹ La descripción del PR #39630 contiene el detalle que las notas de la versión omiten. Dos de sus tres puntos importan aquí: “Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.” (eliminar untrusted de la CLI, del esquema de configuración y de la interfaz de herramientas MCP; las configuraciones explícitas ahora fallan con un error accionable) y “Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.” (eliminar la lista de comandos conocidos como seguros; los proyectos marcados como untrusted ahora piden aprobación para cada comando salvo que una regla explícita de exec policy lo permita).⁴ Una corrección de errores de la misma versión importa para los mismos lectores: “Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.” (los hilos reanudados y bifurcados ahora restauran su perfil de permisos activo en lugar de volver en silencio a los valores predeterminados actuales).¹

Cada fila cita las notas de la versión v0.149.0.¹

¿Quién necesita editar algo?

Cuatro lugares llevan el valor. Encuéntralos todos primero, porque un perfil o un alias de shell reafirma la política antigua después de que corrijas el archivo principal.

El fallo de la tabla heredada es ruidoso. En 0.149.1, codex exec --profile safe "hi" con una tabla [profiles.safe] todavía en config.toml se detiene con Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ..., de modo que el --profile safe de un compañero falla antes de que Codex lea el valor de aprobación.⁵

Un grep por cada lado:

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

El primer grep busca la clave y no la palabra suelta por una razón. trust_level = "untrusted" es un ajuste distinto; déjalo en paz. La referencia de configuración define projects.<path>.trust_level como la clave que marca “a project or worktree as trusted or untrusted” (un proyecto o worktree como confiable o no confiable), y los proyectos no confiables “skip project-scoped .codex/ layers, including project-local config, hooks, and rules” (omiten las capas .codex/ con alcance de proyecto, incluidos la configuración local del proyecto, los hooks y las reglas).⁷ El PR #39630 cambia lo que un proyecto no confiable hace con los comandos, no la clave: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Un buscar y reemplazar a ciegas de untrusted corrompe esa clave.

Los archivos de perfil son el mecanismo documentado de preajustes (~/.codex/<name>.config.toml, seleccionados con codex --profile <name>), así que el perfil de un compañero puede reintroducir el valor retirado sin importar lo que diga la configuración principal.²

¿Cuál es el conjunto actual de políticas de aprobación?

La seguridad de Codex proviene de dos capas: el modo de sandbox decide qué puede hacer Codex técnicamente, y la política de aprobación decide cuándo Codex debe detenerse y preguntar.² El retiro toca solo la segunda.

La forma granular cubre cinco categorías de solicitudes: sandbox_approval, rules (solicitudes de execpolicy), mcp_elicitations, request_permissions y skill_approval.² Ninguna reproduce untrusted, que era una regla de clasificación de comandos (ejecutar automáticamente las lecturas conocidas como seguras, preguntar ante cualquier cosa que pudiera mutar el estado) y no un filtro por categoría de solicitud.²

workspace-write más untrusted, la fila que la documentación llama “Automatically edit but ask for approval to run untrusted commands” (editar automáticamente pero pedir aprobación para ejecutar comandos no confiables), no tiene sucesor directo.² workspace-write más on-request deja de preguntar por los comandos que corren dentro del sandbox; read-only más on-request pregunta tanto por las ediciones como por los comandos.² El PR #39630 eliminó “the known-safe command allowlist” (la lista de comandos conocidos como seguros) y nombra el mecanismo que sobrevive para la solicitud comando por comando: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Las reglas de exec policy son el mismo mecanismo detrás de la categoría rules de la tabla granular, las “execpolicy-rule prompts” que enumera la página de aprobaciones.² Los responsables de seguridad que dependían de untrusted para un workspace con escritura deberían construir esas reglas. La documentación de reglas las limita a los comandos que se ejecutan fuera del sandbox; una prefix_rule con decision = "prompt" pregunta “before each matching invocation” (antes de cada invocación que coincida):⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

El sandbox de solo lectura sigue siendo la alternativa contundente que bloquea la mutación de plano.³

¿Cuáles son las ediciones exactas?

La correspondencia es de una sola línea: untrusted se convierte en on-request, y el modo de sandbox se queda como estaba.³

Configuración principal (un archivo de perfil recibe la edición idéntica):

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

Un script:

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

El par -a/--ask-for-approval pertenece al binario TUI codex. codex exec no tiene esa bandera: en 0.149.1, codex exec --ask-for-approval untrusted "hi" falla con error: unexpected argument '--ask-for-approval' found.⁵ Para codex exec, fija la política en la configuración o pásala en línea:

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

Siguen dos decisiones de criterio. Primero, donde nadie puede responder una solicitud, el binario interactivo codex bajo on-request se queda atascado en la primera aprobación; el par no interactivo documentado es --sandbox read-only --ask-for-approval never, y codex exec --sandbox workspace-write es el punto de entrada no interactivo documentado.² Segundo, si combinabas untrusted con danger-full-access para tener “toda la potencia, pero preguntando cada vez”, esa propiedad no sobrevive al cambio. Los dos ejemplos que da la documentación de una solicitud bajo on-request son salir del sandbox y usar la red, y danger-full-access elimina ambos disparadores.² Las solicitudes de las otras cuatro categorías de la tabla granular siguen activándose con acceso completo: reglas de exec policy con decision = "prompt", elicitaciones MCP, aprobaciones de skills y solicitudes de request_permissions.²⁸ El ajuste opcional approvals_reviewer = "auto_review" enruta las solicitudes elegibles a través de un agente revisor; solo aplica a políticas interactivas, así que sigue disponible después de la migración.²

¿Cómo verifico que el cambio surtió efecto?

1. Ejecuta codex doctor. Con el valor retirado todavía en la configuración, su línea de config empieza con ✗ config config could not be loaded y la línea de detalle dice · failed to load Codex config; doctor no nombra la clave culpable. El error con nombre viene de lanzar codex o codex exec. Una línea limpia de doctor significa que el valor desapareció; una fallida significa que todavía tienes que lanzar una sesión para ver qué clave es.⁵ El error de arranque es idéntico ya sea que el valor esté en config.toml, en un archivo de perfil seleccionado con --profile o en una anulación -c approval_policy=untrusted.⁵ La forma de bandera falla antes, al analizar los argumentos: codex -a untrusted --version imprime error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>' seguido de [possible values: on-request, never].⁵
2. Inicia una sesión desechable en un directorio temporal y ejecuta /status. Su línea Permissions muestra la política activa, y on-request aparece allí como “Ask for approval”.⁵ /permissions abre el menú de preajustes en lugar de informar el modo activo, así que lee /status en su lugar.⁵ /status también lista los directorios del workspace.²
3. Reanuda un hilo antiguo. El PR #39153, “Restore permission profiles when resuming threads” (restaurar los perfiles de permisos al reanudar hilos), ahora restaura “the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread” (la última política de aprobación persistida, el revisor de aprobaciones y el ID del perfil de permisos activo al reanudar o bifurcar un hilo).⁶ Un hilo reanudado cuya política persistida sea untrusted sigue sin probarse; trata ese caso como desconocido hasta que abras uno.

Una advertencia sobre la propia documentación. La página oficial “Agent approvals & security”, tal como se capturó el 24 de agosto y se volvió a revisar el 25 de agosto de 2026, todavía muestra --ask-for-approval untrusted en su tabla de combinaciones, todavía conserva el párrafo que empieza “With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically” (con --ask-for-approval untrusted, Codex ejecuta automáticamente solo operaciones de lectura conocidas como seguras), y todavía usa approval_policy = "untrusted" en su ejemplo de config.toml.² La entrada approval_policy de la referencia de configuración lista untrusted primero en su unión de tipos mientras su descripción marca como retirado un valor distinto: “on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.” (on-failure está obsoleto; usa on-request para ejecuciones interactivas o never para ejecuciones no interactivas).⁷ El PR y el binario son el registro autoritativo; la documentación va por detrás. No copies el bloque de ejemplo de la documentación en una instalación nueva de 0.149 sin cambiar el valor.

Preguntas frecuentes

¿Qué reemplaza a approval_policy = "untrusted" en Codex?

approval_policy = "on-request", con tu sandbox_mode existente sin cambios. Para la combinación más cautelosa, fija sandbox_mode = "read-only" junto a él.³

¿Qué versión de Codex retiró la política untrusted?

v0.149.0, estable desde el 20 de agosto de 2026, mediante el PR #39630 en el changelog completo. v0.149.1 (24 de agosto de 2026, UTC) es el latest actual de npm.¹

¿Qué pasa si dejo untrusted en config.toml?

Codex se niega a iniciar la sesión. En 0.149.1, codex exec se detiene con Error: approval_policy = "untrusted" is no longer supported; remove this setting, el mismo error aparece para un archivo de perfil y para -c approval_policy=untrusted, y codex doctor solo informa que la configuración no se pudo cargar.⁵ El PR #39630 describe el comportamiento como fallar “with an actionable error” (con un error accionable).⁴

¿Es on-request menos seguro de lo que era untrusted?

Dentro de workspace-write, sí: untrusted preguntaba antes de cualquier comando que pudiera mutar el estado, y on-request ejecuta los comandos dentro del sandbox sin preguntar.² La capa de sandbox recupera parte del margen: read-only bloquea las escrituras sin importar la política, y on-request sigue preguntando antes de cualquier escalada.³ Para la solicitud comando por comando en un workspace con escritura, escribe reglas de exec policy, el mecanismo que nombra el PR #39630.⁴⁸

¿Necesito cambiar también mi modo de sandbox?

No. El retiro afecta solo a la política de aprobación; conserva read-only, workspace-write o danger-full-access tal como lo tenías.³

Conclusiones clave

Para desarrolladores individuales: - Haz grep en ~/.codex/*.toml buscando approval_policy = "untrusted" (no la palabra suelta), reemplaza cada coincidencia con on-request, y deja en paz sandbox_mode y cualquier trust_level = "untrusted". - Ejecuta codex doctor, luego /status en una sesión temporal, y reanuda un hilo antiguo para ver qué restaura 0.149.

Para equipos que mantienen perfiles y scripts compartidos: - Corrige los archivos de perfil y las anulaciones en línea en el mismo commit que config.toml; una tabla heredada [profiles.<name>] bloquea --profile por completo hasta que la muevas a ~/.codex/<name>.config.toml.⁵ - Convierte los trabajos desatendidos a --sandbox read-only --ask-for-approval never en el binario codex, o a codex exec --sandbox workspace-write -c approval_policy=never; el binario interactivo codex bajo on-request se bloquea en una solicitud que nadie responderá, y codex exec no tiene la bandera --ask-for-approval.⁵

Para responsables de seguridad: - El clasificador untrusted (ejecutar automáticamente lecturas seguras, preguntar ante mutaciones) no tiene equivalente granular; el PR #39630 apunta a las reglas de exec policy (“unless an explicit exec policy rule allows it”, salvo que una regla explícita de exec policy lo permita) para la solicitud comando por comando,⁴ escritas como una prefix_rule con decision = "prompt" en ~/.codex/rules/default.rules,⁸ y el sandbox de solo lectura bloquea la mutación de plano. - Considera approvals_reviewer = "auto_review" donde un agente revisor pueda sustituir a un humano en las solicitudes elegibles.

Referencias