Codex Permissions and Approvals Configuration

Alcance y capas de control

Esta guía documenta controles locales de Codex según fuentes oficiales consultadas el 2026-11-09. Su objetivo es distinguir lectura, escritura, red y revisión de acciones de las instrucciones que orientan al agente. Los ejemplos no fueron aplicados ni prueban las políticas efectivas de una instalación.

agent-permissions-and-approval-boundaries y agent-sandboxing conservan los conceptos generales. Una guía o skill expresa comportamiento deseado; la política de ejecución determina qué recursos puede utilizar el trabajo. La aprobación decide cómo se trata una acción que necesita esa revisión.

Dos ejemplos de sesión con el esquema sandbox

Para clientes que utilizan sandbox_mode, la guía de aprobaciones y seguridad documenta estas combinaciones:

codex --sandbox read-only --ask-for-approval never

Este modo mantiene comandos locales dentro de un sandbox de solo lectura y no solicita nuevas aprobaciones. Una acción que requiere permisos no disponibles no debe presentarse como ejecutada. No establece por sí solo una política para todos los conectores externos.

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

Esta combinación admite trabajo de escritura dentro del workspace permitido y conserva solicitudes de aprobación cuando corresponden. Tener escritura no significa que todo el disco sea editable: pueden existir directorios protegidos, requisitos administrados y restricciones adicionales. Antes de un encargo, comprobar los límites efectivos de esa sesión.

never controla prompts de aprobación, no elimina el sandbox. Del mismo modo, permitir solicitar una excepción no significa que se vaya a aprobar. El usuario debe conocer qué efecto y alcance está revisando.

Configuración persistente y red

Un fragmento alternativo para una configuración que use el esquema anterior es:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
 
[sandbox_workspace_write]
network_access = false

La referencia de configuración documenta network_access y writable_roots para ese sandbox. No copiar el fragmento reemplazando un archivo completo: revisar capas y claves existentes. Config basics describe configuración personal y de proyecto, con carga de .codex/config.toml de proyectos confiables y precedencia entre capas.

Como criterio de adopción, enumerar qué rutas necesita modificar la tarea y qué red necesita realmente un comando. Un permiso demasiado amplio puede exponer datos o permitir efectos ajenos al trabajo. Una negación también puede impedir una dependencia legítima; diagnosticarla no requiere desactivar todas las restricciones.

Perfiles de permisos: comprobar compatibilidad

La documentación actual de Permissions describe perfiles locales como :read-only y :workspace, seleccionados mediante default_permissions, además de perfiles definidos por el usuario. Es otro mecanismo de configuración; no debe mezclarse suponiendo que compone con sandbox_mode y sandbox_workspace_write.

La guía explica que opciones del esquema anterior pueden hacer que se utilice ese esquema en lugar de default_permissions; las políticas administradas pueden imponer otra selección. Antes de migrar, comprobar versión, capas cargadas y requisitos de la organización. Aquí no se proporciona una migración automática.

Las reglas de dominios de esos perfiles requieren el proxy de red activo para restringir tráfico directo de comandos. Definir dominios permitidos sin el mecanismo de enforcement correspondiente no demuestra que se aplique esa frontera.

Agentes, skills y servicios externos

Caso	Control que debe comprobarse
Custom agent que debería revisar sin editar	Permisos efectivos de la sesión que lo ejecuta; instrucciones y nombre no bastan.
Subagente o rol orquestador	Herencia de la sesión padre, explicada en codex-agent-configuration.
Skill con instrucciones de edición	Permisos del runtime y autoridad del encargo, explicados en codex-skill-configuration.
Comandos locales	Sandbox/perfil, aprobación y permisos del sistema operativo.
MCP, conectores, navegador o Computer Use	Controles propios de esa superficie, además de las políticas aplicables.

La documentación de Permissions delimita explícitamente su alcance sobre comandos locales; no permite inferir permisos universales sobre todas las herramientas. Una integración MCP con operaciones de escritura necesita revisión propia. Mantener tokens fuera del repositorio y de los ejemplos sigue siendo parte del diseño.

Cómo verificar sin asumir enforcement

La guía de sandboxing separa restricciones técnicas y revisión de acciones. Para probar una configuración, usar archivos sintéticos y acciones delimitadas en un entorno de laboratorio. Observar si una lectura permitida funciona, si una escritura prohibida se rechaza y qué ocurre al necesitar una excepción. No usar datos de producción como prueba de aislamiento.

Registrar cliente, plataforma, política efectiva, comando y resultado. Repetir cuando cambien esas condiciones, porque una configuración válida como TOML todavía puede estar ignorada, sobreescrita o no soportada. Este artículo no ejecutó esas pruebas ni alteró permisos del proyecto; ai-technology-catalog organiza la guía junto a las otras implementaciones.