Codex CLI — Permisos, sandbox y aprobaciones · Agentes de IA para programar

El modelo de seguridad de Codex tiene dos mandos: el sandbox (qué pueden tocar los comandos, impuesto por el sistema operativo) y la política de aprobación (cuándo se para Codex a preguntarte). Se configuran con --sandbox/-s y --ask-for-approval/-a, con sandbox_mode/approval_policy en config.toml, o a mitad de sesión con /permissions.

Políticas de aprobación

Política	Comportamiento
`untrusted`	Sólo se ejecutan solas las operaciones de lectura consideradas seguras; todo lo que muta o sale al exterior requiere aprobación
`on-request`	Codex pregunta cuando necesita salirse del sandbox (es el valor del preset interactivo Auto)
`never`	No pregunta nunca; hace lo que puede dentro de los límites del sandbox — la opción correcta para ejecuciones no interactivas
`{ granular = {...} }`	Permitir o rechazar automáticamente por categoría: `sandbox_approval`, `rules`, `mcp_elicitations`, `request_permissions`, `skill_approval`

on-failure está obsoleto — usa on-request en sesiones interactivas o never en las no interactivas.

Con approvals_reviewer = "auto_review" las peticiones de aprobación que apliquen pasan por un agente revisor automático en lugar de por ti.

Modos de sandbox

Modo	Qué puede hacer Codex
`read-only`	Leer archivos y responder preguntas; las ediciones, los comandos y la red requieren aprobación
`workspace-write`	Leer, editar y ejecutar dentro del workspace; la red está apagada por defecto (`sandbox_workspace_write.network_access = true` para activarla); fuera del workspace hace falta aprobación
`danger-full-access`	Sin sandbox de sistema de archivos ni de red — sólo para entornos controlados

Rutas protegidas

Incluso en workspace-write, estas siguen siendo de solo lectura: <raíz>/.git (incluido el gitdir resuelto), <raíz>/.agents y <raíz>/.codex (de forma recursiva). Por eso git commit puede seguir pidiendo aprobación en un workspace por lo demás escribible.

Presets y combinaciones verificadas

Objetivo	Comando
Preset Auto (recomendado en carpetas con control de versiones)	`codex --sandbox workspace-write --ask-for-approval on-request`
Exploración en solo lectura	`codex --sandbox read-only --ask-for-approval on-request`
Solo lectura en CI	`codex exec --sandbox read-only --ask-for-approval never "..."`
Editar archivos pero aprobar los comandos no confiables	`codex --sandbox workspace-write --ask-for-approval untrusted`
Aprobaciones con revisión automática	añade `-c approvals_reviewer=auto_review`

Valores por defecto al arrancar: las carpetas con control de versiones arrancan con el preset Auto recomendado; las que no lo tienen arrancan en read-only; y Codex puede arrancar en solo lectura hasta que el directorio se marque como de confianza. /permissions cambia el modo a mitad de sesión; /status muestra las raíces con permiso de escritura.

El flag --full-auto de codex exec es un alias de compatibilidad obsoleto — muestra un aviso; usa --sandbox workspace-write en su lugar.

AVISO: --dangerously-bypass-approvals-and-sandbox (alias --yolo) desactiva todas las aprobaciones y el sandbox entero. Cada comando que genere el modelo se ejecuta con todos tus privilegios de usuario. La documentación oficial lo marca como “riesgo elevado, no recomendado” y dice que se use sólo dentro de un entorno endurecido por fuera (una VM dedicada como sandbox o un contenedor bien cerrado). Que no sea nunca tu forma habitual de trabajar. Efecto secundario: con acceso total, la búsqueda web pasa a live por defecto. Si necesitas más margen, usa --add-dir antes que danger-full-access, y workspace-write para el trabajo local desatendido.

Notas por plataforma

macOS: Seatbelt vía sandbox-exec, con un perfil acorde al modo; se le añade una política de plataforma curada para compatibilidad con las herramientas.
Linux: bwrap (bubblewrap) + seccomp por defecto. Ojo a una incoherencia en la documentación oficial: las páginas generales hablan de bwrap + seccomp, mientras que el ayudante codex sandbox linux se describe corriendo bajo “Landlock + seccomp” — la documentación ya no presenta Landlock como el mecanismo principal del sandbox del agente, así que la pila exacta no queda del todo clara. WSL1 no está soportado desde la 0.115 (cuando el sandbox de Linux pasó a bwrap); WSL2 sí funciona.
Windows: sandbox nativo de Windows ([windows] sandbox = "elevated" | "unelevated", sandbox_private_desktop), o el sandbox de Linux bajo WSL2. Ajuste de la extensión del IDE: chatgpt.runCodexInWindowsSubsystemForLinux.
Contenedores: si el entorno bloquea bwrap/seccomp, pon el aislamiento por fuera (un devcontainer) y ejecuta --sandbox danger-full-access dentro; la documentación incluye una referencia de devcontainer seguro con lista blanca de firewall y avisos sobre exfiltración de credenciales.

Para probar el sandbox en local:

codex sandbox macos|linux|windows [--permission-profile NOMBRE] [-- COMANDO...]

(Alias: codex debug, codex sandbox seatbelt, codex sandbox landlock.)

Control fino: reglas de execpolicy (experimental)

Los archivos .rules (en Starlark) viven en una carpeta rules/ junto a una capa de configuración activa — por ejemplo ~/.codex/rules/default.rules o <repo>/.codex/rules/ en proyectos de confianza:

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    justification = "Hacer push requiere confirmación humana",
)

Las decisiones son allow, prompt o forbidden, y gana siempre la más restrictiva (forbidden > prompt > allow). Las cadenas de shell con operadores seguros se analizan con tree-sitter y se parten comando a comando; los scripts complejos se evalúan como una única invocación bash -lc. Puedes probar las reglas con codex execpolicy check --rules <archivo> -- <cmd>. Elegir “permitir siempre” en la TUI escribe en ~/.codex/rules/default.rules.

Política de red

El acceso a red de los comandos está apagado por defecto. Se activa por modo (sandbox_workspace_write.network_access) y se le imponen reglas de dominio con el experimental features.network_proxy: reglas orientadas a lista blanca (*.example.com sólo para subdominios, **.example.com para el dominio y sus subdominios, * global; deny siempre gana), allow_local_binding = false bloquea loopback y redes privadas por defecto, soporte de SOCKS5 y las vías de escape dangerously_allow_non_loopback_proxy y dangerously_allow_all_unix_sockets. El proxy no filtra la búsqueda web, las apps/conectores, MCP, el navegador ni el tráfico del modelo y la autenticación.

La búsqueda web es un mando aparte: web_search = "cached" (por defecto, índice mantenido por OpenAI), "indexed", "live" o "disabled".

Última verificación: 2026-09-07

Fuentes oficiales:

Las herramientas de IA para programar evolucionan rápido. Si encuentras información desactualizada, abre un issue o un pull request.