Permisos, sandbox y aprobaciones: qué tan flexible o estricto configurarlo, tú decides

📚 Navegación de la serie: El artículo anterior 14 · Flujos de trabajo comunes integró a Codex en tu ritmo de desarrollo diario. Este artículo cambia de dimensión: no controla "cómo trabaja", sino "qué tanto se atreve a modificar": desde preguntarte por cada línea de comando hasta darle total libertad automática. Aclararemos en este artículo cómo ajustar estos dos interruptores de sandbox y aprobación, y qué nivel elegir para cada escenario.

Permítanme contarles una tontería que hice el invierno pasado. En ese momento, cuando apenas me estaba acostumbrando a configurar Codex, para ahorrar tiempo en ~/.codex/config.toml definí permanentemente sandbox_mode como danger-full-access, bajo el argumento de que "las ventanas emergentes son molestas". El resultado fue que un día, en un directorio temporal que no estaba inicializado con Git, le pedí que "limpiara los archivos inútiles", y realmente comenzó a rebuscar en todo mi directorio principal, ya que en el modo de acceso completo no hay un límite de "espacio de trabajo" que lo contenga. Presioné apresuradamente Esc para interrumpirlo, y en ese instante se me heló la sangre.

Al analizarlo después, el problema no fue de Codex, sino mío: escribí como valor predeterminado global una configuración peligrosa que solo debe usarse en contenedores aislados. El programa no falló por su cuenta; fui yo quien soltó las riendas donde no debía.

En el artículo 02 ya explicamos a fondo los conceptos de sandbox y aprobación utilizando las analogías de "la valla del parque infantil" y "el control de acceso + guardia de seguridad"; este artículo no repetirá las definiciones, sino que se centrará en una sola tarea: enseñarte paso a paso cómo configurarlos y elegirlos. Qué nivel combina con cuál, cómo modificarlos temporalmente desde la consola, cómo guardarlos de forma permanente en el archivo de configuración y dónde se traza la línea roja para el modo de peligro.

Al terminar este artículo, obtendrás:

• Cómo combinar dos a dos las tres modos de sandbox (read-only / workspace-write / danger-full-access) y las tres estrategias de aprobación (untrusted / on-request / never), con una tabla de referencia.
• Plantillas para ajustar temporalmente desde la consola con --sandbox / --ask-for-approval o definirlos de forma fija en config.toml como valores predeterminados.
• Qué nivel te asigna Codex por defecto al iniciarse (lo cual depende de si la carpeta tiene Git o no) y por qué.
• Los valores predeterminados con los que es fácil cometer errores de suposición: el acceso a la red está desactivado y .git está protegido como solo lectura en el modo workspace-write.
• Dónde se traza exactamente la línea roja de --yolo (libertad total) y por qué en tu máquina local y en producción queda totalmente descartado.

---

01 Aclarar primero: estás ajustando "dos interruptores independientes"

Dejemos muy claro el punto que suele causar más confusión: el sandbox y la aprobación no son dos niveles de una misma configuración, sino dos interruptores independientes que gestionan cosas distintas.

Ya usamos la analogía en el artículo 02; aquí solo añadimos cómo se traduce en la configuración: son dos claves separadas en config.toml y dos parámetros separados en la consola:

Interruptor	Qué gestiona	Clave en config	Parámetro de consola	Abreviatura
Modo de sandbox (sandbox mode, límites de acceso a red y archivos)	Qué tanto puede modificar	sandbox_mode	--sandbox	-s
Estrategia de aprobación (approval policy, si se detiene a pedir confirmación manual)	Si te pregunta o no	approval_policy	--ask-for-approval	-a

¿Por qué insistir en que son "independientes"? Porque el malentendido más común entre los principiantes es pensar "si activo el acceso completo, ya no saldrán ventanas emergentes"; no es así. El acceso completo (llevar al límite el interruptor del sandbox) y evitar las preguntas (llevar al límite el interruptor de la aprobación) son dos cosas distintas; puedes configurar perfectamente "acceso a toda la máquina pero preguntando en cada paso" o "solo lectura trabajando de forma silenciosa". El efecto combinado de ambos define la flexibilidad o restricción real que percibirás.

Analogía: Las "marchas" y el "límite de velocidad" al conducir. El sandbox es como la marcha que engranas: en la marcha P (read-only), el coche no se mueve; en la marcha D (workspace-write), puedes circular por la carretera; y en la marcha todo terreno (danger-full-access), puedes meterte incluso en zanjas. La aprobación es como la alerta de límite de velocidad que te fijas: puede configurarse para "sonar solo al exceder el límite" (on-request), "sonar ante cualquier desconocido" (untrusted) o "desactivar la alerta y conducir en silencio" (never). La marcha define a dónde puede ir el coche, y la alerta define cuándo avisarte; son dos sistemas que no se reemplazan mutuamente.

Veamos algunos escenarios que vivirás en la práctica para ayudarte a asimilar esta independencia:

• Quieres pedirle solo leer código y escribir un informe: ajusta el sandbox en read-only y la aprobación da igual; como no puede modificar nada, la presencia de alertas es irrelevante.
• Quieres dejarle modificar libremente dentro del proyecto, pero avisarte al salir de él: sandbox en workspace-write + aprobación en on-request; esta es la combinación de oro para el día a día.
• Vas a ejecutar tareas por lotes en un contenedor aislado y no quieres interrupciones: sandbox en danger-full-access + aprobación en never, llevando ambos interruptores al límite; pero esto debe hacerse únicamente en contenedores, como insistiremos a continuación.

💡 Resumen en una frase: El sandbox (--sandbox) controla "qué tanto puede modificar" y la aprobación (--ask-for-approval) controla "si te pregunta o no"; son dos interruptores independientes y claves separadas en la configuración; el nivel de control real es el resultado de la combinación de ambos.

Este diagrama organiza ambos interruptores en una tabla bidimensional: el eje horizontal representa el modo del sandbox (del estricto read-only al flexible danger-full-access), y el eje vertical representa la estrategia de aprobación (del cauto untrusted al silencioso never). Cada cruce representa una configuración real: la casilla con borde azul workspace-write + on-request es la combinación de oro para el día a día, y la casilla con borde rojo abajo a la derecha danger-full-access + never (es decir, --yolo) solo debe usarse en contenedores aislados.

---

02 Los tres modos de sandbox: qué tanto puede modificar se define aquí

El interruptor del sandbox cuenta con tres niveles definidos de forma muy directa; los resumimos en la siguiente tabla detallando si permite modificar archivos, conectarse a internet y para qué tareas es adecuado; esta es la tabla más importante que debes recordar en esta sección:

Modo de sandbox	¿Modifica archivos?	¿Permite conexión?	Adecuado para
read-only (solo lectura)	❌ No (requiere aprobación previa)	❌	Revisar código, proponer planes, planificar: "no toques mis cosas"
workspace-write (escribible en el espacio de trabajo)	✅ Solo dentro del espacio de trabajo	❌ Desactivado por defecto, requiere habilitación manual	Nivel por defecto para desarrollo diario, baja interrupción
danger-full-access (acceso completo)	✅ En toda la máquina	✅	Contenedores aislados o máquinas virtuales; el nombre danger no es para asustar

Detallemos algunos puntos clave donde es muy fácil cometer errores de suposición:

Primero: En el modo workspace-write, la conexión a internet viene desactivada por defecto. Esto es contraintuitivo: uno asume que "si puede escribir archivos, también debería poder conectarse para instalar dependencias", pero no es así. La documentación oficial lo detalla: por defecto, workspace-write restringe el acceso a la red, y si deseas abrirlo debes configurarlo manualmente. Para habilitar la red, añade este bloque en config.toml:

[sandbox_workspace_write]
network_access = true

La primera vez que pedí a Codex ejecutar npm install en el modo workspace-write, se quedó atascado arrojando varios errores de red; pensé que era un problema del proxy, y tras dar muchas vueltas recordé: el sandbox no le otorga permisos de red por defecto. Recordar esta regla te ahorrará mucho tiempo de depuración.

Segundo: El espacio de trabajo no es únicamente el "directorio actual". La documentación oficial aclara que el espacio de trabajo incluye automáticamente directorios temporales (como /tmp). Para ver qué directorios específicos forman parte de tu espacio de trabajo, escribe /status durante la sesión en lugar de adivinar. El resultado esperado es similar a:

Sandbox: workspace-write
Approval: on-request
Workspace directories:
  /Users/you/myproject
  /tmp

Las líneas Sandbox y Approval muestran los niveles activos; Workspace directories enumera los directorios donde puede escribir.

Tercero: Incluso al habilitar workspace-write, algunos directorios se mantienen en "protección de solo lectura". Esta es una red de seguridad que Codex configura deliberadamente: dentro del espacio de trabajo escribible, las siguientes rutas no se pueden modificar:

Ruta protegida	Motivo de la protección
<espacio_de_trabajo>/.git	Evita que altere el historial de Git por error o desordene el repositorio
<espacio_de_trabajo>/.agents	Evita que modifique en secreto la configuración de sus agentes
<espacio_de_trabajo>/.codex	Igual que la anterior, es el directorio de configuración propio de Codex

Además, esta protección es recursiva: todo el contenido dentro de estos directorios se hereda como solo lectura. Por lo tanto, no te preocupes de que "al abrir permisos de escritura pueda alterar tu carpeta .git", ya que Codex bloquea estas rutas sensibles por defecto.

Cuarto: El sandbox no solo limita las lecturas y escrituras del propio Codex, sino también las de los comandos derivados. Ya mencionamos esto en el artículo 02; volvemos a destacar su importancia práctica: incluso si Codex invoca comandos como git, npm o scripts de prueba, estos subcomandos se mantendrán dentro del mismo límite, de modo que no ocurrirá que "el proceso principal esté restringido y los subcomandos escapen para modificar otros directorios".

💡 Resumen en una frase: Entre los tres modos de sandbox, workspace-write es el predeterminado en el día a día, pero recuerda que la red está desactivada por defecto y .git / .agents / .codex se protegen como solo lectura; para habilitar la red activa manualmente network_access, y escribe /status para ver el alcance del espacio de trabajo.

---

03 Las tres estrategias de aprobación: si te pregunta o no se define aquí

El interruptor de aprobación también cuenta con tres niveles. Una vez definidos los límites del sandbox, si debe detenerse a preguntarte en los bordes es tarea de la aprobación:

Estrategia de aprobación	Comportamiento de Codex	Explicación sencilla
untrusted	Ejecuta de forma automática solo operaciones de lectura "conocidas como seguras", preguntando antes de ejecutar lo demás	Protege contra cualquier comando desconocido, es el nivel más cauto
on-request	Trabaja de forma autónoma dentro del sandbox por defecto, deteniéndose a preguntar solo si intenta salir de él	El nivel de equilibrio más habitual
never	Trabaja en silencio sin solicitar aprobaciones	Se usa frecuentemente en automatización; los permisos los sigue definiendo el sandbox, y solo tiene sentido real si se combina con acceso completo

Hay un detalle oficial que vale la pena destacar: untrusted no significa "solo lectura". Aún ejecutará de forma automática aquellas operaciones de lectura conocidas como seguras, pero requerirá tu confirmación para cualquier comando que "pueda modificar estados o activar ejecuciones externas" (como operaciones destructivas de Git o comandos con parámetros que sobrescriban configuraciones). Por tanto, la sensación al usar untrusted es de "lee con total libertad, pero detente al momento de actuar", siendo más granular y cauto que on-request.

También debes conocer un nivel avanzado: never se puede combinar con cualquier modo de sandbox. Muchos piensan que never (no preguntar) equivale a "libertad total", pero es un error. La documentación oficial aclara que --ask-for-approval never es compatible con todos los modos --sandbox: puedes configurar perfectamente read-only + never, lo que significa "permitir solo lectura y no hacerme ninguna pregunta en absoluto al leer"; esta es la configuración típica para análisis de solo lectura en la CI y es sumamente segura. "No preguntar" y "conceder permisos" son dos cosas distintas, confirmando nuevamente la noción de los "dos interruptores independientes" de la sección 01.

Respecto a "quién realiza la aprobación", el valor predeterminado es presentártelo a ti mismo (approvals_reviewer = "user"). La documentación oficial también ofrece la opción auto_review (revisión automática): permite que un agente revisor evalúe previamente las peticiones que requieren confirmación. Esta es una capacidad avanzada y en evolución, y en el artículo 16 · Límites de seguridad y riesgos desglosaremos su lógica de decisión y riesgos; por ahora basta con saber que existe este interruptor, y el valor user es suficiente en el día a día.

💡 Resumen en una frase: Entre las tres estrategias de aprobación, on-request es la predeterminada en el día a día; untrusted es más granular y cauta (permite leer libremente pero detiene ante modificaciones); never significa "no preguntar" y no "conceder permisos", pudiendo combinarse con cualquier modo de sandbox, como al usar read-only + never en análisis de solo lectura de la CI.

---

04 Cómo combinarlos: llamadas temporales en consola o definición fija en config.toml

Una vez conocidos los modos y estrategias, para configurarlos tienes dos opciones: realizar modificaciones temporales con parámetros en consola o definirlos de forma permanente en el archivo de configuración.

Modificación temporal: parámetros en consola (aplica solo para esta ejecución)

Al iniciar, introduce ambos parámetros para definir los niveles de la sesión. La combinación de bajo riesgo habitual sugerida oficialmente se estructura así:

codex --sandbox workspace-write --ask-for-approval on-request

Con los límites configurados y preguntando solo al salir de ellos, es una opción segura y no invasiva. Las abreviaturas son -s y -a:

codex -s read-only -a on-request "只帮我审一下这段代码，别动手"

¿Quieres cambiar de nivel una vez iniciada la sesión? No requieres salir, un comando de barra diagonal permite cambiar en el acto:

/permissions

Se despliega el selector para elegir el nivel de la sesión actual (Read Only / Auto / Full Access o similares), aplicándose de inmediato. Mi ritmo de trabajo real consiste en: al recibir un proyecto desconocido, uso /permissions para cambiar a solo lectura primero para que examine el código y proponga un plan; una vez revisado, cambio a workspace-write para trabajar; este hábito me ha salvado varias veces de que modifique sin control código que aún no he comprendido.

⚠️ El menú de la nueva versión podría diferir: a partir de codex-cli 0.142, se introdujo la función de permission profiles (Beta, sujeta a cambios) en reemplazo de los preajustes antiguos, por lo que tu opción /permissions podría mostrar niveles de estrategia de aprobación como Ask for approval / Approval for me / Full access, sin la presencia directa de Read Only. Para cambiar a solo lectura, hazlo mediante el parámetro de consola codex --sandbox read-only o definiendo sandbox_mode = "read-only" en ~/.codex/config.toml (se conserva el modo de sandbox antiguo como ruta de compatibilidad). Las menciones posteriores a cambiar a solo lectura mediante /permissions siguen esta misma indicación.

El siguiente diagrama detalla las dos etapas de "evaluar primero el sandbox y luego la aprobación":

Este diagrama ilustra: antes de cada paso, Codex evalúa primero "¿está dentro de los límites del sandbox?" (definido por el sandbox) y, si intenta salir, evalúa "¿debo detenerme a preguntar?" (definido por la aprobación); se recorren ambas etapas en orden y ambas son necesarias.

Definición fija: config.toml por defecto (aplica para cada inicio)

Para no tener que escribir los parámetros en cada ocasión, guarda la combinación habitual en el archivo de configuración para siempre. En ~/.codex/config.toml, añade estas dos líneas:

approval_policy = "on-request"
sandbox_mode    = "workspace-write"

想要「最谨慎」的兜底配法？官方给的「永远先问」组合是 approval_policy = "untrusted" 配 sandbox_mode = "read-only"，等于每次启动都从最严开始，需要放权时再手动切。生产项目、共享机器适合这么兜底。 ¿Quieres la combinación de seguridad más estricta? La combinación oficial de "preguntar siempre" es approval_policy = "untrusted" con sandbox_mode = "read-only", lo que significa iniciar con la mayor restricción y cambiar manualmente al requerir permisos. Es adecuada para proyectos de producción o máquinas compartidas.

Si cuentas con varias combinaciones habituales (por ejemplo, "una para el día a día y otra para la CI"), no modifiques el archivo de configuración constantemente; la herramienta admite perfiles de configuración (profile) para almacenar cada una en un archivo propio y seleccionarla con --profile:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Simplemente especifícala al iniciar:

codex --profile full_auto

⚠️ Recuerda que el profile (perfil de configuración) y el permission profile (perfil de permisos) que explicaremos en la sección 05 son dos cosas diferentes; se parecen en nombre pero no los confundas: el primero es la opción clásica de "agrupar y nombrar un conjunto de configuraciones", y el segundo es la mecanismo Beta más reciente diseñado para detallar los límites del sistema de archivos y de red. La combinación de sandbox_mode + approval_policy de esta sección es el método principal en la actualidad, así que domínalo primero.

---

05 Un paso más avanzado: rules para controlar comandos específicos y permission profiles para detallar límites (Beta)

La configuración de "modo de sandbox + estrategia de aprobación" de la sección 04 es un ajuste general para establecer el rumbo. Si deseas definir a nivel de detalle "este comando específico se permite siempre, y aquel se prohíbe permanentemente", Codex ofrece dos herramientas más precisas. Puedes omitirlas en tu primera lectura y volver cuando realmente lo necesites.

rules: definir reglas para comandos específicos (experimental)

⚠️ Experimental, sujeto a cambios. rules es una característica etiquetada como experimental.

El mecanismo real que usa Codex para "controlar comandos específicos con precisión" se llama rules (reglas); ten en cuenta que sus términos de decisión son allow / prompt / forbidden, y no ask / approve / deny como se menciona en algunos tutoriales; la sintaxis difiere, no los confundas.

El problema que resuelve: el sandbox ofrece límites amplios definidos por áreas, pero a veces necesitas un control preciso por prefijos de comando, del tipo "permitir ejecutar gh pr view directamente sin preguntar, incluso si sale del sandbox" o "prohibir el uso de grep para obligarte a usar rg". En estos casos, ampliar el sandbox completo sería desmedido, y escribir una regla de rule es la solución adecuada.

Las reglas se escriben en archivos .rules dentro de ~/.codex/rules/, utilizando una sintaxis similar a Python (en realidad es Starlark). Una regla se estructura de esta forma:

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "查看 PR 允许，但要我点头",
)

decision tiene tres opciones; sus significados y prioridades vienen definidos por defecto: gana el más estricto (forbidden > prompt > allow):

decision	Efecto
allow	Ejecuta directamente fuera del sandbox, sin preguntar
prompt	Pregunta cada vez que haya una coincidencia
forbidden	Bloquea de inmediato, sin preguntar ni ejecutar

Cuenta con un diseño de seguridad muy atento: ante comandos del tipo git add . && rm -rf / que agrupan varias instrucciones en una sola línea, Codex los dividirá para evaluarlos de forma individual garantizando la seguridad; incluso si permitiste (allow) git add, la instrucción rm -rf / se bloqueará por separado, impidiendo que pase de contrabando. Tras modificar las reglas, usa codex execpolicy check con un comando de prueba para verificar cómo se evaluará, antes de usarlo en la práctica.

permission profiles: agrupar los límites de red y del sistema de archivos en un profile (Beta)

⚠️ Beta, sujeto a cambios, y "no compatible" con la configuración de sandbox antigua. Esto lo recalca la documentación oficial: si algún archivo de configuración contiene sandbox_mode o introduces --sandbox, Codex seguirá usando el sistema de sandbox antiguo e ignorará los permission profiles. Son dos sistemas excluyentes, no los configures al mismo tiempo.

Si consideras que "workspace-write no es lo bastante detallado y quiero especificar qué directorios son escribibles, qué archivos .env bloquear obligatoriamente o a qué dominios acceder", los permission profiles (perfiles de permisos) son para eso. Agrupan las reglas del sistema de archivos y las reglas de red en un profile nombrado, usando default_permissions para definir cuál usar por defecto.

Se incluye tres perfiles integrados de forma oficial, con nombres descriptivos (nota que llevan un prefijo de dos puntos):

Profile integrado	Función
:read-only	Mantiene los comandos locales como solo lectura
:workspace	Permite escribir en la raíz del espacio de trabajo y en los directorios temporales del sistema
:danger-full-access	Elimina las restricciones del sandbox local, para usarse solo al requerir permisos amplios de verdad

Un ejemplo personalizado se estructura así (definiendo el sistema de archivos como escribible en el espacio de trabajo pero bloqueando todo archivo .env):

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

El sistema de archivos cuenta con tres permisos read / write / deny; sus prioridades siguen la misma lógica que las rules: deny tiene la mayor prioridad (deny > write > read), y las rutas más específicas tienen preferencia. La ventaja de este diseño es: puedes configurar "todo el espacio de trabajo como escribible, pero excluir y bloquear específicamente los archivos .env", combinando lo general y lo detallado en una sola línea de configuración. La red también se rige por una lista blanca previa: si no defines allow, no se permitirá ningún dominio, y deny siempre tiene prioridad sobre allow.

Mi recomendación directa: si eres principiante, no utilices los profiles y quédate con el método principal de la sección 04 para trastear en el día a día. Cuando tengas la necesidad real de bloquear un archivo sensible o dominios específicos, vuelve a revisarlos; y recuerda limpiar sandbox_mode de la configuración antes de cambiar de sistema, ya que son incompatibles.

💡 Resumen en una frase: El sistema rules controla por prefijos de comando (allow/prompt/forbidden, ganando el más estricto) y los permission profiles (Beta) delimitan por rutas y dominios (deny prioritario); ambos son niveles avanzados: usa el sistema principal si eres principiante y recurre a ellos solo con necesidades estrictas, teniendo en cuenta que no son compatibles con el sandbox antiguo.

---

06 Valores por defecto al iniciar + línea roja del modo de peligro

Una vez explicados los mecanismos, para saber qué nivel elegir, debes conocer un detalle: al iniciar, Codex ya ha seleccionado un nivel por defecto de forma inteligente por ti, y esta elección depende de si la carpeta cuenta con Git o no.

Qué nivel te asigna Codex por defecto

La lógica oficial es inteligente: al iniciar, revisa si el directorio está bajo control de versiones (si tiene Git) para sugerir distintos niveles predeterminados:

Carpeta desde donde inicias Codex	Recomendación por defecto
Bajo control de Git (version-controlled)	Nivel Auto (workspace-write + on-request)
Sin Git (non-version-controlled)	read-only (solo lectura)

Este diseño da en el clavo: al contar con el respaldo de Git, si el modelo daña algo puedes revisarlo con git diff o hacer rollback, por lo que permite escribir en el espacio de trabajo; en cambio, los directorios sin Git modifican los archivos sin opción a deshacer cambios, de modo que el valor predeterminado es de solo lectura para garantizar la seguridad. Al recordar la historia del inicio, usé el acceso completo precisamente en un directorio temporal sin Git, lo que equivalía a desactivar yo mismo las dos capas de seguridad que Codex me ofreció; era inevitable que fallara.

Además, hay otro detalle: en ciertos casos Codex iniciará en el modo read-only hasta que indiques explícitamente que "confías" en este directorio de trabajo (ya sea en la guía inicial o mediante /permissions). Si al principio notas que actúa con timidez y solo lee, no te asustes: simplemente está esperando tu confirmación para confiar en el directorio, no es que no funcione.

También vale la pena recordar un valor predeterminado respecto a la conexión a internet: la búsqueda web (web search) funciona por defecto con caché (cached), no mediante extracción en tiempo real. Se mantiene un conjunto de resultados preindexados oficiales, y el modo de caché devuelve esta información en lugar de cargar páginas web en vivo. Su ventaja es reducir el riesgo de ataques por inyección de prompts ocultos en páginas reales. Ten en cuenta un punto contraintuitivo: si habilitas el acceso completo (el sistema --yolo), la búsqueda web cambiará por defecto a tiempo real (live). Para forzar la búsqueda en tiempo real usa --search, o para desactivarla por completo configura web_search = "disabled"; las consideraciones de seguridad sobre este aspecto las detallaremos en el artículo 16 · Límites de seguridad y riesgos.

--yolo: la línea roja de la libertad completa

Por último, tenemos esa línea roja que protagonizó mi caída al principio: la libertad completa. En Codex existen dos formas equivalentes para definirla:

• A nivel de configuración: sandbox_mode = "danger-full-access" combinado con approval_policy = "never"
• En consola directamente: --dangerously-bypass-approvals-and-sandbox (el alias corto --yolo, you only live once)

El nombre --yolo deja muy en claro que no debe usarse a la ligera. Desactiva tanto el sandbox como la aprobación, otorgando a Codex libertad total en tu máquina sin hacer ninguna pregunta. Revisa en esta tabla si debes activarlo o no:

Escenario	¿Habilitar --yolo / acceso completo?
Contenedores aislados / Máquinas virtuales / dev containers	✅ Sí, ya que se destruiría un entorno desecheable
Ejecución de tareas temporales en la CI (dentro de contenedores)	✅ Sí, siempre que el entorno de por sí sea aislado
Tu propia máquina local para desarrollo diario	❌ No, es preferible la demora antes que desactivar la aprobación
Máquinas con código de producción o datos corporativos importantes	❌ Rotundamente no, es una bomba de tiempo

La postura oficial al respecto es muy clara: el acceso completo figura como (not recommended) (no recomendado). Si tu máquina física no puede ejecutar el sandbox de Linux o si tu empresa usa desarrollo basado en contenedores por defecto, la práctica correcta es realizar el aislamiento con Docker o dev containers y ejecutar --yolo dentro del contenedor, dejando que sea el contenedor el que sirva de barrera de seguridad en lugar de soltar las riendas directamente en tu máquina local. Existe un ejemplo oficial de devcontainer seguro (con control de salida mediante cortafuegos) muy útil como referencia.

Sin embargo, la documentación oficial añade una advertencia que debo transmitirte: incluso abriendo acceso completo dentro de un devcontainer, la seguridad no es absoluta; un proyecto malicioso podría robar todo lo accesible en el contenedor (incluyendo tus credenciales de sesión de Codex). Por lo tanto, incluso dentro de contenedores, hazlo únicamente con repositorios de código de confianza y vigila sus operaciones como lo harías con cualquier entorno de privilegios elevados.

Mi dolorosa conclusión es una sola: el acceso completo solo se abre en entornos aislados donde no importe la destrucción o la pérdida de datos, y en la máquina local o producción queda descartado por completo. Que las alertas sean molestas no es justificación: es mejor lidiar con ellas que quedarse con la sangre helada.

💡 Resumen en una frase: Codex selecciona el nivel por defecto según "si hay Git o no" (con Git → Auto, sin Git → solo lectura), no desactives esta protección; la búsqueda web usa caché por defecto para evitar inyecciones; --yolo (libertad completa) se usa únicamente en contenedores aislados y nunca en tu máquina local o en producción.

---

07 Manos a la obra: cambia los tres niveles de permisos en 5 minutos

Leer no es suficiente para recordar. A continuación utilizaremos un directorio vacío para comprobar cómo reacciona Codex ante una misma petición en los diferentes niveles, si deteniéndose a preguntar o ejecutando directamente. El proceso no requiere ningún proyecto real.

Primer paso: Crear un directorio vacío y arrancar Codex.

En Mac / Linux (en Windows usa PowerShell y cambia mkdir -p por mkdir):

mkdir -p ~/perm-demo && cd ~/perm-demo
codex

Nota: Este directorio no está inicializado con Git. Siguiendo la lógica por defecto de la sección 06, lo más probable es que Codex inicie en el nivel read-only, lo cual nos ahorra tener que configurarlo manualmente.

Segundo paso: Confirmar el nivel activo.

Al iniciar la sesión, revisa en qué nivel te encuentras:

/status

Resultado esperado: verás el modo de sandbox activo, la estrategia de aprobación y los directorios de tu espacio de trabajo. Toma esta pantalla como referencia inicial.

Tercer paso: Bajo el nivel de solo lectura, pídele realizar una acción de "escritura de archivos".

Asegúrate de estar en solo lectura (si no es así, escribe /permissions para cambiar a Read Only) y escribe:

帮我新建一个文件 hello.txt，里面写一行 "hello codex"。

Resultado esperado: no creará el archivo de forma silenciosa, sino que se detendrá a pedir confirmación, ya que "escribir archivos" excede los límites de read-only. Según la estrategia de aprobación, te consultará algo como:

我需要创建文件 hello.txt，这超出了当前只读模式的权限，是否允许？

Al ver que se detiene a preguntar, el sandbox y la aprobación actúan de forma conjunta ante tus ojos: el sandbox evalúa que "este paso intenta salir de los límites" y la aprobación se despliega para que confirmes.

Cuarto paso: Cambiar a modo escribible y ver la flexibilidad.

/permissions

Cambia al nivel Auto / Workspace Write en el selector e indícale crear hello.txt nuevamente. Resultado esperado: esta vez creará el archivo directamente sin preguntar, ya que escribir archivos en el espacio de trabajo está dentro de los límites del sandbox y no requiere aprobación.

已创建 hello.txt

Quinto paso (Opcional): Comprobar que la red está desactivada por defecto.

Manteniendo el nivel de espacio de trabajo escribible, pídele realizar una acción de red:

帮我用 curl 访问一下 https://example.com，把返回内容贴出来。

Resultado esperado: como workspace-write desactiva la red por defecto (explicado en la sección 02), se detendrá a pedir confirmación de red o fallará el acceso de inmediato, lo que demuestra que "escribir archivos ≠ conectarse a la red". Para permitirle conectarse, tendrías que activar network_access en config.toml, pero no es necesario para esta práctica.

Al completar estos pasos, habrás verificado por ti mismo el flujo de "bloquear escrituras en solo lectura, autorizar en modo escribible y red desactivada por defecto". Cualquier ajuste futuro de permisos se basa en cambiar de marchas en este mismo sistema.

💡 Resumen en una frase: Crea un directorio vacío, usa /status para revisar, pídele escribir en solo lectura para ver cómo se bloquea, cambia a escribible para ver cómo avanza y comprueba el acceso a la red: cambiar los tres niveles por ti mismo es más valioso que memorizar diez parámetros.

---

08 Resumen

En este artículo hemos revisado las riendas de control de Codex desde su lógica interna hasta su uso práctico: la flexibilidad o restricción depende de la combinación de los interruptores de sandbox y aprobación.

Repasemos los puntos clave consolidados:

Qué quieres hacer	Qué utilizar	Punto clave
Configurar alcance	Sandbox --sandbox	Tres niveles: read-only / workspace-write / danger-full-access
Configurar alertas	Aprobación --ask-for-approval	Tres niveles: untrusted / on-request / never, independiente del sandbox
Modificación temporal	Parámetros de consola / /permissions	Permite cambiar de nivel en la sesión actual
Configuración permanente	config.toml	Claves sandbox_mode + approval_policy; usa --profile para múltiples perfiles
Control detallado de comandos/rutas	rules / permission profiles	Nivel avanzado; los profiles no son compatibles con el sandbox antiguo
Libertad completa	--yolo	Únicamente en contenedores aislados, descartado en tu máquina local o en producción

Ahora deberías ser capaz de: comprender qué tareas corresponden a los tres modos de sandbox y las tres estrategias de aprobación; ajustarlos temporalmente con --sandbox / --ask-for-approval o guardarlos por defecto en config.toml; saber que Codex elige la configuración según "si hay Git o no"; comprender que workspace-write restringe la red por defecto y protege .git como solo lectura; y trazar firmemente la línea roja de --yolo para usarlo únicamente en entornos aislados. Esta capacidad de control flexible es el fundamento que te permite delegar tareas a Codex con tranquilidad, sin el temor a que se te hiele la sangre.

---

El siguiente artículo 16 · Límites de seguridad y riesgos: este artículo te ha enseñado "cómo configurar los permisos", pero las opciones son solo herramientas; el problema de fondo es: ¿realmente se debe confiar en la AI para trabajar con tu código y sistema? ¿Cómo aprovecha las brechas la inyección de prompts (prompt injection)? ¿Cómo evitar filtraciones de datos sensibles? ¿Cuál es el balance de seguridad respecto a las búsquedas web con caché o las revisiones automáticas? Con las riendas en la mano, en el próximo artículo conversaremos sobre "cuándo restringir y cuándo dar libertad".

---

Lecturas recomendadas

• Codex Cloud en la nube: delega el trabajo a la nube y espera el resultado tomando un café
• Subagentes (Subagents): bifurcar tareas para ejecutarlas en paralelo, pero solo cuando lo solicites
• Mejores prácticas: aquellas reglas realmente aplicables más allá de la "palabrería correcta"