Capital de Tokens
Hay un flag de Codex cuyo nombre ya intenta avisarnos de que no estamos activando una simple comodidad:
codex exec --dangerously-bypass-approvals-and-sandbox "..."También existe su alias corto:
codex exec --yolo "..."La documentación actual de OpenAI lo describe de forma muy directa: ejecuta comandos sin approvals y sin sandboxing, y recomienda usarlo únicamente dentro de un entorno endurecido externamente, como un runner aislado o una VM dedicada.
La parte importante está en esas dos palabras:
approvals
sandboxNo son lo mismo.
Y entender la diferencia permite construir agentes mucho más autónomos sin tener que darles acceso indiscriminado a la máquina.
El modelo mental correcto: hay dos ejes independientes
Codex separa dos preguntas:
1. ¿Qué está técnicamente permitido?
2. ¿Cuándo debe pedirse permiso al humano?La primera la responde el sandbox.
La segunda la responde la approval policy.
Podemos visualizarlo así:
Codex
│
▼
quiere ejecutar algo
│
▼
┌────────────────────┐
│ Approval policy │
│ ¿debo preguntar? │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Sandbox / profile │
│ ¿puedo hacerlo? │
└─────────┬──────────┘
│
▼
sistema operativoÉsta es la distinción que más conviene recordar:
Approval controla la interacción. Sandbox controla la capacidad.
Un agente puede no preguntar nunca y seguir estando muy limitado.
También puede tener un filesystem prácticamente abierto y aun así detenerse antes de ciertas escaladas.
Qué hace exactamente --dangerously-bypass-approvals-and-sandbox
La referencia oficial de la CLI dice que este flag hace que Codex ejecute todos los comandos sin approvals ni sandbox y que sólo debería utilizarse dentro de un entorno endurecido externamente.
Conceptualmente equivale a combinar:
sandbox_mode = danger-full-access
approval_policy = neverOpenAI denomina a esa combinación Full access.
Eso significa que la frontera deja de estar dentro de Codex y pasa a estar en aquello que rodea al proceso.
Por ejemplo:
host normal
└── usuario frank
└── codex --yolo
├── shell
├── git
├── gh
├── python
├── docker
└── cualquier herramienta accesible al usuarioCodex no obtiene mágicamente root si el usuario no lo tiene.
Pero sí puede llegar, aproximadamente, hasta donde pueda llegar la cuenta que lanzó el proceso.
Si esa cuenta puede hacer:
cat ~/.ssh/id_ed25519
rm -rf ~/projects
curl https://example.com
gh repo delete ...
docker run ...
kubectl ...entonces un Codex sin sandbox puede intentar utilizar esas capacidades también.
El riesgo no es sólo un comando equivocado.
El riesgo es el blast radius completo de la identidad desde la que se ejecuta.
Los tres modos clásicos de sandbox
La CLI actual expone tres modos principales:
--sandbox read-only
--sandbox workspace-write
--sandbox danger-full-accessread-only
Está pensado para inspección.
leer repo ✅
analizar código ✅
review ✅
modificar repo ❌Un patrón interesante para CI es:
codex exec \
--sandbox read-only \
--ask-for-approval never \
"Revisa este cambio y devuelve hallazgos"Aquí el agente no interrumpe al pipeline con preguntas, pero tampoco recibe autoridad para modificar el workspace.
La autonomía no implica acceso ilimitado.
workspace-write
Éste es probablemente el modo más útil para trabajo local y agentes de desarrollo.
Codex puede:
leer el proyecto
editar dentro del workspace
correr comandos locales rutinariosmientras mantiene la frontera del workspace.
La documentación actual lo presenta como el modo local de baja fricción.
Un ejemplo:
codex exec \
--sandbox workspace-write \
--ask-for-approval on-request \
"Implementa el issue y ejecuta los tests"El agente trabaja normalmente dentro del proyecto y pide aprobación cuando necesita cruzar la frontera prevista.
danger-full-access
codex --sandbox danger-full-accesselimina las restricciones locales del sandbox.
La documentación señala explícitamente que desaparecen las fronteras de filesystem y red propias del sandbox.
Pero eso todavía no obliga a desactivar approvals.
Ésa es una distinción importante.
never no significa automáticamente “dale acceso a todo”
La approval policy never significa esencialmente:
no me interrumpas con approval promptsNo significa:
ignora todas las restricciones técnicasPor ejemplo:
codex exec \
--sandbox read-only \
--ask-for-approval never \
"Analiza este repositorio"es un agente silencioso y altamente restringido.
Y:
codex exec \
--sandbox workspace-write \
--ask-for-approval never \
"Corrige los tests"puede ser una configuración excelente para automatización local o un runner dedicado cuando queremos cero interacción pero todavía queremos confinamiento.
La combinación peligrosa es:
danger-full-access
+
neverEso es precisamente el territorio de --yolo.
La matriz que conviene tener en la cabeza
| Sandbox | Approval | Comportamiento |
|---|---|---|
read-only | on-request | muy conservador |
read-only | never | autónomo para auditoría |
workspace-write | on-request | buen default local |
workspace-write | never | agente autónomo pero confinado |
danger-full-access | on-request | host abierto con checkpoints humanos |
danger-full-access | never | full access / YOLO |
El error más común es pensar que el eje principal es:
pregunta mucho ←→ no preguntaEn realidad el eje más importante de seguridad es:
qué puede hacer incluso si se equivocaEl sandbox también envuelve los procesos hijos
El sandbox no protege únicamente la función interna de edición de archivos de Codex.
Si Codex ejecuta:
bash
python
pytest
uv
npm
git
gh
curlesos procesos forman parte del entorno restringido.
Conceptualmente:
Codex
└── bash
└── python
└── subprocess
└── herramientaLa utilidad de esta arquitectura está en que la política se aplica al runtime, no sólo a una promesa del modelo.
Eso es crucial frente a errores y prompt injection.
Un prompt puede intentar convencer al modelo de hacer algo.
El sistema operativo todavía puede responder:
ACCESS DENIEDEl enforcement ocurre a nivel del sistema operativo
OpenAI documenta que el sandbox local utiliza mecanismos diferentes según la plataforma.
Actualmente:
macOS
└── Seatbelt / sandbox-exec
Linux
└── bwrap + seccomp
WSL
└── sandbox Linux
Windows
└── sandbox nativo de CodexEsto introduce una separación muy importante:
"modelo, no hagas X"
≠
"kernel, impide X"El primero es una instrucción probabilística.
El segundo es una frontera de ejecución.
Para agent security, necesitamos ambos, pero no debemos confundirlos.
Network es otra capacidad que debe modelarse explícitamente
En workspace-write, la red para comandos está deshabilitada por defecto según la documentación actual de Codex.
Puede activarse mediante:
[sandbox_workspace_write]
network_access = truePero permitir red y permitir cualquier destino son decisiones distintas.
Codex tiene soporte para network_proxy, que permite aplicar políticas por dominio.
Por ejemplo:
[features.network_proxy]
enabled = true
domains = {
"api.openai.com" = "allow",
"example.com" = "deny"
}Esto permite construir una frontera como:
agente
│
├── filesystem → sólo workspace
│
└── network
└── proxy
├── api.openai.com ✅
├── github.com ✅
└── resto ❌Es mucho mejor que asumir que “necesita Internet” equivale a abrir Internet completo.
--add-dir: ampliar acceso sin abandonar el sandbox
OpenAI recomienda explícitamente preferir --add-dir cuando el agente necesita trabajar con directorios adicionales, en vez de saltar directamente a danger-full-access.
Ejemplo:
codex \
--sandbox workspace-write \
--add-dir ../shared-libraryEso produce una autoridad mucho más estrecha:
repo principal write ✅
shared-library write ✅
resto de la máquina ❌Éste es exactamente el tipo de diseño de mínimo privilegio que conviene para agentes de larga duración.
Permission Profiles: una capa más fina que los tres modos clásicos
Codex también dispone de permission profiles.
La documentación actual incluye tres perfiles built-in:
:read-only
:workspace
:danger-full-accessY permite definir perfiles personalizados.
Por ejemplo:
default_permissions = "project-edit"
[features]
network_proxy = true
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"Ese perfil expresa una política bastante más útil que simplemente “sandbox on/off”:
workspace write
.env deny
api.openai.com allow
resto de destinos no permitidoHay una sutileza importante: OpenAI documenta que estos permission profiles no se componen con el mecanismo clásico de sandbox_mode.
Debemos configurar una familia u otra de forma consciente.
Denegar .env es un buen ejemplo de seguridad útil
Pensemos en este workspace:
repo/
├── src/
├── tests/
├── pyproject.toml
└── .envEl objetivo no debería ser impedir que Codex haga trabajo real.
El objetivo debería ser darle suficiente autoridad para:
editar código
crear tests
correr linters
corregir bugsmientras se le impide leer secretos que no necesita.
Un permission profile puede convertir esa intención en una política técnica:
src/** write
tests/** write
.env denyEso reduce enormemente el impacto de una prompt injection que intente buscar credenciales.
Rules: un firewall para comandos
Otra capa de Codex son las reglas de ejecución o .rules.
Las reglas pueden decidir entre:
allow
prompt
forbiddenY cuando varias coinciden, la documentación define esta precedencia:
forbidden > prompt > allowPodríamos imaginar una política como:
gh pr view allow
gh pr list allow
gh pr create prompt
gh repo delete forbiddenEsta capa es especialmente útil porque muchas acciones sensibles no se distinguen únicamente por el binario.
No es lo mismo:
gh pr viewque:
gh repo deleteaunque ambas comiencen con gh.
Rules permite expresar autoridad a nivel de operaciones concretas.
Auto-review: automatizar approvals sin borrar la frontera
Codex también puede delegar ciertas aprobaciones a un reviewer automático.
La configuración documentada incluye:
approval_policy = "on-request"
approvals_reviewer = "auto_review"Eso cambia el flujo de:
Codex
↓
pide escalada
↓
humano decidehacia:
Codex
↓
pide escalada
↓
reviewer agent
├── aprueba
└── rechazaEl punto importante es que no elimina el sandbox.
Automatiza una parte del gate.
Éste es un patrón mucho más interesante que saltar directamente a YOLO cuando queremos agentes que trabajen durante horas sin supervisión continua.
--full-auto ya no es la dirección recomendada
La CLI todavía reconoce:
--full-autopero la referencia actual lo marca como deprecated y recomienda usar --sandbox workspace-write.
Eso refleja una evolución conceptual saludable:
autonomía
≠
acceso ilimitadoUn agente puede ser completamente automático dentro de una frontera estrecha.
Otros escape hatches que conviene conocer
La CLI también documenta flags como:
--dangerously-bypass-hook-trustque permite ejecutar hooks habilitados sin exigir la confianza persistida habitual para esa invocación.
Y:
--ignore-rulesque evita cargar las reglas execpolicy del usuario o proyecto durante ese run.
No son equivalentes a --yolo, pero sí modifican capas importantes del modelo de confianza.
En CI deben tratarse como cambios deliberados de seguridad, no como simples atajos para “hacer que pase”.
El mejor patrón para CI no suele ser YOLO
Supongamos que queremos un agente que haga review automáticamente.
Una configuración razonable puede ser:
filesystem: read-only
approvals: never
network: sólo lo necesario
secrets: mínimosPara un agente que corrige código:
filesystem: workspace-write
approvals: never
network: allowlist
secrets: token scoped al repoPara un agente que publica un PR:
workspace-write
+
regla explícita para gh pr create
+
token con permisos mínimos
+
branch protection
+
required checksLa arquitectura debería intentar mantener varias barreras:
modelo
↓
permission profile / sandbox
↓
rules
↓
network policy
↓
credenciales con scopes mínimos
↓
rama aislada
↓
CI
↓
branch protectionEso es defense in depth para agentes.
Cuándo sí tiene sentido --yolo
El flag no existe porque nunca sea útil.
Tiene sentido cuando Codex no es la frontera de seguridad.
Por ejemplo:
host real
↓
VM efímera / runner aislado
↓
container o usuario sin privilegios
↓
secrets mínimos
↓
Codex --yoloEn ese diseño, eliminar el segundo sandbox puede simplificar herramientas que de otro modo pelearían con restricciones duplicadas.
Pero la pregunta correcta antes de activar el flag es:
Si Codex ejecutara el peor comando plausible, ¿qué podría destruir, leer o exfiltrar desde este entorno?
Si la respuesta incluye:
mis SSH keys
mis repos privados completos
credenciales cloud
Docker socket del host
kubectl de producción
tokens de larga duraciónentonces el entorno probablemente no está preparado para YOLO.
El principio central: limitar capacidad, no sólo pedir confirmación
Un sistema que depende únicamente de approvals humanos sigue teniendo un problema.
El humano puede cansarse.
Puede aprobar por costumbre.
Puede no entender exactamente qué está autorizando.
Puede querer que el agente funcione mientras duerme.
Por eso el objetivo maduro no debería ser:
hacer que Codex pregunte por todosino:
hacer que aquello que puede ejecutar automáticamente
ya esté acotado por políticas técnicasEso produce una arquitectura mejor:
agente muy autónomo
+
blast radius pequeñoEn vez de:
agente muy autónomo
+
identidad con acceso totalLa relación con prompt injection
Este modelo de permisos conecta directamente con otro problema que ya analizamos en Capital de Tokens: repository poisoning y prompt injection contra coding agents.
Un repo puede contener texto malicioso.
Un issue puede contener instrucciones manipuladoras.
La salida de una tool puede estar comprometida.
No debemos construir la defensa bajo la premisa:
"el modelo siempre reconocerá el engaño"La postura más robusta es:
modelo puede equivocarse
↓
¿qué puede hacer si se equivoca?Ahí sandbox, rules, network policy y least privilege dejan de ser detalles de configuración.
Se convierten en la arquitectura principal de seguridad del agente.
Una receta práctica para agentes locales
Si queremos un Codex que trabaje de forma bastante autónoma en un repo local, yo empezaría por algo parecido a:
codex exec \
--sandbox workspace-write \
--ask-for-approval never \
"Implementa la tarea, corre tests y deja el workspace listo"Después ampliaría únicamente lo necesario:
necesita otro repo → --add-dir
necesita Internet → network explícito
necesita sólo GitHub → allowlist de dominios
no debe leer .env → permission profile deny
ciertos comandos peligrosos → .rules forbiddenLa escalada correcta es:
mínimo privilegio
↓
observar qué falta
↓
agregar capacidad concretaNo:
algo fue bloqueado
↓
activar YOLOLa idea que vale la pena recordar
El sistema de seguridad de Codex no es un simple interruptor.
Es una composición de capas:
Model
↓
Approval policy
↓
Rules
↓
Permission profile / sandbox
↓
Network policy
↓
OS enforcement
↓
Credentials / external environment
↓
Git / CI / branch protectionY --dangerously-bypass-approvals-and-sandbox elimina dos de las barreras más importantes de esa pila de una sola vez.
Por eso el nombre es deliberadamente incómodo.
No significa necesariamente:
“Codex se vuelve inseguro en cualquier contexto”.
Significa:
“Desde aquí, la seguridad depende mucho más del entorno externo que hayas construido.”
Ésa es la diferencia entre usar YOLO dentro de una VM efímera con un token scoped a un repo y usarlo desde tu laptop principal con todas tus credenciales cargadas.
El mismo flag.
Un blast radius completamente diferente.
Y ésa es probablemente la lección más importante para cualquiera que esté construyendo agentes autónomos: la autonomía debería crecer más rápido que los privilegios.