Después de instalar Codex CLI, mi primer problema no fue un aviso de aprobación. Fue que npm install no funcionaba en Codex CLI.
Los archivos se editaban sin problema, pero la instalación de dependencias se quedaba parada. Durante un buen rato lo confundí con un problema del propio npm.
Voy directo a la conclusión. No conviene forzarlo con sudo.
Además, la aprobación y el sandbox son dos ejes completamente distintos. Si no los separas, la misma confusión vuelve una y otra vez: “Lo permití, ¿por qué no se ejecuta?”.
¿Por qué npm install no funciona en Codex CLI con workspace-write?
workspace-write permite escribir archivos, pero el acceso a la red es un ajuste aparte. Por eso un comando que necesita red, como npm install, puede bloquearse aunque las ediciones de archivos funcionen.
Al principio pensé que npm se estaba portando raro. Al fin y al cabo, los archivos de código se seguían editando con normalidad.
Ya con la instalación terminada, puse a Codex a hacer trabajo real. Los cambios de código pasaban bien.
Solo el paso de instalar dependencias se atascaba una y otra vez.
Durante un tiempo sospeché de mi configuración de npm. La causa real era la condición de acceso a la red del sandbox.
Desde entonces trato “¿puede escribir archivos?” y “¿puede usar la red?” como dos permisos totalmente separados.
Según la documentación oficial, workspace-write maneja la escritura en el sistema de archivos y el acceso a la red como límites distintos (Documentación de OpenAI: Sandbox).
Eso sí, no pude confirmar en la documentación el nombre exacto de la clave de configuración. Por eso aquí solo afirmo que el acceso a la red se controla con un ajuste aparte.
¿Conviene usar sudo si npm install -g da EACCES?
En mi caso, no: con sudo el paquete se instala de momento, pero después los permisos se enredan más. Lo que lo resolvió fue ordenar la ruta de instalación de Node y reinstalar desde un entorno de Node del usuario.
Este caso de EACCES fue un problema distinto, de los primeros momentos de la instalación.
En la misma máquina convivían el Node del sistema y un gestor de versiones de Node que había instalado aparte. Al instalar un paquete global de npm, apareció un problema de permisos.
Mi primera reacción fue sudo npm install -g .... Ahí me detuve, porque ya había pasado por eso antes.
Ordené la ruta de instalación de Node y reinstalé desde el entorno de Node del usuario. El problema desapareció.
Lo que saqué de ese ensayo y error: que aparezca EACCES no significa que haya que recurrir a sudo sin pensarlo.
Aprobación vs sandbox en Codex CLI: ¿qué cambia realmente?
approval_policy decide cuándo preguntar a una persona, y sandbox_mode decide hasta dónde puede ejecutar sin preguntar. Son dos ejes independientes, así que una aprobación permisiva no levanta el sandbox.
No conocía esta distinción desde el principio.
Por qué malinterpreté never como “permitir todo”
Al ver approval_policy = "never", lo primero que pensé fue simple: “Ahora todo se permitirá automáticamente”.
No funcionó así. Incluso con never, las acciones fuera del sandbox siguieron restringidas.
La documentación oficial dice lo mismo. --ask-for-approval never está diseñado para funcionar con todos los modos de --sandbox.
Según la documentación, las restricciones del sandbox se mantienen sea cual sea el ajuste de aprobación (Documentación de OpenAI: Agent approvals & security).
Qué vigilar a septiembre de 2026
Todo lo de este artículo lo comprobé en septiembre de 2026. Codex CLI tiene un historial de cambiar nombres de flags y valores de configuración entre versiones.
Si copias opciones de un tutorial antiguo, puede que no coincidan con la última versión.
Por ejemplo, approval_policy = "untrusted" se retiró con un PR fusionado en agosto de 2026. Desde la 0.149.0, si el archivo de configuración aún tiene ese valor, Codex ni siquiera arranca y da un error (openai/codex PR #39630).
Los valores de approval_policy que indica la documentación oficial son on-request, never y el más detallado granular. Un valor llamado “unless-trusted”, aunque se menciona a menudo, no lo pude confirmar.
Por eso, cada vez que vuelvo a tocar config.toml, me parece más seguro abrir antes la ayuda de la CLI y la referencia oficial de configuración.
workspace-write vs danger-full-access: ¿cuánto tiempo cuestan las aprobaciones?
Repetí la misma refactorización 5 veces en un repositorio personal/POC en macOS con Apple Silicon. workspace-write + on-request tardó 14–16 minutos y danger-full-access en un entorno aislado, 11–13 minutos (medición propia, no una cifra general).
Solo cambié dos condiciones.
| Condición | Tiempo (rango del promedio de 5 ejecuciones) | Intervenciones de aprobación |
|---|---|---|
| workspace-write + on-request | 14–16 min | 2–4 |
| danger-full-access (entorno aislado) | 11–13 min | Ninguna (sin avisos de aprobación) |
¿De dónde salieron las 2–4 aprobaciones?
Con workspace-write + on-request, cada ejecución tenía por lo general unas 2–4 intervenciones de permisos. Editar archivos dentro del workspace y las pruebas normales avanzaban casi sin pausa.
La mayoría de las pausas llegaban en momentos parecidos: cuando algo necesitaba acceso a la red o tocar un archivo fuera del workspace.
14–16 min frente a 11–13 min, y por qué no lo generalizo
Con danger-full-access en un entorno aislado, el tiempo detenido por aprobaciones casi desaparece (ver la tabla).
No lo voy a convertir en “danger-full-access es un 20% más rápido” como cifra general. La diferencia real dependía mucho de cuánto acceso fuera del sandbox necesitaba la tarea.
Tampoco lo medí con marcas de tiempo precisas. Son cinco ejecuciones personales, nada más.
¿En qué entornos uso danger-full-access?
Mi criterio es usarlo solo en entornos que se puedan desechar enteros, como Docker, una VM desechable o un worktree aparte. read-only, el modo más conservador, ni siquiera permite escribir, así que queda fuera de esta comparación.
La documentación oficial describe danger-full-access como un modo que elimina por completo los límites del sistema de archivos y de la red (Documentación de OpenAI: Sandbox).
--dangerously-bypass-approvals-and-sandbox (alias --yolo) no aparece como “EXTREMELY DANGEROUS” en la documentación. Su etiqueta es [Elevated Risk] No sandbox; no approvals (not recommended), con un aviso de usarlo con cuidado (Documentación de OpenAI: Agent approvals & security).
--sandbox/-s y --profile figuran en la documentación. Para --worktree y --approve-for-me no encontré respaldo en lo que revisé, así que no los trato aquí.
Repositorio personal, POC en el trabajo y experimentos de automatización
En la práctica separo tres entornos. En un repositorio personal, uso workspace-write + on-request en el host macOS.
En una POC en el trabajo, me quedo sobre todo en workspace-write, en un repositorio de desarrollo. Mantengo el acceso a credenciales y a producción aparte, en herramientas y entornos distintos.
Solo los experimentos de automatización de bajo riesgo reciben permisos más amplios, en Docker o un worktree desechable.
Mi valor por defecto es siempre workspace-write.
No decido por velocidad. Me pregunto: “Si este agente ejecuta algo mal, ¿está bien que el daño llegue fuera del workspace?”.
En la mayoría de los casos, la respuesta es no. En mis repositorios de desarrollo habituales en el host, no dejo una opción de bypass por defecto solo porque sea cómoda.
Pocos perfiles, los justos
Prefiero no tener demasiados perfiles. Dejo la configuración por defecto conservadora y aparte mantengo un solo perfil, más o menos, para entornos aislados.
Codex CLI vs Antigravity CLI: ¿cuál pidió menos aprobaciones?
En mi comparación personal, Codex con workspace-write + on-request se sintió con menos intervenciones que Antigravity, aunque puede variar según la herramienta y el momento. En la misma tarea, Antigravity tardó unos 18 minutos en modo de aprobación y unos 12 en avance automático.
| Herramienta / modo | Tiempo | Aprobaciones | Bloqueos |
|---|---|---|---|
| Antigravity CLI, modo de aprobación | ~18 min | 6–7 | 4 |
| Antigravity CLI, avance automático | ~12 min | – | – |
| Codex workspace-write + on-request | 14–16 min | 2–4 | – |
Comparado con mis pruebas de Antigravity, en Codex tuve menos la sensación de aprobar uno por uno hasta los comandos normales del workspace.
Para el uso diario de un agente de programación, esta combinación me resultó más cómoda.
En ambos casos juzgué con el mismo criterio: el blast radius (hasta dónde llega el daño) y la reversibilidad.
Algo sí fue igual. Si no se distinguen sandbox y aprobación, cualquier herramienta confunde de la misma manera.
Qué combinación de Codex equivale exactamente a --dangerously-skip-permissions de Claude Code es algo que no trato a fondo en este artículo.
Para mí, el sandbox no es por desconfiar del agente
Por muy buenos que sean los modelos, quedan rutas de fallo ajenas a su razonamiento. Hablo de comandos de shell, scripts de paquetes, una ruta equivocada o una limpieza de pruebas inesperada.
Mi valor por defecto es encerrar el blast radius de un error dentro del workspace, no ahorrar unos cuantos clics de aprobación.
Referencias
- Documentación de OpenAI: Sandbox: cómo los modos del sandbox separan los límites del sistema de archivos y de la red, y cómo danger-full-access los elimina
- Documentación de OpenAI: Agent approvals & security: independencia de approval_policy y sandbox_mode, etiqueta de advertencia del flag de bypass y flags de la CLI
- openai/codex PR #39630: Retire the untrusted approval policy: retirada de
approval_policy = "untrusted"y error de arranque desde la 0.149.0
Este artículo fue localizado a partir del original en coreano: https://jjeongil.tistory.com/3566.