Ponle la correa a Codex antes de soltarlo
No le darías la contraseña de tu laptop a un empleado nuevo en su primer día. Tampoco se la des a tu agente de IA para programar. OpenAI Codex tiene dos ajustes independientes que deciden cuánta libertad recibe: el modo sandbox, que controla qué tiene permitido tocar físicamente, y la política de aprobación, que controla cuándo tiene que detenerse y preguntarte primero.
Dos perillas, no una
Es tentador tratar los ajustes de seguridad de Codex como un único control de confianza. No lo son. El modo sandbox es el límite duro — impuesto a nivel del sistema operativo, no por el criterio del modelo. La política de aprobación es la capa conversacional — cuándo Codex se detiene a mitad de la ejecución para pedir permiso en lugar de simplemente actuar. Puedes tener un sandbox amplio con aprobaciones estrictas (podría hacer mucho, pero pregunta constantemente), o un sandbox estrecho con aprobaciones laxas (rara vez pregunta, pero hay poco que pueda hacer mal). Saber qué perilla controla qué modo de fallo es todo el truco.
Los tres modos de sandbox
| Modo | Lectura | Escritura | Red / fuera del proyecto |
|---|---|---|---|
read-only | En cualquier lugar | En ningún lugar | No |
workspace-write (por defecto) | En cualquier lugar | Solo dentro de la carpeta del proyecto | Pregunta primero |
danger-full-access | En cualquier lugar | En cualquier lugar | Sí, sin restricciones |
workspace-write es el valor por defecto y el que vale la pena entender. Puede leer cualquier archivo de tu sistema — útil para traer contexto de repos hermanos o documentación en otra parte del disco — pero solo puede escribir dentro de la carpeta del proyecto actual. Si necesita la red o una ruta fuera de esa carpeta, se detiene y pregunta, independientemente de la política de aprobación, porque esa es una restricción a nivel de sandbox. danger-full-access elimina la barrera por completo; resérvalo para un contenedor desechable o un sandbox de CI, nunca para tu máquina principal.
Las tres políticas de aprobación
- untrusted — pregunta antes de casi todo. Bueno para una base de código que aún no conoces ni en la que confías.
- on-request — pregunta solo cuando está a punto de hacer algo que el sandbox no le permitiría por sí solo (salir de la carpeta, alcanzar la red). El valor por defecto equilibrado.
- never — nunca pregunta; hace lo que el sandbox permita. Reservado para automatización y CI donde no hay un humano presente para responder a una solicitud.
El valor por defecto seguro: workspace-write + on-request
Junta las dos perillas: sandbox = workspace-write, aprobación = on-request. Codex lee todo tu disco para obtener contexto, edita y crea archivos libremente dentro de tu proyecto, ejecuta comandos y pruebas locales — y se detiene a preguntar antes de hacer cualquier cosa que llegue más allá de la carpeta del proyecto o toque la red. Eso cubre la mayoría del trabajo diario de funcionalidades sin un diálogo de permiso cada pocos segundos.
Guarda danger-full-access para entornos que puedas descartar: un runner de CI efímero, una VM de borrador, un contenedor que se reconstruye en cada ejecución.
Cómo configurarlo
Ambos ajustes viven en el config.toml de Codex, así que los estableces una sola vez en lugar de volver a elegirlos al inicio de cada sesión. Establece ahí tus preferencias y cada nueva sesión las hereda automáticamente — sin configuración repetida, sin olvidar volver a apretar una configuración permisiva que activaste para una tarea arriesgada.
Elegir modos según la situación
- Base de código nueva o no confiable:
read-only+untrusted. Deja que Codex explore y proponga antes de que pueda tocar nada. - Trabajo rutinario de funcionalidades en un repo que conoces:
workspace-write+on-request— el valor por defecto equilibrado. - Pipelines automatizados, contenedores desechables, CI:
danger-full-access+never, ya que no hay un humano presente y el entorno es desechable.
Errores comunes
- Tratar el modo sandbox como la historia completa. Un sandbox amplio con aprobaciones
neversignifica que Codex genuinamente no preguntará antes de hacer cualquier cosa que el sandbox permita. - Aflojar a acceso completo "solo por esta tarea" y olvidar revertirlo — es un archivo de configuración, no una elección forzada por sesión.
- Suponer que workspace-write es completamente seguro. Aún lee cualquier cosa en el disco, lo que importa si tu proyecto está junto a directorios con secretos.
Recursos
- developers.openai.com — modos de sandbox de Codex
- developers.openai.com — políticas de aprobación y seguridad
¿Construyendo una funcionalidad de IA? Yeda AI diseña, audita y despliega sistemas LLM en producción.