Guía práctica de seguridad de Codex

Usa esta receta cuando los empleados deban iniciar sesión en Codex a través del espacio de trabajo de ChatGPT de tu empresa y esté prohibido usar cuentas personales de ChatGPT o autenticarse con claves de API en los dispositivos administrados.

Resultado esperado

En los dispositivos administrados por la empresa, Codex solo acepta el inicio de sesión con ChatGPT en el espacio de trabajo de ChatGPT de la empresa.

Requisitos previos

• El UUID del espacio de trabajo aprobado de ChatGPT Enterprise.

• Un medio para distribuir la configuración administrada de Codex a los dispositivos.

• La decisión de prohibir la autenticación con claves de API en los dispositivos administrados.

Configuración

1. Registra el UUID del espacio de trabajo aprobado en tu repositorio interno de configuración.

2. Agrega los requisitos obligatorios de autenticación al archivo requirements.toml local:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

   La primera clave permite únicamente la autenticación con ChatGPT. La segunda restringe el inicio de sesión al espacio de trabajo aprobado. Sustituye el UUID de ejemplo por el de tu espacio de trabajo. Consulta la referencia de requisitos.

3. Distribuye los requisitos mediante el archivo requirements.toml local o los requisitos de MDM en macOS según las rutas de Dónde aplicar la configuración. Estos requisitos de autenticación se aplican antes de cargar las credenciales y de obtener la política de la nube. Codex los ignora si se incluyen en los requisitos administrados desde la nube. Impide que el usuario modifique el archivo y su directorio superior. Los valores predeterminados del archivo heredado managed_config.toml no hacen cumplir esta restricción.

4. Durante la prueba piloto, cierra las sesiones de los usuarios o elimina las sesiones personales de Codex guardadas anteriormente. No des por hecho que una política nueva invalida retroactivamente una sesión existente.

5. Combina la restricción de inicio de sesión con los roles del espacio de trabajo y el acceso por grupo. La autenticación controla qué identidad inicia sesión. El control de acceso basado en roles (RBAC) determina qué funciones de Codex puede usar esa identidad. Consulta Autenticación.

Verificación

• Cierra sesión en Codex.

• Intenta iniciar sesión con una cuenta personal de ChatGPT. Resultado esperado: se rechaza el inicio de sesión en el espacio de trabajo personal.

• Intenta iniciar sesión en Codex con una clave de API. Resultado esperado: se rechaza el inicio de sesión con la clave de API.

• Inicia sesión en el espacio de trabajo aprobado con la cuenta corporativa. Resultado esperado: la sesión se inicia correctamente.

• Reinicia la aplicación de escritorio, la CLI y la extensión del IDE. Luego repite las comprobaciones.

Revertir los cambios

Restaura los requisitos de autenticación locales anteriores y vuelve a desplegar el paquete revisado.

Alcance y límites

Este control se aplica a los clientes administrados de Codex en dispositivos administrados. Combínalo con controles de aplicaciones en los dispositivos y con una política de red si el requisito es “impedir el uso personal de Codex desde los recursos de la empresa”.

Usa esta receta cuando los desarrolladores necesiten acceso de solo lectura o limitado al espacio de trabajo y quieras impedir que seleccionen Acceso completo o que eludan las aprobaciones y el sandbox con --yolo.

Resultado esperado

Los usuarios solo pueden seleccionar perfiles aprobados de solo lectura o limitados al espacio de trabajo. No pueden seleccionar danger-full-access, approval_policy = "never" ni --yolo.

Configuración

1. Define un perfil aprobado para el espacio de trabajo:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Restringe la selección a los perfiles y las políticas de aprobación permitidos:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

   La lista de perfiles permitidos es exhaustiva. Se deniegan los perfiles que no figuran en ella o cuyo valor es falso, incluidos los que se agreguen en versiones futuras. Consulta la Referencia de configuración.

3. Para los clientes heredados que aún usan sandbox_mode, usa lo siguiente:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Distribuye estos ajustes como requisitos impuestos por el administrador. Evita distribuirlos en un archivo de configuración que el usuario pueda editar.

5. Si más adelante decides permitir la Revisión automática, agrégala después de probarla. La Revisión automática cambia quién revisa una acción que excede los límites establecidos. No restablece un límite que ya se eliminó. Consulta Revisión automática.

Verificación

• Abre el selector de permisos. Resultado esperado: la opción Acceso completo no está disponible o se rechaza al seleccionarla.

• Inicia Codex con --dangerously-bypass-approvals-and-sandbox. Resultado esperado: Codex rechaza el inicio o impone un perfil compatible.

• Inicia Codex con --sandbox danger-full-access --ask-for-approval never. Resultado esperado: se rechaza el inicio.

• Ejecuta una tarea habitual del espacio de trabajo. Resultado esperado: la tarea se completa y las acciones que exceden los límites siguen requiriendo aprobación.

Revertir los cambios

Restaura el paquete de requisitos anterior. Mantén bloqueado el acceso sin restricciones salvo que se haya aprobado una excepción por separado.

Alcance y límites

Este control regula los permisos de ejecución de Codex. No le quita privilegios a una cuenta privilegiada del sistema operativo.

Usa esta receta cuando tu organización necesite decidir qué servidores MCP puede usar Codex y hacer cumplir la lista aprobada.

Autorizar un servidor y configurarlo son pasos independientes. Una entrada en la lista permite usar un servidor que coincida con ella, pero no crea la configuración del servidor. Configúralo por separado con el nombre y la identidad correspondientes, junto con la autenticación que requiera.

Resultado esperado

Codex habilita únicamente los servidores MCP cuyo nombre e identidad configurados coincidan con una entrada de la lista aprobada por la empresa.

Configuración

1. Registra los datos de cada servidor aprobado: responsable, finalidad, transporte, ejecutable o URL exactos, autenticación, clasificación de los datos y herramientas con capacidad de escritura.

2. Empieza por denegar todo. Una tabla administrada vacía deshabilita todos los servidores MCP:

   [mcp_servers]

3. Agrega los servidores HTTP aprobados con su URL exacta:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Agrega los servidores stdio aprobados con su ejecutable y sus argumentos posicionales:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

   La regla comprueba que coincidan el ejecutable, la cantidad de argumentos y su orden. No restringe cwd, env ni env_vars. Antes de aprobar un servidor stdio, asegúrate de controlar todo su contexto de inicio. Protege el ejecutable y sus dependencias e impide que una configuración de usuario o de proyecto que no sea de confianza proporcione un directorio de trabajo o un entorno capaz de modificar el comportamiento del servidor. Si no puedes imponer ese límite de forma independiente, deja el servidor stdio sin aprobar y usa un servidor HTTP revisado.

5. Agrega por separado las identidades MCP incluidas en complementos bajo plugins.<plugin>.mcp_servers.<server>.

6. Guarda la lista aprobada en un repositorio de configuración sujeto a revisión y despliégala mediante requisitos impuestos por el administrador.

El cliente habilita un servidor solo cuando tanto su nombre como su identidad coinciden con una entrada aprobada. Consulta Configuración administrada.

Verificación

• Configura el servidor exactamente como se aprobó. Resultado esperado: el servidor se inicia.

• Cambia un carácter de la URL. Resultado esperado: el servidor queda deshabilitado.

• Cambia la cantidad o el orden de los argumentos de stdio, o proporciona un argumento que no cumpla las reglas configuradas. Resultado esperado: el servidor queda deshabilitado. Los valores que siguen coincidiendo con un prefijo permitido continúan admitiéndose.

• En un proyecto de confianza que puedas descartar, prueba cambios inocuos en cwd, env y env_vars sin modificar el ejecutable ni los argumentos que coinciden con la entrada aprobada. La comprobación de identidad por sí sola no rechaza estos cambios. Verifica que el control independiente del contexto de inicio rechace los cambios inseguros o que el servidor stdio siga sin aprobarse. No uses una carga de inyección real.

• Agrega un nombre no aprobado. Resultado esperado: el servidor queda deshabilitado.

• Prueba un servidor incluido en un complemento. Resultado esperado: el servidor funciona solo con la identidad aprobada.

Revertir los cambios

Elimina la entrada que acabas de agregar. Para detener de inmediato todo uso de MCP, despliega una tabla mcp_servers vacía.

Alcance y límites

Una lista de identidades permitidas no demuestra que las herramientas del servidor, los datos que recibe de otros sistemas, sus credenciales o su entorno de inicio sean seguros. Los procesos MCP locales que usan stdio se ejecutan fuera del sandbox de comandos local. Comprobar que coincidan el ejecutable y los argumentos no restringe el acceso del servidor ni impide que cargue código a través del entorno. Revisa de forma independiente todo el contexto de inicio y los permisos del servidor. Consulta Requisitos de identidad MCP.

Usa esta receta cuando tu equipo de seguridad necesite entender qué hace Codex en los dispositivos y en tu red. Reúne eventos de ejecución y de herramientas, decisiones de aprobación, registros de auditoría del espacio de trabajo y registros de red para facilitar las investigaciones.

Resultado esperado

Los equipos de seguridad pueden correlacionar ejecuciones de Codex, decisiones sobre herramientas, aprobaciones, registros de auditoría del espacio de trabajo y tráfico de red saliente real sin depender de lo que el modelo diga que hizo.

Usar cuatro fuentes de evidencia

1. OpenTelemetry de Codex: eventos de ejecución, API, modelo, sandbox, aprobación y herramientas.

2. Hooks administrados del ciclo de vida: registros en el dispositivo sobre el uso de herramientas y las solicitudes de permisos.

3. Registros del proxy o de la puerta de enlace de red: destinos DNS/HTTP reales y resultados de las conexiones.

4. API de Cumplimiento: registros de auditoría e investigación del espacio de trabajo.

Ninguna fuente por sí sola ofrece un monitoreo completo de la red.

Configuración

1. Envía los registros de OpenTelemetry de Codex a tu recolector sin incluir el texto original de los prompts:

   [otel]
   environment = "enterprise"
   log_user_prompt = false
   
   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

   Antes de iniciar el cliente, proporciona OTLP_TOKEN al proceso de Codex a través del gestor de secretos aprobado o del entorno del proceso. Mantén el token fuera de los archivos TOML que despliegues y del sistema de control de versiones.

   Codex puede emitir eventos de inicio de conversaciones, solicitudes de API, eventos de transmisión, metadatos de prompts, decisiones sobre herramientas y resultados de herramientas. Consulta Configuración avanzada.

2. Despliega OTel fuera de la configuración local del proyecto. Los archivos .codex/config.toml del proyecto no pueden modificar el destino de la telemetría.

3. Agrega hooks administrados del ciclo de vida para SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop y SessionEnd.

4. Instala los scripts de los hooks en un directorio gestionado por el administrador y establece allow_managed_hooks_only = true si se deben ignorar los hooks de usuarios, proyectos y complementos.

5. Dirige el tráfico de los comandos que se ejecutan en el sandbox a través de un proxy con registros independientes. OTel registra que se ejecutó una herramienta. El proxy registra a dónde intentó conectarse el subproceso.

6. Configura telemetría por separado para la búsqueda web, las apps, los conectores, los servidores MCP, la actividad del navegador y Codex Cloud. Las reglas del proxy de comandos local no cubren automáticamente estos casos.

7. Transmite al SIEM los registros compatibles de la API de Cumplimiento y aplica tus propios controles de retención y conservación por motivos legales. Consulta API de Cumplimiento y eventos de auditoría.

8. Correlaciona la cuenta de usuario o de servicio, el host o ejecutor, el ID de conversación, el modelo, la versión del cliente, el perfil de permisos, la decisión de aprobación, el destino y el nombre de la herramienta.

Verificación

Ejecuta una sesión controlada en la que se realicen las siguientes acciones:

• Leer un archivo permitido.

• Intentar leer un archivo cuya lectura está bloqueada.

• Ejecutar un comando permitido.

• Intentar enviar una solicitud saliente bloqueada.

• Solicitar aprobación y recibir una denegación.

• Finalizar la sesión.

Resultados esperados por fuente de evidencia:

• OTel muestra eventos de ejecución y de herramientas.

• Los hooks muestran el ciclo de vida de la sesión.

• Los registros del proxy muestran los destinos permitidos y bloqueados.

• El sistema de ingesta de datos de cumplimiento recibe los registros compatibles.

• El SIEM correlaciona esos registros con el usuario o la carga de trabajo.

Revertir los cambios

Restaura la configuración anterior para deshabilitar el exportador y los hooks. Al revertir la telemetría, conserva el registro independiente del proxy.

Alcance y límites

No prometas que la telemetría de Codex captura cada argumento de los comandos, cada byte de salida o cada paquete de red. Documenta la cobertura de cada capa.

Usa esta receta cuando Codex deba funcionar sin acceso a internet o solo deba acceder a destinos aprobados. Elige el procedimiento local o el de la nube según el entorno que configures y ten presente que sus políticas tienen alcances distintos.

Resultado esperado

Codex no tiene acceso a internet o solo puede acceder a dominios aprobados, según la configuración que elijas. En los entornos de Codex Cloud (Legacy) también puedes restringir los métodos HTTP.

Configurar la versión actual de Codex Cloud

1. Crea entornos separados para los distintos niveles de confianza, por ejemplo, no-internet-review, approved-dependencies-build y cyber-lab.

2. En la configuración del entorno, desactiva Habilitar todo el acceso a internet pública y Habilitar dominios de gestores de paquetes.

3. Cuando necesites acceso a internet pública, agrega los nombres exactos de los hosts aprobados en Dominios permitidos adicionales. Elimina los Secretos HTTP que permitan destinos públicos no aprobados. Para bloquear el acceso a internet pública fuera de la VPN, deja la lista vacía y elimina los Secretos HTTP que permitan destinos públicos.

4. Guarda los ajustes y prueba los servicios durante la preparación. Publica o vuelve a publicar el entorno y prueba el acceso a destinos aprobados y no aprobados en una tarea nueva. Revisa los scripts de preparación por separado: fija las versiones de las dependencias, da preferencia a los repositorios espejo aprobados y evita descargar ejecutables que no se hayan revisado.

Consulta Conectarse a servicios. La configuración actual de Codex Cloud no incluye el selector de métodos HTTP de la versión heredada.

Configurar Codex Cloud (Legacy)

1. Mantén Desactivado el acceso del agente a internet cuando sea innecesario. La versión heredada bloquea internet de forma predeterminada durante la fase del agente. Los scripts de preparación siguen teniendo acceso a internet para instalar dependencias.

2. Cuando el agente necesite acceso, selecciona Activado y usa una lista reducida de dominios permitidos. Empieza con Ninguno y agrega los dominios exactos.

3. Para flujos de trabajo que solo requieran descargas, permite únicamente GET, HEAD y OPTIONS. Esto bloquea POST, PUT, PATCH, DELETE y otros métodos. Revisa los scripts de preparación por separado porque la restricción de la fase del agente no regula su acceso a internet.

Consulta Acceso del agente a internet en la versión heredada. Estos ajustes predefinidos y controles de métodos HTTP se aplican únicamente a la versión heredada de Codex Cloud.

Configurar Codex local

1. En el archivo requirements.toml gestionado por el administrador, define y selecciona el perfil de red aprobado y limita a los usuarios a ese perfil:

   default_permissions = "corp-build"
   
   [allowed_permission_profiles]
   "corp-build" = true
   
   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"
   
   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false
   
   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Despliega el paquete de requisitos revisado siguiendo las instrucciones de Configuración administrada. Un perfil con nombre no se activa por sí solo. default_permissions lo selecciona y la lista de perfiles permitidos impide seleccionar otros.

3. Activa el proxy gestionado por el administrador en el mismo paquete de requisitos para que se apliquen las restricciones de dominio y los usuarios no puedan ampliar la lista. Despliega juntos el proxy y el perfil con acceso a la red. Sin un proxy activo, ese perfil concede acceso directo a la red sin hacer cumplir sus reglas de dominio:

   Precaución: [experimental_network] es experimental y puede cambiar. Valídalo en cada versión compatible del cliente local y en cada sistema operativo antes de ampliar el despliegue. La compatibilidad con Windows es limitada. Antes de aplicar esta política a usuarios de Windows, comprueba que las restricciones se hagan cumplir en tu entorno.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true
   
   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Mantén desactivada la vinculación a puertos locales salvo que el flujo de trabajo la necesite. Configura por separado el acceso a destinos de red privados. Permitir un dominio no autoriza por sí solo el acceso a sus direcciones privadas. Consulta Requisitos de acceso a la red.

5. Configura por separado la búsqueda web, las apps, los servidores MCP, la actividad del navegador y Codex Cloud. Las reglas del sandbox local no controlan estos casos.

Verificación

• Envía una solicitud a un dominio aprobado y confirma que se complete correctamente.

• Envía una solicitud a un dominio no aprobado y confirma que se bloquee.

• Envía solicitudes a localhost, a una IP privada y a un punto de acceso de metadatos de la nube. Confirma que cada solicitud se bloquee salvo que se haya aprobado explícitamente.

• En Codex Cloud (Legacy), intenta enviar una solicitud POST a un dominio permitido. Confirma que se bloquee cuando solo se permitan GET, HEAD y OPTIONS.

• Confirma que los registros del proxy o de la puerta de enlace contengan entradas tanto para las solicitudes permitidas como para las denegadas.

Revertir los cambios

Vuelve a desactivar el acceso a internet en el entorno o restaura la política de dominios anterior. Evita volver a habilitar el acceso sin restricciones a internet.

Alcance y límites

Una elevación de privilegios aprobada que permita salir por completo del sandbox puede eludir el proxy de comandos local. Antes de confiar en la restricción, prueba por separado los comandos habituales dentro del sandbox y los comandos cuya elevación de privilegios se haya aprobado.

Un dominio permitido puede alojar contenido con inyección de prompts, paquetes comprometidos o documentación insegura.

Usa esta receta cuando Codex necesite acceso a directorios de código fuente aprobados, pero deban quedar fuera de su alcance los secretos, los archivos .env, las claves SSH y los repositorios ajenos a la tarea. Aquí se explica cómo restringir el acceso a los archivos y reducir la cantidad de variables de entorno con credenciales que se pasan a los comandos que se inician.

Resultado esperado

Codex puede trabajar en los directorios de código fuente aprobados, pero no puede leer archivos que suelen contener secretos ni heredar un conjunto amplio de variables de entorno con credenciales.

Configuración

1. Define patrones para denegar la lectura en un perfil del espacio de trabajo:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"
   
   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6
   
   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

2. Agrega las rutas exactas cuyo acceso deba denegarse para los directorios de credenciales conocidos, las claves de firma, la configuración de producción y los repositorios vecinos.

3. En el archivo /etc/codex/config.toml del sistema o ~/.codex/config.toml del usuario, reduce las variables de entorno que se pasan a los comandos que se inician:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false
   
   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

   Este ajuste es un valor predeterminado que el usuario puede configurar y no impone un requisito obligatorio. Reduce las variables heredadas, pero no impide el acceso a archivos de credenciales, programas auxiliares de credenciales, contenido de inicio del shell u otras identidades. Consulta Configuración avanzada.

4. En el archivo requirements.toml gestionado por el administrador, selecciona el perfil restringido y permite únicamente ese perfil. Los perfiles integrados no heredan sus restricciones de lectura de archivos con secretos:

   default_permissions = "corp-workspace"
   
   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Elige cómo se gestionarán las credenciales en tu entorno en la nube:

   • En la versión actual de Codex Cloud, usa Secretos HTTP para las credenciales que se envían a un servicio HTTPS permitido. Los programas reciben un marcador de posición y el proxy lo sustituye por el valor real para los destinos aprobados en el puerto 443 durante la preparación y las tareas. La credencial original no se guarda en ningún proceso ni archivo local. Los programas sí tienen acceso a las variables de entorno que se les pasan directamente. Consulta Variables de entorno y secretos de red.
   • En Codex Cloud (Legacy), los secretos permiten autenticarse durante la preparación y se eliminan antes de la fase del agente. Las variables de entorno se conservan durante todo el chat. Consulta Entornos de la versión heredada de Codex Cloud.

6. Si el agente necesita autenticarse, usa un intermediario independiente que proporcione credenciales de corta duración limitadas al destino y a la acción específicos. Consulta Configuración recomendada.

Verificación

Crea archivos de prueba inocuos:

.env.test
test-key.pem
.aws/credentials
.kube/config

Luego pídele a Codex que haga lo siguiente:

• Leer un archivo normal.

• Leer cada archivo de prueba.

• Buscar secretos de forma recursiva.

• Mostrar el entorno de sus comandos.

• Leer un repositorio vecino.

Resultado esperado: la lectura del archivo normal se completa, los archivos bloqueados y los repositorios vecinos siguen siendo inaccesibles y las variables excluidas no aparecen en el entorno de los comandos.

Revertir los cambios

Restaura el perfil anterior, pero mantén las restricciones sobre archivos que sabes con certeza que contienen secretos mientras investigas los problemas del flujo de trabajo.

Alcance y límites

Las restricciones del sistema de archivos no eliminan los secretos que alguien ya haya pegado en un prompt o incluido en un commit de código accesible, ni los que hayan devuelto los conectores o que figuren en registros que el modelo pueda leer.

Usa esta receta cuando acciones como git push, los despliegues, las migraciones de bases de datos y los comandos de la CLI de la nube necesiten aprobación antes de ejecutarse. Decide qué comandos deben solicitar revisión y cuáles deben prohibirse. Luego configura las reglas correspondientes.

Resultado esperado

Los comandos sensibles siempre se detienen a la espera de aprobación o quedan prohibidos, incluso cuando el modelo considera que son apropiados.

Configuración

1. Decide qué comandos deben solicitar aprobación y cuáles deben prohibirse.

2. Agrega reglas de comandos impuestas por el administrador:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

   Las reglas de los requisitos pueden exigir que se solicite aprobación o prohibir un comando. No pueden autorizarlo. Consulta Configuración administrada.

3. Para los perfiles de alto riesgo, agrega una entrada para los wrappers de shell al mismo arreglo prefix_rules si un wrapper podría ocultar un comando sensible:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

   Esta entrada puede generar muchas solicitudes de revisión. Úsala solo cuando corresponda.

4. Si una persona debe aprobar los comandos, impón estos ajustes:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

   La Revisión automática cambia quién revisa la solicitud. No ofrece una garantía de seguridad determinista. Consulta Revisión automática.

5. Envía los eventos PermissionRequest y los eventos de decisiones y resultados de herramientas a tu sistema de procesamiento de eventos de seguridad.

Verificación

• Ejecuta git status. Resultado esperado: no aparece ninguna solicitud de aprobación.

• Ejecuta git push. Resultado esperado: aparece una solicitud de aprobación.

• Ejecuta terraform apply. Resultado esperado: aparece una solicitud de aprobación.

• Ejecuta kubectl delete pod test. Resultado esperado: aparece una solicitud de aprobación.

• Ejecuta rm -rf test-directory. Resultado esperado: el comando está prohibido.

• Deniega una solicitud de aprobación. Resultado esperado: el comando no se ejecuta y la denegación queda registrada.

• Reinicia el cliente y repite las comprobaciones. Resultado esperado: la regla sigue siendo obligatoria.

Revertir los cambios

Restaura el paquete de requisitos anterior. Si un patrón de tokens es demasiado amplio, hazlo más específico en lugar de eliminar toda una clase de comandos sensibles.

Alcance y límites

Las reglas de prefijos no constituyen un motor completo de políticas del sistema operativo. Combínalas con el aislamiento en un sandbox, cuentas del sistema operativo con los privilegios mínimos, restricciones de red, IAM en la nube, protección de ramas, aprobaciones de despliegues y autorización en la base de datos.

Recetas de configuración que se usan: restringir los perfiles de permisos y el Acceso completo, proteger los secretos y los repositorios ajenos a la tarea y exigir aprobación para comandos sensibles.

Los desarrolladores tienen acceso legítimo al entorno de producción, pero quieres que Codex ayude en el desarrollo sin hacer cambios en producción que no se hayan revisado.

• Define un perfil aprobado para el espacio de trabajo y restringe la selección a los perfiles y las políticas de aprobación permitidos. Distribuye estos ajustes como requisitos impuestos por el administrador para impedir que los usuarios los modifiquen.

• Ejecuta Codex con una identidad independiente que tenga menos privilegios o en un entorno que no pueda acceder a credenciales de escritura en producción ni obtenerlas. Los desarrolladores pueden conservar el acceso a producción mediante un flujo de trabajo autorizado independiente.

• Reduce al mínimo las variables de entorno que se pasan a los comandos que se inician. Si el agente necesita autenticarse, usa un intermediario independiente que proporcione credenciales de corta duración limitadas al destino y a la acción específicos.

• Decide qué comandos deben solicitar aprobación y cuáles están prohibidos. Exige que una persona apruebe determinados comandos de alto impacto, como git push, terraform apply, los cambios en Kubernetes y las migraciones de bases de datos. Prohíbe los comandos que nunca deban ejecutarse.

• Mantén vigentes los controles de IAM en producción, la protección de ramas y las aprobaciones de despliegues de forma independiente de Codex.

Restringir los perfiles de permisos y exigir revisión humana

En el archivo requirements.toml gestionado por el administrador, permite los perfiles integrados de espacio de trabajo y de solo lectura y exige que el usuario revise las acciones que requieran aprobación:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

El perfil de espacio de trabajo permite realizar tareas en ese espacio dentro de su sandbox. El perfil de solo lectura está disponible para tareas de menor alcance. Los perfiles de acceso completo no figuran en la lista de perfiles permitidos.

Establece approval_policy = "on-request" en la configuración del cliente si este necesita que se seleccione explícitamente una opción compatible. Con on-request se puede solicitar aprobación cuando sea necesario, sin solicitarla para cada comando. Agrega reglas explícitas para las acciones que necesiten revisión y conserva la autorización independiente para producción.

Las listas administradas de perfiles permitidos requieren Codex 0.138.0 o posterior. Para clientes anteriores, usa y prueba los requisitos documentados del modo sandbox heredado.

Reinicia cada cliente piloto, verifica que funcione el perfil aprobado y comprueba que se rechace un perfil de acceso completo no permitido.

Separar la identidad de Codex de las credenciales de producción

En el sistema que usas para administrar dispositivos o aprovisionar entornos de desarrollo, crea un usuario, contenedor o host de desarrollo dedicado a Codex que solo tenga acceso al código fuente y a los servicios de desarrollo que necesite. No montes en ese entorno los archivos de credenciales de producción, los programas auxiliares de tokens ni los llaveros del desarrollador. Impide que la identidad adquiera roles con permisos de escritura en producción.

Si el agente necesita acceso a un servicio, configura el intermediario de credenciales de tu organización para que emita credenciales de corta duración limitadas al recurso de desarrollo y a la acción. El desarrollador puede usar su identidad habitual mediante un flujo de trabajo de producción independiente y autorizado.

Por ejemplo, en AWS IAM, abre Roles, selecciona el rol de desarrollo de Codex y, en Permisos, agrega una política en línea revisada como la siguiente. Sustituye la cuenta y el rol por los tuyos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

Este ejemplo deniega los intentos de asumir el rol indicado, pero no los de asumir otros roles. Elimina también los permisos directos de producción, restringe los demás roles de producción y fuentes de credenciales, y revisa las políticas de confianza y los controles de la organización.

Prueba el rol de desarrollo con permisos representativos de desarrollo y de producción sin realizar cambios en producción. Consulta los ejemplos de políticas de roles de AWS IAM.

Reducir al mínimo el entorno del shell

En /etc/codex/config.toml, para una configuración inicial de todo el sistema, o en ~/.codex/config.toml, para un solo usuario, configura qué variables de entorno heredarán los comandos que se inicien:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Este valor predeterminado es configurable y no impone una restricción obligatoria sobre el acceso a credenciales. Los ajustes del usuario, el contenido de inicio o las instantáneas del shell, los programas auxiliares de credenciales y otras fuentes de credenciales aún pueden exponerlas.

En requirements.toml, usa las siguientes restricciones opcionales para deshabilitar los shells de inicio de sesión y las instantáneas del shell si son compatibles con tu flujo de trabajo:

allow_login_shell = false

[features]
shell_snapshot = false

Haz una prueba piloto con estos ajustes porque algunos flujos de trabajo dependen de la inicialización del shell de inicio de sesión.

Inicia Codex con variables sintéticas inocuas que coincidan con los filtros e inspecciona el entorno de un comando que se inicie. Si deshabilitaste los shells de inicio de sesión, verifica también que se rechace una solicitud para iniciar uno. Comprueba de forma independiente que la identidad de ejecución no pueda acceder a credenciales de producción reales. Consulta Política de entorno del shell.

Solicitar aprobación para determinados comandos de alto impacto

Agrega reglas a los requisitos para los comandos que usa tu organización. Por ejemplo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

Usa forbidden para un comando que nunca deba ejecutarse. Sustituye los patrones o agrega otros para las herramientas de despliegue y migración que uses.

Estas reglas comprueban los prefijos de los comandos y no cubren todas las acciones equivalentes. Prueba por separado las rutas absolutas, los wrappers, las variantes en el orden de los argumentos, otros clientes y otras herramientas.

En un destino de prueba que puedas descartar, ejecuta un comando normal, solicita una de las acciones de la lista, deniega la solicitud de aprobación y verifica que la acción no se haya ejecutado. Consulta Aplicar reglas de comandos obligatorias.

Exigir aprobaciones de repositorios y despliegues fuera de Codex

En tu plataforma de control de versiones, protege las ramas de producción como main. Exige que se revisen los cambios y que se obtengan las aprobaciones y se superen las comprobaciones de estado necesarias. Revisa qué roles pueden eludir esos requisitos. Configura la aprobación de despliegues en el sistema de despliegue correspondiente y los privilegios de la base de datos en la propia base de datos.

Usa un repositorio que puedas descartar para verificar que se acepte un cambio revisado y que se rechace un push directo no autorizado. Estos controles se aplican independientemente de si la acción se solicitó a través de Codex.

Verificación

En un destino de prueba que puedas descartar:

• Ejecuta una tarea habitual del espacio de trabajo. Resultado esperado: la tarea se completa correctamente.

• Intenta ejecutar un comando sensible representativo y deniega la solicitud de aprobación. Resultado esperado: el comando denegado no se ejecuta.

• Verifica que la identidad de Codex no pueda obtener acceso de escritura en producción.

• Reinicia el cliente y repite las comprobaciones.

Alcance y límites

Las reglas de prefijos no constituyen un motor completo de políticas del sistema operativo. Combínalas con el aislamiento en un sandbox, cuentas del sistema operativo con los privilegios mínimos, restricciones de red, IAM en la nube, protección de ramas, aprobaciones de despliegues y autorización en la base de datos.

Recetas de configuración que se usan: proteger los secretos y los repositorios ajenos a la tarea, restringir los destinos de red, permitir solo servidores MCP aprobados y exigir aprobación para comandos sensibles.

Los desarrolladores usan Codex con repositorios internos y quieres reducir el riesgo de que se envíe código a un repositorio público, se publique como fragmento de código de acceso público o se transfiera a otro destino no aprobado.

• Agrega las rutas exactas cuyo acceso deba denegarse para los directorios de credenciales conocidos y los repositorios ajenos a la tarea. Reduce al mínimo las variables de entorno que se pasan a los comandos que se inician.

• Cuando el agente necesite acceso a internet, usa una lista reducida de dominios aprobados. Permite únicamente los nombres e identidades de servidores MCP aprobados y exige revisión para determinados comandos de publicación, como git push, o deniégalos.

• Usa hooks y permisos de control de versiones, políticas para repositorios y fragmentos de código públicos, y controles de prevención de pérdida de datos adecuados para tu organización.

Denegar el acceso a repositorios ajenos a la tarea y archivos de credenciales

En el archivo requirements.toml gestionado por el administrador, agrega las rutas exactas que el agente local no deba leer:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

Sustituye las rutas de ejemplo por rutas que existan en tus dispositivos administrados. Esta restricción administrada se aplica a todos los perfiles de permisos admitidos. Una restricción configurada únicamente dentro de un perfil personalizado no protege a los usuarios que seleccionen otro perfil. Da preferencia a las rutas exactas conocidas y prueba los patrones glob en los niveles de profundidad que necesites.

En Windows nativo, el ajuste administrado deny_read cubre las herramientas que acceden directamente a los archivos, pero por sí solo no impide que los subprocesos del shell los lean. Usa también identidades del sistema operativo y listas de control de acceso a archivos.

Crea archivos de prueba inocuos en las ubicaciones bloqueadas. Con cada perfil permitido, verifica que se deniegue la lectura de esos archivos tanto directamente como desde el shell y que se pueda leer un archivo de código fuente aprobado. Consulta Requisitos administrados para denegar la lectura.

Reducir al mínimo las variables del shell que contienen credenciales

En /etc/codex/config.toml o ~/.codex/config.toml, limita las variables de entorno que se heredan:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

Este ajuste reduce las variables heredadas, pero el usuario puede configurarlo y no impide el acceso a archivos de credenciales, programas auxiliares de credenciales, contenido de inicio del shell u otras identidades.

Cuando corresponda, un administrador también puede agregar estas restricciones a requirements.toml y probarlas en un grupo piloto para evaluar cómo afectan a los flujos de trabajo de los desarrolladores:

allow_login_shell = false

[features]
shell_snapshot = false

Haz las pruebas con variables sintéticas y una identidad de ejecución independiente con los privilegios mínimos. No uses credenciales reales. Consulta Política de entorno del shell.

Permitir solo destinos de red aprobados para los comandos locales

Si los comandos locales que se ejecutan en el sandbox necesitan acceso a la red, integra en requirements.toml tanto la configuración del perfil como la del proxy administrado que aparecen a continuación. Sustituye los dominios por puntos de acceso aprobados:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

El perfil con acceso a la red permite que el comando ejecutado en el sandbox se conecte a la red y el proxy administrado restringe sus destinos. Despliégalos juntos. Sin el proxy administrado previsto, un perfil con acceso a la red no aplica las mismas restricciones de destino. Si el acceso a internet es innecesario, mantén deshabilitado el acceso a la red.

No combines la tabla canónica domains con los ajustes heredados allowed_domains o denied_domains. Migra la política existente y pruébala.

Reinicia el cliente y verifica que funcione un punto de acceso aprobado y que se bloquee uno no aprobado.

Estos ajustes son experimentales. Valida la compatibilidad del sistema operativo y del cliente y configura por separado el acceso a redes privadas si el nombre de un host aprobado se resuelve en una dirección privada. Una elevación de privilegios aprobada que permita salir por completo del sandbox puede eludir el proxy de comandos.

Este control de red para comandos locales no cubre por sí solo la búsqueda web, las apps, los servidores MCP, la actividad del navegador ni los entornos en la nube. Estos requieren políticas independientes. Un dominio de alojamiento aprobado también puede contener repositorios o fragmentos de código públicos, por lo que una lista de destinos permitidos no basta para proteger el contenido. Consulta Requisitos de acceso a la red.

Configurar por separado la red del entorno en la nube

En la interfaz actual de Codex Cloud, abre la configuración del entorno. Desactiva Habilitar todo el acceso a internet pública y Habilitar dominios de gestores de paquetes. Si necesitas acceso a internet pública, agrega los nombres exactos de los hosts aprobados en Dominios permitidos adicionales. Elimina los Secretos HTTP que permitan destinos públicos no aprobados. Para bloquear el acceso a internet pública fuera de la VPN, deja la lista vacía y elimina los Secretos HTTP que permitan destinos públicos. Guarda la configuración, publica o vuelve a publicar el entorno y prueba una tarea nueva.

Revisa de forma independiente la autenticación y las capacidades de los servicios.

La versión heredada de Codex Cloud tiene un ajuste independiente de acceso del agente a internet para cada entorno, con controles para los dominios permitidos y los métodos HTTP. Los scripts de preparación se rigen por sus propias condiciones de acceso.

Prueba la versión del entorno que usas. Consulta Conectarse a servicios y Configuración de internet de la versión heredada.

Restringir los servidores MCP y solicitar aprobación antes de un push de Git

Permite únicamente las identidades aprobadas de servidores MCP locales en requirements.toml. Por ejemplo:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

Configura el servidor por separado en el archivo config.toml del usuario o de valores predeterminados administrados. Usa el nombre y la URL que coincidan con la entrada aprobada y la autenticación que requiera el servidor:

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

El requisito solo permite usar un servidor que coincida con la entrada, sin crearlo. Revisa el acceso y las herramientas del propio servidor.

Verifica que el servidor aprobado pueda conectarse y que no se permita un servidor con otro nombre o URL.

Agrega una regla de comandos administrada que solicite revisión antes de ejecutar un comando de publicación representativo:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Si la revisión debe hacerla una persona, combina esta regla con allowed_approval_policies = ["on-request"] y allowed_approvals_reviewers = ["user"] como requisitos de nivel superior.

Deniega un push de prueba y confirma que no se ejecute.

La comprobación de prefijos no cubre todos los wrappers, clientes de API, apps ni vías alternativas de publicación.

Restringir la publicación de contenido público mediante el control de versiones y la prevención de pérdida de datos

En tu plataforma de control de versiones, restringe la creación de repositorios públicos y limita quién puede cambiar la visibilidad de un repositorio cuando la plataforma lo permita. Revisa qué usuarios privilegiados pueden eludir esas restricciones. Comprueba por separado las cuentas personales, los fragmentos de código, las organizaciones externas y el acceso mediante tokens, ya que los ajustes de la organización no regulan todos los destinos.

En el repositorio correspondiente, exige que se revisen los cambios y verifica la protección de ramas y los permisos que permiten eludirla.

En la consola de prevención de pérdida de datos (DLP) de tu organización, configura una política piloto para el código fuente sensible y los canales de carga o de repositorio que cubra tu producto DLP. Configura la acción de bloqueo y pruébala con un marcador sintético inerte.

Cuando la plataforma de control de versiones admita controles del lado del servidor, configura hooks revisados y hazlos obligatorios para los repositorios que reciban pushes.

Usa destinos de prueba autorizados y confirma el bloqueo antes de que se publique contenido.

Verificación

• Crea archivos de prueba inocuos y confirma que fallen los intentos de leer archivos bloqueados.

• Si el acceso a la red está habilitado, comprueba que se pueda acceder a un destino aprobado y que se bloquee uno no aprobado. De lo contrario, verifica que se bloqueen las solicitudes de red.

• Con un marcador inocuo y cuentas o destinos de prueba que puedas descartar, verifica con intentos representativos que se bloquee la publicación antes de que el contenido sea público.

Alcance y límites

Un dominio permitido puede alojar contenido público. Configura por separado la búsqueda web, las apps, los servidores MCP, la actividad del navegador y Codex Cloud. Las reglas del sandbox local no controlan estos casos.

Recetas de configuración que se usan: restringir los perfiles de permisos y el Acceso completo, permitir solo servidores MCP aprobados, restringir los destinos de red, proteger los secretos y los repositorios ajenos a la tarea y exigir aprobación para comandos sensibles.

Quieres que las restricciones que rigen el uso de Codex sigan vigentes cuando Codex trabaje en un repositorio o un usuario cambie la configuración local.

• Distribuye las restricciones admitidas de permisos, aprobaciones, MCP, red y comandos como requisitos impuestos por el administrador.

• Instala los scripts de los hooks en un directorio gestionado por el administrador y usa solo hooks administrados si se deben ignorar los hooks de usuarios, proyectos y complementos.

• Protege los archivos de las políticas y el canal de distribución de la configuración con controles del sistema operativo y de administración de dispositivos. Ejecuta Codex sin los privilegios necesarios para modificar esas protecciones.

• Revisa la configuración efectiva de cada cliente y entorno al que se aplican los controles.

Hacer cumplir las restricciones de perfiles, aprobaciones, identidades de servidores y comandos

Integra los ajustes revisados en el archivo requirements.toml gestionado por el administrador para evitar depender de los ajustes editables de un usuario o repositorio. Por ejemplo:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

Este ejemplo permite dos perfiles, exige revisión humana cuando se necesita aprobación, permite una identidad MCP que coincida con la entrada y solicita aprobación para un prefijo de comando específico.

Configura el propio servidor MCP por separado y agrega los demás patrones de comandos sensibles de la organización. Agrega restricciones globales de archivos y restricciones de red cuando sea necesario. Los requisitos limitan los ajustes compatibles, pero no sustituyen los controles de identidad, servicios y destinos externos a Codex.

Las listas administradas de perfiles permitidos requieren Codex 0.138.0 o posterior.

En un cliente piloto, intenta seleccionar un perfil no permitido, cambiar un ajuste restringido de usuario o de proyecto y usar una identidad MCP que no figure en la lista de permitidas. Comprueba que cada intento se rechace o que la restricción siga vigente después del reinicio. Deniega la solicitud de aprobación de un comando de prueba y verifica que no se ejecute.

Agregar restricciones administradas del sistema de archivos y de la red

Para denegar la lectura de archivos locales sensibles en todos los perfiles permitidos, agrega la siguiente tabla a requirements.toml y sustituye las rutas de ejemplo por las de tu organización:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

Cuando los comandos locales que se ejecutan en el sandbox necesiten acceso a la red, define conjuntamente un perfil permitido con acceso a la red y los destinos administrados:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

Usa esta política de perfiles en lugar del valor predeterminado anterior :workspace, o integra ambos nombres de perfil de forma deliberada. No pegues claves ni tablas duplicadas. Si los comandos no necesitan acceso a la red, mantenlo deshabilitado.

Verifica las rutas exactas bloqueadas con archivos inocuos y comprueba los destinos aprobados y no aprobados.

En Windows nativo, usa también listas de control de acceso a archivos porque el ajuste administrado deny_read por sí solo no cubre las lecturas de los subprocesos del shell.

La configuración de red de los comandos locales no regula otros clientes, apps, conectores ni la ejecución en la nube.

Instalar hooks administrados y exigir su uso

Pide a un administrador que instale un programa de hook revisado en un directorio administrado por root, por ejemplo, en /etc/codex/hooks/pre_tool_use_policy.py, y que impida que el usuario de Codex modifique el archivo o su directorio. En requirements.toml, habilita los hooks y configura el cliente para que ignore los hooks de usuarios, proyectos, sesiones y complementos:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

El requisito registra el hook, pero no lo instala. Para una prueba de integración local en macOS, guarda el siguiente código como pre_tool_use_policy.py y pide a un administrador que lo instale con los comandos que aparecen más abajo.

El código bloquea únicamente el marcador sintético. Antes de confiar en él, sustitúyelo por una política revisada específica de tu organización. Confirma que /usr/bin/python3 exista en el equipo de destino y ajusta la ruta del intérprete si es necesario:

1
2
3
4
5
6
7
8import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Reinicia el cliente local y haz lo siguiente:

• Confirma que se ejecute un comando de Bash inocuo.

• Confirma que se bloquee un comando que contenga CODEX_HOOK_TEST_DENY.

• Verifica que el usuario de Codex no pueda modificar la política ni las dependencias.

allow_managed_hooks_only omite todos los hooks no administrados de usuarios, proyectos, sesiones y complementos, lo que puede afectar a otros flujos de trabajo.

El patrón de coincidencia de Bash no cubre todas las herramientas ni todas las entradas que se proporcionen posteriormente a un proceso existente. Los errores, los tiempos de espera agotados o las respuestas mal formadas del hook pueden permitir que continúe una llamada a una herramienta.

Cuando se orquesta desde la nube, el modo Work admite otros controladores de hooks. Mantén protecciones independientes en el sistema operativo y en los servicios. Consulta Hooks administrados y Comportamiento de los hooks.

Proteger la política y su distribución

En macOS, un administrador puede desplegar un archivo de requisitos revisado y consolidado en un directorio superior propiedad de root e impedir que el usuario de Codex escriba en el archivo:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

En Linux, usa el grupo de administradores correspondiente. En Windows, protege el directorio ProgramData y el archivo con listas de control de acceso gestionadas por el administrador. Limita quién puede cambiar la política de MDM o de la nube, revisa los cambios y conserva una copia para poder restaurarla.

Con una cuenta piloto sin privilegios de administrador, comprueba que no puedas modificar la política, el directorio superior ni el programa del hook administrado. Prueba un ajuste de usuario o de proyecto menos restrictivo, reinicia Codex y verifica que se sigan aplicando las restricciones obligatorias.

Prueba cada cliente y entorno al que se aplican los controles. No des por hecho que todos los clientes cargan la misma política.

Verificación

Con una identidad de prueba sin privilegios de administrador:

• Intenta editar la política administrada. Resultado esperado: no puedes modificar el archivo administrado.

• Intenta debilitar una restricción mediante la configuración del usuario o del proyecto. Resultado esperado: los ajustes menos restrictivos se rechazan o siguen sujetos a la restricción.

• Reinicia el cliente y verifica que las restricciones sigan vigentes.

Alcance y límites

Un usuario o agente con suficientes privilegios de administrador en el host podría modificar las protecciones del entorno. Los ajustes editables por el usuario no sustituyen por sí solos los requisitos gestionados por el administrador.