Configuración administrada

La configuración administrada permite a los administradores de empresas establecer requisitos y valores predeterminados compatibles con ChatGPT Work y Codex. Los requisitos limitan lo que pueden hacer los usuarios y las tareas. Los valores predeterminados definen la configuración inicial. La compatibilidad depende del producto, de la versión del cliente y del entorno de ejecución.

Para los ajustes que se pueden administrar desde la nube, empieza en Seguridad del agente, en la consola de administración. Usa los controles de configuración para las tareas habituales o selecciona Editar como TOML para inspeccionar, copiar o editar el texto de la configuración. Ambas vistas permiten editar la misma política. TOML también da acceso a campos compatibles que no tienen un control específico. No necesitas distribuir un archivo local para usar ajustes administrados desde la nube. Las restricciones de autenticación y las implementaciones administradas en los dispositivos tienen una configuración local independiente.

Los administradores de empresas pueden controlar el comportamiento de los clientes locales compatibles mediante estas opciones:

• Requisitos: restricciones que imponen los administradores y que los usuarios no pueden anular.

• Valores predeterminados de configuración: ajustes de config.toml administrados por el sistema o desde la nube que los usuarios pueden modificar.

• Valores predeterminados administrados heredados: valores iniciales de managed_config.toml que se aplican cuando se inicia un cliente compatible. Los usuarios pueden cambiar los ajustes durante la ejecución. El cliente vuelve a aplicar estos valores predeterminados la próxima vez que se inicia.

Consulta Seguridad del agente para conocer la configuración base de Global, las excepciones por entorno y las listas de campos del orquestador y del ejecutor.

Si tus usuarios no inician sesión en Codex con ChatGPT, puedes distribuir valores predeterminados y requisitos a Codex CLI y a la app de escritorio desde un punto de acceso HTTPS que tú administres. Consulta Alojar la configuración de Codex para tu equipo.

Configurar una política en Seguridad del agente

En los espacios de trabajo que tienen habilitada la función Seguridad del agente, los propietarios del espacio de trabajo, sus administradores y los miembros con permisos de administrador de Codex pueden administrar políticas. Tener acceso al editor de políticas no les da a los miembros acceso a las funciones que controla una política.

Usa Configuración predeterminada del espacio de trabajo para establecer la configuración base del espacio de trabajo. Usa Excepciones cuando determinados usuarios, grupos o roles necesiten ajustes diferentes. Una excepción por destinatario determina quién recibe una política. Un ajuste de entorno determina dónde se aplican los controles de ejecución compatibles.

1. Abre Consola de administración > Seguridad del agente y selecciona Configuración predeterminada del espacio de trabajo o la política que quieras editar en Excepciones.
2. Abre Requisitos para imponer límites o Valores predeterminados para definir valores iniciales que los miembros puedan cambiar dentro de esos límites.
3. Mantén la aprobación, la búsqueda web y los demás ajustes que afectan a todo el agente en Global. Cuando esté disponible, usa Agregar ajustes de entorno en la tarjeta correspondiente para agregar Entornos locales o Entornos de Codex Cloud y configurar los ajustes de ejecución compatibles. Un documento de entorno vacío hereda los ajustes de Global sin copiar ni fijar la configuración base actual.
4. Usa los controles que se describen en esta guía. Para los campos avanzados, selecciona Editar como TOML y edita el archivo requirements.toml o config.toml del ámbito correspondiente. Selecciona Usar controles de configuración para volver al editor visual.
5. Revisa los mensajes de validación y selecciona Guardar cambios. Al aplicar una regla en el editor de reglas, se actualiza el borrador. Aún debes guardar la política.
6. Comprueba qué política se selecciona y cómo se comporta el cliente compatible según se describe en Verificar la experiencia de los administradores y los empleados.

Los editores de entorno y los campos compatibles dependen del espacio de trabajo y de la política. Consulta Dónde se aplican los ajustes antes de mover un ajuste de Global a un entorno. Un ajuste de Global no necesariamente se aplica a todos los productos o modos de ejecución.

Copiar o reutilizar una configuración

El editor visual no reemplaza TOML. Selecciona Editar como TOML para copiar una configuración, guardar una copia de referencia o reutilizar ajustes en otra política. Selecciona Usar controles de configuración para volver al editor visual.

1. Abre la política de origen y selecciona Editar como TOML.
2. Elige el ámbito que quieras copiar: Global o una de las pestañas de entorno disponibles. Copia el texto de Requisitos (requirements.toml), de Valores predeterminados (config.toml) o de ambos, según lo que quieras reutilizar.
3. Abre la política de destino, selecciona Editar como TOML y elige el mismo ámbito. Pega los requisitos en requirements.toml y los valores predeterminados en config.toml. Antes de reemplazar el texto, revisa los ajustes existentes en el destino y conserva los demás ajustes que deban seguir vigentes.
4. Revisa los mensajes de validación, los destinatarios y la prioridad de la política de destino. Luego selecciona Guardar cambios. Comprueba cómo se comporta el cliente antes de depender de la política copiada.

El texto copiado contiene los ajustes definidos para esa política y ese ámbito. No incluye las asignaciones, el orden de las políticas, los documentos de otros entornos ni la configuración efectiva que resulta de combinar otras políticas y ajustes del dispositivo. Si necesitas copiar los ajustes de otros entornos, hazlo por separado. Cambiar de vista o copiar texto no guarda los cambios en la política.

Prueba el siguiente ejemplo: cambia un ajuste y selecciona Editar como TOML para ver su configuración. Vuelve con Usar controles de configuración para seguir probando.

Elegir el control adecuado

Controlar el navegador y el uso de la computadora

Usa Seguridad del agente en la consola de administración para gestionar el acceso al navegador y a las apps nativas en los clientes de escritorio compatibles. Empieza con los controles de la interfaz. Los ejemplos de TOML que aparecen más adelante sirven de referencia para distribuir políticas mediante archivos y para configurar ajustes que requieren el editor TOML.

La función Navegador controla la actividad del agente en un navegador. Uso de la computadora controla la actividad del agente en apps de escritorio nativas. Los ajustes del panel del navegador integrado son independientes de la función Navegador. Consulta Sesiones del navegador e inicios de sesión existentes para conocer las diferencias entre las formas de acceder al navegador.

Antes de empezar

Usa una cuenta con permiso para administrar políticas de Seguridad del agente. Confirma quiénes reciben la política y qué versiones del cliente y sistemas operativos necesitas admitir. Consulta Seguridad del agente para conocer las asignaciones de políticas, los ajustes de Global y las excepciones por entorno compatibles.

Usa Requisitos para imponer límites que los usuarios no puedan anular. Los Valores predeterminados definen los valores iniciales dentro de esos límites. Permitir un sitio o una app no instala un complemento, no otorga permisos del sistema operativo, no inicia la sesión del usuario ni aprueba una acción que aún requiere revisión.

En Disponibilidad de funciones de escritorio, revisa Navegador, Uso de un navegador externo y Uso de la computadora. Forzar desactivación deshabilita la función correspondiente, incluso si hay una regla que permite el acceso a un sitio o una app. Revisa Acceso completo a CDP por separado. Bloquear activación por el usuario impide que los usuarios lo habiliten.

Estos controles de escritorio no configuran el navegador alojado de Work Cloud. Administra Uso del navegador en la nube y Acceso a la red en la nube por separado en Consola de administración > Permisos y roles > Capacidades del espacio de trabajo > Capacidades de la computadora en la nube. Consulta Cómo se aplica Seguridad del agente a Work Cloud.

Configurar el acceso al navegador

1. Abre Consola de administración > Seguridad del agente. Usa Configuración predeterminada del espacio de trabajo para la configuración base del espacio de trabajo o abre la política correspondiente en Excepciones. En Requisitos, ve a Controles del navegador de escritorio.
2. En Reglas de sitios, abre las acciones de la fila Predeterminada y elige Editar regla predeterminada. Para limitar el acceso a sitios aprobados, establece Acceso al sitio en Bloquear y elige Aplicar regla. La fila Predeterminada proporciona los valores que una regla de sitio coincidente deja en Usar regla predeterminada.
3. Elige Agregar regla de sitio. En Sitio o patrón, ingresa un origen que incluya un esquema, un nombre de host y, opcionalmente, un puerto. Por ejemplo, https://example.com es válido, pero https://example.com/files no lo es. No incluyas rutas, consultas ni fragmentos. HTTP y HTTPS corresponden a orígenes distintos. Especifica el puerto cuando difiera del predeterminado para el esquema.
4. Configura Acceso al sitio y revisa Descargas, Cargas y Depuración/CDP. Elige Permitir o Bloquear según corresponda, o deja el ajuste en Usar regla predeterminada. Depuración/CDP controla el acceso completo al protocolo Chrome DevTools para depurar el navegador. Permitir deja que continúen las comprobaciones habituales de políticas y aprobaciones.
5. Revisa Revisión automática, Permitir siempre y Duración de la aprobación para el sitio. Duración de la aprobación ofrece las opciones Este turno y Este hilo. Revisa también Historial del navegador, Guardar aprobaciones de sitios y Aprobar solicitudes automáticamente en Controles del navegador de escritorio.
6. Elige Agregar regla, revisa los mensajes de validación y selecciona Guardar cambios. Prueba un sitio permitido y otro bloqueado en un cliente compatible que reciba la política. Prueba por separado las cargas, las descargas y las demás acciones restringidas.

Agregar regla de sitio

La fila Predeterminada se aplica cuando una regla de sitio deja un permiso en Usar regla predeterminada. Si las reglas se superponen, Bloquear tiene prioridad para cada permiso.

Sitio o patrón 

Acceso al sitioUsar regla predeterminada

DescargasUsar regla predeterminada

CargasUsar regla predeterminada

Depuración/CDPUsar regla predeterminada

Revisión automáticaUsar regla predeterminada

Permitir siempreUsar regla predeterminada

Duración de la aprobaciónUsar regla predeterminada

Si deshabilitas la función Revisión automática para las acciones del navegador, esas acciones se envían al usuario para que las apruebe. El monitoreo de seguridad del modelo sigue activo.

Cuando coinciden varios patrones de origen, prevalece el valor más restrictivo para cada ajuste. La configuración local no puede flexibilizar una denegación administrada. Las reglas de denegación de red administradas y las listas exclusivas de destinos permitidos también se aplican a las herramientas del navegador. Consulta los campos de la política del navegador para conocer los patrones de origen y el comportamiento de las aprobaciones.

La función Uso de la computadora también puede operar un navegador como app nativa. Las reglas de sitios y capacidades de la función Navegador no se aplican a esta vía de acceso. Revisa el acceso a las apps nativas por separado. Consulta los límites de seguridad del navegador.

Configurar el acceso a apps nativas

1. En Requisitos, ve a Controles de apps de escritorio > Reglas de apps.
2. Usa las acciones de la fila Predeterminada para configurar el acceso a las apps que no tengan una regla coincidente. Para limitar el uso de la computadora a las apps aprobadas, bloquea el acceso de forma predeterminada y agrega reglas que permitan el acceso a esas apps.
3. Elige Agregar regla de app. En el cuadro de diálogo Editar regla, selecciona ID de paquete de macOS, AUMID de Windows o Ejecutable de Windows en App. En Identificador de la app, ingresa el ID de paquete exacto o el identificador de modelo de usuario de la aplicación (AUMID) exacto. Para Ejecutable de Windows, ingresa el Nombre del editor y el Nombre del producto. El Nombre del binario es opcional. Usa información verificada sobre la identidad de la app. El nombre visible y la ruta del archivo no sirven para identificarla.
4. Configura el Acceso a la app para la regla y elige Agregar regla. Revisa Guardar aprobaciones de apps en Controles de apps de escritorio, revisa los mensajes de validación y selecciona Guardar cambios. Aunque deshabilites las aprobaciones guardadas, se pueden conceder aprobaciones para la sesión actual. Permitir que se guarden aprobaciones no aprueba ninguna app.
5. Prueba una app permitida y otra bloqueada en cada sistema operativo compatible de tu implementación. Confirma que los permisos del sistema operativo se sigan aplicando y que los usuarios aún deban dar las aprobaciones requeridas.

Editar regla

Define el acceso predeterminado a las apps y cámbialo para las apps que coincidan con una regla.

AppID de paquete de macOS

Identificador de la app 

Acceso a la appElegir acceso

Consulta los campos de la política de uso de la computadora para conocer los requisitos de identidad de Windows y las restricciones de uso con la computadora bloqueada para las Mac administradas.

Comprobar la política efectiva

Si un sitio o una app permitidos siguen bloqueados, revisa las demás reglas coincidentes, las asignaciones y la prioridad de las políticas, los requisitos del dispositivo y la configuración del usuario. Una regla que permite el acceso en una fuente no anula una denegación aplicable de otra fuente. Consulta Ubicaciones y precedencia de los requisitos.

Si un ajuste no surte efecto, comprueba que sea compatible con el cliente, el sistema operativo y el mecanismo de distribución de la política. Presta especial atención a Work Cloud con acceso a la computadora local, ya que algunos campos tienen compatibilidad parcial o requieren validación. Consulta la compatibilidad con el modo Work en la referencia de configuración.

Si un usuario no puede acceder a la función o al complemento necesario, comprueba por separado los permisos del espacio de trabajo y los controles de complementos.

Referencia de configuración TOML

Los siguientes ejemplos muestran cómo expresar las mismas políticas en requirements.toml. Úsalos cuando administres políticas mediante archivos o con el editor TOML. No necesitas editar un archivo local para usar los controles disponibles en Seguridad del agente.

Este ejemplo de navegador deniega el acceso de forma predeterminada, permite acceder a https://example.com, bloquea las cargas y el acceso completo a CDP en ese sitio y limita la aprobación de acceso al sitio al turno actual:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Para deshabilitar la función Revisión automática para las acciones del navegador, configura browser_use.disable_auto_review = true. Para restringirla en un origen específico, establece auto_review = "deny" en la política de ese origen.

En los planes administrados que cumplan los requisitos, deja browser_use.allow_webmcp sin configurar o establece su valor en true para que la política del espacio de trabajo permita usar las herramientas de sitios en el navegador integrado de la app de escritorio. Establece el valor en false para desactivar el acceso que otorga esta política. Los usuarios que ya tengan acceso porque la función se habilitó en sus cuentas pueden seguir usando las herramientas de sitios. También se aplican las condiciones de compatibilidad del modelo, los ajustes del navegador y los permisos de los sitios.

Este ejemplo de apps nativas permite usar la Calculadora en macOS, deniega las demás apps de forma predeterminada e impide que las aprobaciones de apps se conserven entre sesiones:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Las políticas de Windows pueden identificar apps empaquetadas mediante computer_use.windows.aumids o ejecutables mediante computer_use.windows.exes. Las reglas de ejecutables requieren publisher_name, product_name y access. El campo binary_name es opcional.

Para consultar todos los campos y valores compatibles, usa la referencia de requirements.toml. Si quieres deshabilitar una capacidad completa en lugar de restringir sitios o apps individuales, consulta Fijar indicadores de funciones.

Otros controles de escritorio

Los siguientes controles de escritorio abarcan la disponibilidad de funciones, el uso con la computadora bloqueada, las capturas de apps y el control remoto del dispositivo. Usa los ajustes específicos para la disponibilidad de funciones y el uso con la computadora bloqueada. Configura las capturas de apps y el control remoto del dispositivo con Editar como TOML. Para restringir los destinos del tráfico de la app de escritorio, consulta Controlar los destinos de red de la app de escritorio.

Fijar indicadores de funciones

Para las funciones de escritorio disponibles en Seguridad del agente, abre Global > Requisitos > Disponibilidad de funciones de escritorio. Establece Navegador integrado, Navegador, Uso de un navegador externo o Uso de la computadora en Forzar desactivación para deshabilitar la capacidad correspondiente y selecciona Guardar cambios. Para Acceso completo a CDP, elige Bloquear activación por el usuario para impedir que los usuarios lo habiliten. Permitir una función no modifica su disponibilidad según el producto, la plataforma o la etapa de lanzamiento.

Para otros indicadores de funciones compatibles, usa Editar como TOML y el documento requirements.toml de Global, o una fuente compatible de requisitos locales. Los siguientes ejemplos fijan valores para funciones del entorno de ejecución y funciones específicas de escritorio:

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Usa las claves canónicas de funciones de config.toml, en la tabla [features], para las funciones del entorno de ejecución. El entorno de ejecución local ajusta las funciones reconocidas para respetar los valores fijados y rechaza los cambios incompatibles en config.toml o en los ajustes de funciones de los archivos de perfil.

El ajuste administrado unified_exec = false mantiene disponible la ejecución de comandos, pero deshabilita los procesos que se pueden reanudar y la herramienta write_stdin. La configuración del usuario no puede deshabilitar esta función.

• in_app_browser = false deshabilita el panel del navegador integrado.
• in_app_updates = false deshabilita el actualizador propio de la app de escritorio de ChatGPT al reiniciarla, donde sea compatible. No afecta la distribución externa de paquetes ni extiende la compatibilidad con versiones anteriores de la app. Para obtener instrucciones de configuración e implementación, consulta Administrar las actualizaciones de la app.
• browser_use = false deshabilita las capacidades compatibles de la función Navegador. El uso de un navegador externo y el uso de la computadora con apps nativas tienen controles independientes.
• browser_use_full_cdp_access = false deshabilita el acceso completo a CDP en el entorno de ejecución local, incluido el modo de desarrollador del navegador, e impide que la app de escritorio de ChatGPT habilite el ajuste correspondiente.
• browser_use_external = false deshabilita el uso del navegador por parte del agente mediante extensiones de navegador compatibles.
• computer_use = false deshabilita el uso de la computadora con apps nativas, incluido el uso de un navegador como app nativa, además de la grabación y reproducción y los procesos de instalación o configuración relacionados.

Deshabilitar solo la función Navegador no bloquea todas las vías de acceso al navegador. La función Uso de la computadora puede seguir operando un navegador como app nativa si se permiten tanto esa capacidad como el acceso a la app. Las reglas de sitios y capacidades de la función Navegador no se aplican a esa vía. Para bloquearla, establece Uso de la computadora en Forzar desactivación (computer_use = false) o deniega el acceso a la app del navegador en Reglas de apps si otras apps nativas deben seguir disponibles. Revisa Uso de un navegador externo y Navegador integrado por separado. Consulta Sesiones del navegador e inicios de sesión existentes para conocer los controles aplicables a cada vía.

Si omites estas claves, la política permite las funciones, sujetas a su disponibilidad habitual según el cliente, la plataforma y la etapa de lanzamiento.

Restringir el uso de la computadora bloqueada

Para impedir que los usuarios habiliten el uso con la computadora bloqueada en una Mac administrada, abre Global > Requisitos > Controles de apps de escritorio, establece Permitir el uso con la computadora bloqueada en Deshabilitado y selecciona Guardar cambios. Este ajuste no desactiva el uso con la computadora bloqueada en una Mac donde ya esté habilitado.

El requisito equivalente para el editor TOML o la distribución administrada en los dispositivos es:

[computer_use]
allow_locked_computer_use = false

Este requisito quita los controles que permiten habilitar el uso con la computadora bloqueada. No desactiva la función si ya está habilitada. Si lo omites, siguen vigentes la disponibilidad habitual del producto y el ajuste local del usuario.

Deshabilitar las capturas de apps

La función de capturas de apps permite que los clientes compatibles incluyan instantáneas de las aplicaciones. Para deshabilitarla para los usuarios administrados desde la nube, abre Editar como TOML en Seguridad del agente y configura el campo de nivel superior allow_appshots en el documento requirements.toml de Global. Para las implementaciones administradas en los dispositivos, usa la fuente de requisitos locales correspondiente:

allow_appshots = false

Donde estén disponibles las capturas de apps, allow_appshots = false las deshabilita. Si omites la clave, los requisitos no restringen las capturas de apps y se aplican las comprobaciones habituales de disponibilidad del producto. Los clientes de App Server que leen los requisitos efectivos mediante configRequirements/read reciben la misma restricción en allowAppshots. Si se omite el valor o se usa null en allowAppshots, las capturas de apps no se deshabilitan.

Deshabilitar el control remoto del dispositivo

Para deshabilitar el control remoto del dispositivo para los usuarios administrados desde la nube, usa Editar como TOML en Seguridad del agente y configura el campo de nivel superior allow_remote_control en el documento requirements.toml de Global. También puedes configurar allow_remote_control en una fuente compatible de requisitos locales:

allow_remote_control = false

En los dispositivos compatibles con el control remoto, allow_remote_control = false lo deshabilita. Si omites la clave, los requisitos no restringen el control remoto del dispositivo y se aplican las comprobaciones habituales de disponibilidad del producto. Este requisito no deshabilita las conexiones remotas por SSH.

Configurar las aprobaciones y los permisos de ejecución

Usa esta sección para definir cómo funcionan las aprobaciones, los límites de los permisos y los valores iniciales. Empieza con Límites de la política y Valores predeterminados. Las tareas siguientes explican los requisitos TOML para exigir un revisor, definir perfiles de permisos personalizados, restringir el sistema de archivos, establecer excepciones por host y aplicar reglas de comandos.

Requisitos impuestos por el administrador (requirements.toml)

Los requisitos limitan ajustes que afectan la seguridad, como la política de aprobación, el revisor de aprobaciones, la política de Revisión automática, el modo de sandbox, los perfiles de permisos, el modo de búsqueda web, los hooks administrados, los servidores MCP que pueden habilitar los usuarios y las fuentes de marketplaces de complementos que pueden usar. El cliente local determina la configuración, por ejemplo, a partir de config.toml, de archivos de perfil o de ajustes especificados en la CLI. Si un valor entra en conflicto con una regla obligatoria, el cliente usa un valor compatible y avisa al usuario. Si configuras una lista de servidores permitidos en mcp_servers, el cliente solo habilita un servidor MCP si tanto su nombre como su identidad coinciden con una entrada aprobada. En caso contrario, lo deshabilita.

Los requisitos también pueden restringir indicadores de funciones mediante la tabla [features] de requirements.toml. Aunque las funciones no siempre afectan la seguridad, las empresas pueden fijar sus valores si lo desean. Las claves omitidas quedan sin restricciones.

Para Codex 0.138.0 o posterior, da preferencia a los perfiles de permisos con allowed_permission_profiles y el ajuste administrado default_permissions. Usa allowed_sandbox_modes solo para implementaciones heredadas que todavía configuren sandbox_mode.

Para ver la lista exacta de claves, consulta la sección sobre requirements.toml de la referencia de configuración.

Establecer límites de aprobación, sandbox y búsqueda web

Usa Requisitos > Límites de la política para limitar las opciones en los clientes compatibles. Estos controles restringen la configuración, pero no seleccionan el valor inicial. Configura el valor inicial por separado en Valores predeterminados.

1. En Global, abre Políticas de aprobación y selecciona las modalidades de aprobación permitidas. Por ejemplo, Preguntar cuando sea necesario permite que el agente solicite aprobación para acciones como elevar los permisos del sandbox. No preguntar nunca impide las solicitudes de aprobación, pero no autoriza la ejecución sin restricciones.
2. Abre Modos de sandbox para limitar las opciones de sandbox heredadas. Solo lectura restringe las escrituras, Escritura en el espacio de trabajo permite escribir dentro del espacio de trabajo y de las raíces configuradas con permiso de escritura, y Acceso completo elimina el aislamiento del sistema de archivos. Usa los requisitos de perfiles de permisos en implementaciones que usen perfiles de permisos en lugar de sandbox_mode.
3. En Global, abre Modos de búsqueda web para limitar la búsqueda web. Elige En caché para permitir la búsqueda en caché sin búsqueda en tiempo real, o Deshabilitada para desactivar la búsqueda web. Las restricciones de búsqueda web son independientes de las reglas de red para comandos.
4. Revisa las opciones permitidas y los valores predeterminados correspondientes, y selecciona Guardar cambios.

Si dejas un requisito sin configurar, esa política no impone ningún límite para ese requisito. Las demás políticas aplicables siguen vigentes. La opción Preguntar para comandos que no sean de confianza corresponde a untrusted en la lista de valores permitidos de los requisitos. No restablece el ajuste explícito retirado approval_policy = "untrusted". Para ese caso, sigue las instrucciones de migración que aparecen más adelante.

Para restringir la búsqueda web, usa Global > Requisitos > Límites de la política > Modos de búsqueda web. El TOML equivalente es:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] solo permite "disabled". Por ejemplo, allowed_web_search_modes = ["cached"] impide la búsqueda web en tiempo real incluso en sesiones con danger-full-access.

Configurar los valores predeterminados

Los valores predeterminados proporcionan a los miembros una configuración inicial. No imponen restricciones ni otorgan acceso a capacidades del espacio de trabajo.

1. Abre la tarjeta Valores predeterminados de la política. Mantén los valores predeterminados que afectan a todo el agente en Global. Usa una pestaña de entorno disponible para los valores predeterminados de ejecución compatibles.
2. En Ejecución de comandos, elige la Política de aprobación y el Revisor de aprobaciones iniciales, así como el Modo de sandbox o los Permisos predeterminados que correspondan. El revisor determina quién revisa las solicitudes de aprobación de forma predeterminada. La política de aprobación determina cuándo pueden generarse solicitudes.
3. En Búsqueda web, elige el modo inicial de Búsqueda web y el Contexto de búsqueda web. En Apps y herramientas, revisa Apps/conectores, Herramientas de mundo abierto y Herramientas destructivas para las herramientas de apps compatibles.
4. Confirma que los valores predeterminados cumplan tus Requisitos y selecciona Guardar cambios.

Usa Editar como TOML para los valores predeterminados compatibles que no tengan controles visuales, como la configuración de marketplaces de complementos. Estos valores predeterminados de la nube siguen la precedencia habitual de configuración. Se distinguen de la precedencia heredada de managed_config.toml, que da prioridad a los valores predeterminados administrados sobre la configuración local durante el inicio.

Ejemplo de requirements.toml

Este ejemplo bloquea --ask-for-approval never y --sandbox danger-full-access (incluido --yolo):

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

Aquí, untrusted conserva el comportamiento de aprobación más estricto que se deriva de trust_level = "untrusted". No permite usar approval_policy = "untrusted" como ajuste explícito.

Migrar la política de aprobación retirada untrusted

Codex y ChatGPT Work ya no admiten approval_policy = "untrusted". Elimina ese ajuste de los valores predeterminados administrados, del archivo heredado managed_config.toml y de cualquier configuración de usuario, proyecto, perfil o inicio que lo defina.

Para el uso interactivo de solo lectura, selecciona approval_policy = "on-request" con un sandbox o un perfil de permisos de solo lectura que permitan tus requisitos administrados. Los comandos permitidos por ese sandbox se pueden ejecutar sin aprobación.

Para mantener aprobaciones de comandos más estrictas, omite el ajuste explícito approval_policy, establece trust_level = "untrusted" en la entrada del proyecto en el archivo de usuario ~/.codex/config.toml y conserva untrusted en allowed_approval_policies. Esto también deshabilita la configuración local del proyecto. Establecer on-request explícitamente reemplaza esa política. Consulta Migrar desde la política de aprobación retirada untrusted para ver ejemplos y conocer las implicaciones de seguridad de cada opción.

Configurar la política de Revisión automática

Para usar Revisión automática de forma predeterminada, selecciona Global > Valores predeterminados > Ejecución de comandos > Revisor de aprobaciones. Los usuarios aún pueden elegir otro revisor permitido. Para exigir Revisión automática o reemplazar la política que usa el revisor, selecciona Editar como TOML y edita el archivo requirements.toml de Global. Las acciones del navegador tienen sus propios controles de Revisión automática.

El siguiente ejemplo exige Revisión automática para las solicitudes de aprobación que cumplen los requisitos. Para permitir también la aprobación manual, incluye "user" en allowed_approvals_reviewers.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

Para reemplazar la política completa, usa guardian_policy_config. Consulta Configuración de Revisión automática para conocer la política predeterminada y cómo preparar una que la reemplace.

Controlar los perfiles de permisos disponibles

Usa Valores predeterminados > Ejecución de comandos > Permisos predeterminados para elegir el perfil integrado con el que empiezan los usuarios. Para imponer qué perfiles pueden seleccionar o definir perfiles personalizados, usa Editar como TOML y configura requirements.toml en el ámbito Global o en el del entorno de ejecución compatible que corresponda. Elegir un perfil predeterminado por sí solo no restringe los perfiles disponibles.

Usa allowed_permission_profiles para controlar qué perfiles de permisos integrados y personalizados pueden seleccionar los usuarios. Es el equivalente de allowed_sandbox_modes para perfiles de permisos. Usa la lista de valores permitidos que corresponda a la forma en que tus usuarios seleccionan los permisos.

Las listas de perfiles de permisos permitidos requieren Codex 0.138.0 o posterior. Codex 0.137.0 y las versiones anteriores ignoran allowed_permission_profiles y el ajuste administrado default_permissions.

Usa los siguientes ejemplos de perfiles de permisos solo cuando todos los clientes administrados ejecuten una versión compatible. Espera a que termine la actualización de todos los clientes antes de implementar perfiles personalizados administrados.

Cuando está presente, la tabla contiene la lista completa de perfiles permitidos. Permite los perfiles establecidos en true y deniega los perfiles omitidos o establecidos en false, incluidos los perfiles integrados que se agreguen en versiones futuras de Codex.

Permitir los perfiles estándar

Esta política permite el acceso de solo lectura y el acceso al espacio de trabajo, pero deniega el acceso completo:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Agregar un perfil predeterminado administrado con privilegios mínimos

Los administradores pueden definir un perfil personalizado en la misma fuente de requisitos. Usa nombres de perfil específicos de la organización que no coincidan con nombres de la configuración que cargan los usuarios. Los nombres personalizados no pueden empezar con : ni usar el nombre reservado filesystem.

No implementes perfiles personalizados administrados en clientes que ejecuten Codex 0.137.0 o anterior. Esos clientes reconocen la tabla de perfiles, pero no el valor predeterminado administrado que selecciona el perfil.

Por ejemplo:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Permitir solo perfiles definidos por la empresa

Omite todos los perfiles integrados cuando los usuarios deban seleccionar únicamente perfiles definidos por el administrador:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

El perfil personalizado puede extender :workspace aunque los usuarios no puedan seleccionar directamente el perfil integrado :workspace.

Desactivar un perfil permitido por otra fuente

Las listas de perfiles de permisos permitidos se combinan por nombre de perfil. Como los requisitos de la nube tienen mayor precedencia que los del sistema, los requisitos de la nube pueden usar false para desactivar un perfil permitido en el archivo del sistema.

Requisitos de la nube:

default_permissions = ":read-only"

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

Requisitos del sistema:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

Establece default_permissions explícitamente en un perfil permitido. Si lo omites, el entorno de ejecución local usa :workspace de forma predeterminada solo cuando se permiten explícitamente tanto :workspace como :read-only. Si allowed_permission_profiles está ausente, los requisitos administrados no restringen los nombres de perfil que pueden seleccionar los usuarios. Cada entrada debe indicar un perfil integrado o un perfil personalizado definido en una fuente de configuración o requisitos que se haya cargado. Define los perfiles personalizados en los requisitos administrados para controlar su comportamiento de forma centralizada.

Imponer requisitos de denegación de lectura

Usa Editar como TOML para agregar restricciones del sistema de archivos al documento requirements.toml de Global o del entorno de ejecución compatible que corresponda. Estas restricciones bloquean la lectura de rutas sensibles. Un valor predeterminado de solo lectura no oculta archivos por sí solo.

Los administradores pueden denegar la lectura de rutas exactas o de rutas que coincidan con patrones glob mediante [permissions.filesystem]. Los usuarios no pueden flexibilizar estos requisitos con la configuración local.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Cuando hay requisitos de denegación de lectura, el entorno de ejecución local rechaza los permisos de acceso completo y mantiene la ejecución local en un sandbox de solo lectura o del espacio de trabajo para poder imponer esos requisitos. En Windows nativo, el ajuste administrado deny_read se aplica a las herramientas que acceden directamente a los archivos. Las lecturas realizadas por subprocesos del shell no usan esta regla del sandbox.

Cambiar los requisitos de sandbox según el host

Usa Editar como TOML en Seguridad del agente para definir requisitos específicos por host. Los controles de entorno seleccionan un entorno de ejecución. Los patrones de host seleccionan las máquinas coincidentes dentro del entorno de ejecución compatible.

Usa [[remote_sandbox_config]] cuando una misma política administrada deba aplicar distintos requisitos de sandbox según el host. Por ejemplo, puedes mantener un valor predeterminado más estricto para las computadoras portátiles y permitir escrituras en el espacio de trabajo en las máquinas de desarrollo o los ejecutores de CI que coincidan con el patrón. Actualmente, las entradas específicas por host solo reemplazan allowed_sandbox_modes:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

El entorno de ejecución local compara cada entrada de hostname_patterns con el nombre de host que logra resolver. Da preferencia al nombre de dominio completo cuando está disponible y, en caso contrario, usa el nombre de host local. La comparación no distingue entre mayúsculas y minúsculas. * coincide con cualquier secuencia de caracteres y ? con un solo carácter.

Dentro de una misma fuente de requisitos, prevalece la primera entrada de [[remote_sandbox_config]] que coincida. Si ninguna coincide, el entorno de ejecución local conserva el valor de nivel superior de allowed_sandbox_modes. La coincidencia del nombre de host solo sirve para seleccionar la política. No la uses como prueba autenticada de la identidad del dispositivo.

Imponer reglas de comandos mediante requisitos

Usa Editar como TOML en Seguridad del agente para agregar reglas de comandos y restricciones de servidores MCP al documento requirements.toml de Global. Las reglas de comandos especifican decisiones de aprobación o denegación para los comandos que coincidan. Las restricciones de MCP limitan las identidades de los servidores que el cliente puede habilitar. El control Políticas de aprobación no permite definir ninguno de estos conjuntos de reglas.

Los administradores también pueden imponer reglas restrictivas de comandos desde requirements.toml mediante una tabla [rules]. Estas reglas se combinan con los archivos .rules habituales y sigue prevaleciendo la decisión más restrictiva.

A diferencia de las reglas de .rules, las reglas de los requisitos deben especificar decision y su valor debe ser "prompt" o "forbidden" (no "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Para restringir los servidores MCP que puede habilitar un cliente local, agrega una lista de servidores aprobados en mcp_servers. Para los servidores stdio, comprueba la coincidencia con command. Para los servidores HTTP que admiten streaming, compruébala con url:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

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

Cuando identity.command es una cadena, solo se comprueba la coincidencia con el command configurado. No se inspeccionan args, cwd, env ni env_vars.

Para restringir una invocación stdio completa, comprueba la coincidencia con el ejecutable y con cada argumento posicional:

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

Deben coincidir el ejecutable, la cantidad de argumentos y su orden. Las reglas de argumentos y URL admiten coincidencias de tipo exact, prefix y regex. En este último caso, la expresión regular debe coincidir con el valor completo. Las reglas estructuradas de comandos tampoco inspeccionan cwd, env ni env_vars. Los servidores MCP incluidos en complementos usan los mismos formatos de identidad en plugins.<plugin>.mcp_servers.<server>.

Si mcp_servers está presente pero vacío, el cliente local deshabilita todos los servidores MCP.

Configurar el acceso a la red

El acceso a la red de los comandos y el de la app de escritorio usan controles diferentes. Empieza con Controles de uso de la red para el tráfico de comandos compatible, revisa los límites del entorno y de la ejecución, y luego usa los requisitos independientes de la app de escritorio si los necesitas. Las reglas de sitios del navegador se encuentran en Controlar el navegador y el uso de la computadora.

Usar el proxy del sistema para las solicitudes del cliente nativo

El ajuste experimental features.respect_system_proxy permite que el entorno de ejecución nativo de Codex, que usan ChatGPT para escritorio y Codex, utilice los ajustes de proxy del sistema operativo para sus propias solicitudes de red. Habilítalo en dispositivos que necesiten un proxy del sistema o configuración automática de proxy (PAC). El valor predeterminado es false.

Agrega lo siguiente a una fuente compatible de valores predeterminados de config.toml o a managed_config.toml:

[features]
respect_system_proxy = true

La configuración local del proyecto no puede habilitar este ajuste. Para MDM de macOS, incluye el mismo TOML en config_toml_base64. Reinicia el cliente después de cambiar la configuración local. Para desactivar esta opción, establece su valor en false en la fuente de configuración que la habilitó.

Inicio de sesión y valores predeterminados de la nube

La función independiente system_proxy_fallback está habilitada de forma predeterminada. Después de un error de conexión, puede reintentar las solicitudes compatibles de inicio de sesión y de configuración de la nube mediante el proxy del sistema, incluso cuando respect_system_proxy es false. Este mecanismo alternativo puede permitir que los clientes compatibles inicien sesión y obtengan los valores predeterminados de la nube sin necesidad de activar el proxy localmente. Deshabilitar únicamente respect_system_proxy no deshabilita el mecanismo alternativo.

Si el acceso directo no funciona y el mecanismo alternativo no está disponible, está deshabilitado o falla, implementa respect_system_proxy localmente antes de iniciar sesión.

Alcance y limitaciones

Valida el inicio de sesión y una solicitud autenticada con las versiones del cliente y en las redes que planeas usar. Ten en cuenta estos límites:

• Alcance de las solicitudes: el ajuste se aplica a los clientes de red del entorno de ejecución de Codex. No configura todas las solicitudes de ChatGPT para escritorio o del navegador, ni todos los procesos de complementos o comandos de shell. No impone una lista de destinos permitidos ni garantiza el bloqueo de conexiones directas. Para el tráfico compatible, consulta los requisitos de red de los comandos y los requisitos de red de la app de escritorio.
• Compatibilidad con plataformas: macOS y Windows admiten la detección nativa del proxy del sistema. Si el sistema no puede determinar qué proxy usar, el entorno de ejecución usa los ajustes explícitos de proxy del entorno, si están disponibles. De lo contrario, se conecta directamente. Las demás plataformas usan los ajustes del entorno o la conexión directa en lugar de la detección nativa del sistema.
• Enrutamiento con PAC: el entorno de ejecución selecciona una ruta del resultado de PAC. Si esa conexión falla, no prueba las siguientes entradas de proxy o DIRECT del resultado.
• Autenticación en Windows: las compilaciones compatibles pueden responder a un desafío HTTP 407 del proxy durante la configuración del túnel mediante Negotiate o NTLM con las credenciales del usuario que inició sesión en Windows. No se admiten proxies HTTPS que requieran tokens de autenticación vinculados a la conexión TLS del proxy.

Configurar los requisitos de acceso a la red

Usa Requisitos > Controles de uso de la red para administrar el acceso a la red de los comandos compatibles en Seguridad del agente. Configura una base compartida en Global o usa una pestaña disponible de Entornos locales o Entornos de Codex Cloud para los ajustes de ejecución específicos del entorno.

1. Establece Red administrada en Activada para aplicar reglas de dominio al tráfico de comandos administrado. Agregar reglas de dominio por sí solo no activa el proxy administrado.
2. En Reglas de red, selecciona Agregar regla de red. Ingresa un Dominio como api.openai.com o **.example.com, sin esquema de URL ni ruta. Elige Permitir o Denegar en Acceso y selecciona Guardar regla para actualizar el borrador. Repite el proceso para otros destinos.
3. Establece Permitir solo los dominios agregados por administradores en Activado si los ajustes del usuario y las aprobaciones por dominio no deben ampliar la lista administrada de dominios permitidos. Incluye las entradas necesarias de tipo Permitir. Una lista que solo contiene denegaciones no permite otros destinos.
4. Revisa Permitir acceso a la red local para los flujos de trabajo que necesiten servicios locales a la escucha o destinos privados. Las conexiones locales directas pueden eludir las reglas de dominio del proxy. Antes de cambiar este ajuste, revisa los límites de conectividad de Codex Cloud que se describen más adelante.
5. Revisa las reglas heredadas y los mensajes de validación, y selecciona Guardar cambios. Prueba una solicitud que deba completarse y otra que deba bloquearse en cada entorno de ejecución afectado.

Establecer Red administrada en Desactivada elimina las reglas de red definidas en ese ámbito y guarda un valor explícito de desactivación. No deshabilita el acceso a internet. Sin configurar elimina los ajustes de red definidos en ese ámbito para que puedan aplicarse la política correspondiente o los valores predeterminados del entorno de ejecución. Al quitar los ajustes de entorno, pueden volver a quedar vigentes las reglas heredadas de Global. Usa Editar como TOML para los campos avanzados de red o las listas de dominios heredadas existentes que el editor visual no pueda representar.

En Codex 0.166.0, [network_proxy] es la tabla canónica de requirements.toml para administrar el acceso de los comandos a la red. Codex también acepta el nombre anterior, [experimental_network]. Usa un solo nombre de tabla por capa. Si las capas usan nombres diferentes, Codex aplica el orden habitual de precedencia de los requisitos.

Configura enabled = true en la tabla administrada para iniciar el proxy independientemente del ajuste de usuario features.network_proxy. El sandbox activo también debe permitir que los comandos accedan a la red. El ejemplo usa el nombre que reconocen los clientes y las capas de validación de políticas de versiones anteriores.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Usa experimental_network.managed_allowed_domains_only = true solo si también defines entradas "allow" bajo control de los administradores en [experimental_network.domains] y quieres que esas reglas sean exclusivas. Si su valor es true y no hay reglas administradas que permitan dominios, las reglas de permiso de dominio agregadas por los usuarios dejan de surtir efecto. No combines el mapa canónico domains con las listas heredadas allowed_domains o denied_domains.

*.example.com solo coincide con subdominios. **.example.com coincide con el dominio raíz y sus subdominios. Si coinciden una regla de denegación y una de permiso, prevalece la de denegación.

La sintaxis de dominios, las reglas de destinos locales o privados, la prioridad de las denegaciones sobre los permisos y las limitaciones relativas al reenlace de DNS son las mismas que se describen para la red del sandbox en Aprobaciones y seguridad del agente.

El proxy enruta el tráfico de los comandos locales que se ejecutan dentro del sandbox. Las herramientas del navegador también comprueban las denegaciones de red administradas y las listas exclusivas de destinos permitidos antes de acceder a un origen. Esta comprobación de política es independiente y no enruta el tráfico del navegador a través del proxy de comandos. El proxy no filtra la búsqueda web, las apps y los conectores, los servidores MCP, el tráfico de apps nativas, las solicitudes del servicio de Codex ni el tráfico específico de otras capacidades. Usa los controles correspondientes en cada caso:

• Usa allowed_web_search_modes para restringir la búsqueda web.
• Usa features.apps = false para deshabilitar las integraciones de apps y conectores, y features.plugins = false para deshabilitar los complementos donde se admita.
• Usa la lista administrada de servidores aprobados de mcp_servers para restringir los servidores MCP.
• Usa requisitos de funciones como browser_use, in_app_browser y computer_use para restringir las capacidades de navegador y uso de la computadora.
• Para los comandos administrados compatibles de Codex Cloud, revisa tanto los ajustes de internet del entorno como los de Seguridad del agente. El entorno puede bloquear un dominio aunque Seguridad del agente lo permita.

Prueba por separado los comandos ordinarios y las ejecuciones con elevación completa de permisos del sandbox que permita la política. Una elevación completa de permisos del sandbox, una vez aprobada, puede eludir el proxy administrado de comandos. Consulta Aislamiento de red.

Sin destinos permitidos efectivos: cuando están activadas las opciones Red administrada y Permitir solo los dominios agregados por administradores, los comandos administrados ordinarios necesitan una entrada de tipo Permitir, ya sea explícita o heredada. Antes de guardar, comprueba los destinos permitidos efectivos.

Conectividad local o privada de Codex Cloud: si un comando en la nube no puede acceder a un dominio permitido, comprueba el valor efectivo de allow_local_binding. Un valor de desactivación heredado puede bloquear el acceso al proxy ascendente. Consulta Conectividad local o privada de Codex Cloud para conocer el valor predeterminado y las excepciones específicos de la nube.

Cuando los requisitos del entorno están vacíos, se aplican los de Global. Establecer Red administrada en Desactivada es independiente del ajuste de acceso a internet del entorno en la nube. Consulta los controles de ejecución de Seguridad del agente para obtener detalles sobre el ámbito de ejecución.

Precedencia de las políticas de red y límites del entorno de ejecución

Dentro de una política, el orden de mayor a menor prioridad es: excepción de entorno para un sistema operativo específico → excepción de entorno para todos los sistemas operativos → Global. Una política de mayor prioridad prevalece sobre una de menor prioridad, incluso cuando la de menor prioridad es más específica. Algunos requisitos tienen reglas de combinación específicas por campo. El entorno de ejecución aplica los requisitos resultantes. Distingue los siguientes casos de red, que dependen del campo, de la prioridad de las políticas.

Estos ejemplos comparan los ajustes de entorno y de Global dentro de una misma política, con la red administrada ya configurada y sin que una política de mayor prioridad cambie los valores. Describen cómo se combinan los campos y qué ocurre durante la ejecución.

Configurar distintos niveles de acceso a dominios según el entorno

Para una misma regla de dominio dentro de una política, una excepción de entorno definida por un administrador puede permitir un dominio denegado en Global o denegar uno permitido en Global. Si no hay una excepción de entorno, se hereda la regla de Global. Otras reglas de denegación efectivas u otros controles de acceso aún pueden bloquear una solicitud.

Cómo se combinan las reglas de dominio

Estos resultados comparan la misma clave de dominio dentro de una política, sin que otra de mayor prioridad cambie el resultado. Un valor de mayor prioridad reemplaza el de la misma clave. Las demás claves heredadas se conservan. Una regla de tipo Permitir no elude otra regla coincidente de tipo Denegar, como una regla heredada con comodines. Un mapa de entorno vacío no elimina las reglas heredadas.

Ejemplo: deniega packages.example.com en Global y permítelo en Desarrollo. Desarrollo puede permitir el acceso en las condiciones descritas. Producción hereda la denegación de Global a menos que se configure una excepción.

Confirma que el ejecutor implementado admita estas reglas de combinación. Aún se debe validar la compatibilidad de los ejecutores administrados ordinarios.

Límites del orquestador. El entorno de ejecución en la nube no admite puertos de escucha HTTP/SOCKS administrados ni servicios de proxy que escuchen en interfaces distintas de la de loopback. La compatibilidad con reglas de sockets depende de la vía de ejecución. Los ajustes de ejecución local de la siguiente tabla no constituyen configuraciones compatibles del orquestador.

Otros límites de red del entorno de ejecución

Todos los campos que aparecen a continuación pertenecen a la tabla administrada network_proxy (también se acepta el nombre experimental_network) de requirements.toml. Las flechas muestran un valor de Global seguido de un valor de entorno dentro de la misma política. Estos casos de ejecución local no indican que el orquestador admita los mismos ajustes.

La activación del proxy, la exclusividad, el comportamiento del proxy ascendente y las reglas de sockets Unix dependen del ejecutor. No generalices a estos ajustes la forma en que se combinan las claves de dominio. Verifica los valores efectivos y prueba el entorno de ejecución implementado. Para la conectividad local o privada de Codex Cloud, consulta Configurar los requisitos de acceso a la red.

Verificar el comportamiento antes de la implementación

Prueba los destinos, los servicios locales a la escucha, el comportamiento del proxy y las rutas de sockets que realmente usan tus flujos de trabajo. Comprueba una acción que deba completarse y otra que deba bloquearse en cada entorno afectado. Verifica que la versión del entorno de ejecución implementada admita cada ajuste que uses.

Controlar los destinos de red de la app de escritorio

Usa Editar como TOML en Seguridad del agente para configurar en Global estos requisitos específicos de escritorio. La interfaz de Controles de uso de la red administra la red de los comandos, que tiene una política independiente.

Usa [application.network] en requirements.toml para restringir los destinos de red de la app de escritorio. Con enabled = true, las solicitudes externas deben usar HTTPS o WSS y coincidir exactamente con un dominio que tenga el valor "allow" en [application.network.domains]. Los subdominios no se permiten implícitamente. Un mapa de dominios vacío no permite ningún destino externo. Consulta la referencia de configuración para conocer las claves compatibles.

Esta política es independiente de la red de los comandos y de las reglas de origen del navegador. No impone restricciones de destino a los módulos nativos ni a los procesos que se inician, y no controla la ejecución de Work Cloud.

Configurar complementos y hooks administrados

Para estas tareas, usa Editar como TOML en Seguridad del agente o una fuente de configuración local compatible. Los valores predeterminados del marketplace, las restricciones obligatorias de complementos y los hooks administrados tienen fines distintos. Elige la tarea que corresponda a la política que necesitas.

Configurar marketplaces y valores predeterminados de complementos

Usa Seguridad del agente > Editar como TOML para definir marketplaces locales o de Git y valores predeterminados de complementos en el documento config.toml de Global. También puedes distribuir estos ajustes en el archivo config.toml del sistema. Proporcionan la configuración inicial de marketplaces y complementos, sin imponer una política obligatoria. Para limitar las fuentes que pueden usar los miembros, configura los requisitos de fuentes de marketplaces.

Consulta la referencia de configuración para conocer las claves de configuración, la precedencia de configuración para saber qué ajustes prevalecen y los ajustes de complementos del repositorio para la configuración a nivel de proyecto. La importación y sincronización con GitHub del espacio de trabajo se gestiona por separado.

Controlar la disponibilidad de los complementos

Usa Editar como TOML en Seguridad del agente para imponer ajustes de la función de complementos en el documento requirements.toml de Global, o distribúyelos mediante requisitos locales para los clientes administrados en los dispositivos. Valores predeterminados > Apps y herramientas > Apps/conectores establece los valores predeterminados de las herramientas de apps. El control obligatorio features.plugins se configura por separado. Para los permisos de complementos del espacio de trabajo, consulta Apps y conectores.

Para desactivar los complementos en los clientes locales compatibles, establece features.plugins en false en requirements.toml:

features.plugins = false

Este ajuste también se aplica cuando los usuarios inician sesión en Codex con una clave de API. Consulta la referencia de features.plugins para conocer la configuración compatible.

Restringir las fuentes de marketplaces de complementos

Usa Editar como TOML para configurar los requisitos de fuentes de marketplaces en el documento requirements.toml de Global o distribúyelos mediante requisitos locales. Estas reglas limitan las fuentes locales o de Git que los usuarios pueden agregar y usar. Son independientes de los valores predeterminados de marketplaces.

Para restringir las fuentes de marketplaces de complementos, configura restrict_to_allowed_sources = true y define una o más reglas de fuentes:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Las reglas de Git comprueban la coincidencia con la URL normalizada del repositorio y, cuando se especifica, con el valor exacto de ref. Los patrones de host son expresiones regulares que se comparan con el host de Git en minúsculas. Usa ^ y $ para que deba coincidir todo el nombre del host. Las reglas locales requieren una ruta absoluta normalizada. Consulta la referencia de requirements.toml para conocer el esquema completo y las reglas de combinación.

Estos requisitos rechazan las operaciones de agregar marketplaces, instalar complementos y actualizar marketplaces de Git configurados cuando la fuente no coincide. También filtran los marketplaces configurados y sus complementos durante la ejecución.

Los marketplaces de Git seleccionados por OpenAI, incluido el catálogo para claves de API, también deben coincidir con la lista de fuentes permitidas. Para permitirlos, incluye la siguiente fuente de Git sin una restricción de ref:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Para excluir los catálogos seleccionados, omite esa fuente y comprueba que ninguna regla de host más amplia la permita. Los complementos incluidos y los complementos del espacio de trabajo instalados de forma remota son independientes de esta política de fuentes de Git seleccionadas.

Estas restricciones de fuentes se aplican solo donde un cliente local admite operaciones de marketplaces de complementos: en ChatGPT y Codex en la app de escritorio, y en Codex CLI. No controlan el uso de complementos en ChatGPT en la web o en dispositivos móviles, ni agregan complementos a la extensión para IDE.

Imponer hooks administrados mediante requisitos

En Seguridad del agente, abre Global > Requisitos > Editar como TOML. Para el modo Work con acceso a la computadora local y para los dots, configura los controladores mcp_tool compatibles en el documento requirements.toml de Global. Antes de la implementación, prueba la conexión de la llamada de retorno y comprueba qué ocurre si se agota su tiempo de espera. Consulta Hooks con orquestación en la nube para conocer los eventos compatibles y el comportamiento en caso de falla.

Para Codex local, distribuye los scripts de los hooks con tu herramienta de administración de dispositivos. Para imponerlos incluso si un usuario deshabilita los hooks, fija [features].hooks = true en requirements.toml. Consulta el ejemplo de configuración de hooks administrados para conocer las rutas de los scripts y cómo permitir únicamente los hooks administrados.

Entender el alcance y la precedencia de las políticas

Usa esta sección para comprobar dónde se aplica una política, cómo se combinan los requisitos, cómo reciben los clientes los ajustes administrados desde la nube y cómo verificar el resultado.

En el modo Work con acceso local y en los dots, la política de Global compatible rige el orquestador compartido de la nube cuando la política administrada está habilitada. Los requisitos de ejecución local aplicables rigen la computadora conectada. Los contenedores del modo Work en la nube conservan las políticas existentes de Work Cloud y los controles compatibles del dispositivo siguen aplicándose a la ejecución local. Codex conserva su comportamiento de configuración existente. La configuración administrada no asigna una licencia del espacio de trabajo ni da acceso a funciones. Usa Roles y permisos del espacio de trabajo para esos controles.

Seguridad del agente y acceso a la computadora local con Work Cloud

Usa Seguridad del agente en la consola de administración para administrar políticas y configuraciones. Esta sección reemplaza a Políticas y configuración. Seguridad del agente está disponible en la consola de administración independientemente del acceso a la computadora local con Work Cloud. Se conservan las políticas existentes, las asignaciones y su orden. Revisa tus políticas existentes en Seguridad del agente. El acceso a la computadora local con Work Cloud se habilita por separado. Consulta Seguridad del agente para obtener instrucciones de migración.

Antes de migrar la automatización de políticas a Seguridad del agente:

1. Identifica las integraciones afectadas. Haz un inventario de las configuraciones de Terraform y de los scripts que actualizan políticas, y registra qué políticas administran.

2. Usa la API de políticas para administrar los ajustes de Global. Para administrar los ajustes de Local o Codex Cloud, usa la interfaz de Seguridad del agente. Los flujos de trabajo existentes de la API para Global siguen disponibles después de la migración. Prueba tus scripts y tus integraciones de Terraform, y confirma que las asignaciones y el orden de las políticas se hayan conservado.

3. Haz los cambios necesarios y prueba la automatización. Verifica que la actualización prevista llegue a la política correcta de Seguridad del agente y que se apliquen los controles resultantes.

La migración de políticas no otorga acceso a la computadora local al modo Work ni a los dots. Se recomienda revisar o crear políticas antes de la implementación, pero el proceso de confirmación no exige crear una política para habilitar el acceso. Antes de habilitar Permitir acceso a la computadora local, revisa la configuración base migrada o crea una en la nube si actualmente distribuyes tus políticas solo mediante MDM. Si enforce_residency está habilitado en alguna política de la nube, Permitir acceso a la computadora local queda deshabilitado tanto para el modo Work como para los dots. Esta medida de protección no configura la residencia de los datos del espacio de trabajo ni deshabilita por sí sola Work Cloud o los dots.

Las excepciones por entorno permiten variar los ajustes compatibles dentro de una política. Dentro de una política, el orden de mayor a menor prioridad es: excepción de entorno para un sistema operativo específico → excepción de entorno para todos los sistemas operativos → Global. Una política de mayor prioridad prevalece sobre una de menor prioridad, incluso cuando la de menor prioridad es más específica. Algunos requisitos tienen reglas de combinación específicas por campo. Confirma qué editores de excepciones y qué campos están disponibles para tu espacio de trabajo.

Antes de habilitar el acceso local para un flujo de trabajo que use hooks, comprueba qué hooks se ejecutan con la orquestación en la nube.

Ubicaciones y precedencia

Para la ejecución local, los requisitos se aplican en el siguiente orden, de menor a mayor prioridad. Este orden también se aplica a los pasos locales cuando se usa el acceso a la computadora local con Work Cloud:

1. El archivo requirements.toml del sistema (/etc/codex/requirements.toml en sistemas Unix, incluidos Linux y macOS, o %ProgramData%\OpenAI\Codex\requirements.toml en Windows).
2. Los requisitos de Seguridad del agente distribuidos en el paquete de configuración de la nube.
3. Los campos heredados de managed_config.toml que el cliente local reinterpreta como requisitos.
4. Las preferencias administradas de macOS (MDM) distribuidas mediante com.openai.codex:requirements_toml_base64.

Las capas de mayor precedencia reemplazan los valores escalares y de listas ordinarios de las capas inferiores. Las tablas se combinan por clave, mientras que requisitos como las reglas, los hooks y las restricciones del sistema de archivos se combinan de forma específica según el campo. Usa la referencia de requirements.toml para consultar el esquema vigente. No supongas que todos los campos se combinan de la misma manera.

Para mantener la compatibilidad con versiones anteriores, los clientes locales compatibles reinterpretan los campos heredados approval_policy, approvals_reviewer y sandbox_mode como requisitos. Esta conversión agrega opciones de compatibilidad cuando es necesario. Usa requirements.toml para definir listas explícitas de valores permitidos.

Precedencia para el acceso a la computadora local con Work Cloud

Para el modo Work con acceso local y los dots, distingue la política de Global del orquestador de la política de ejecución. Los requisitos locales aplicables rigen la computadora conectada. Los contenedores del modo Work en la nube y las computadoras en la nube de los dots usan sus propios requisitos y configuración de ejecución en lugar del paquete de entorno administrado que usan otros ejecutores.

Para la ejecución local, los requisitos de MDM y los requisitos heredados de dispositivos administrados tienen mayor prioridad que Seguridad del agente. El archivo de requisitos del sistema del dispositivo tiene menor prioridad que Seguridad del agente. Dentro de cada política, resuelve primero las excepciones de entorno específicas del sistema operativo, luego las excepciones de entorno para todos los sistemas operativos y por último Global. Entre políticas, la prioridad prevalece sobre la especificidad.

Los requisitos imponen restricciones, mientras que los valores predeterminados de configuración proporcionan valores iniciales. Para el modo Work con acceso local y los dots, la política de Global compatible se aplica mediante el orquestador compartido de la nube cuando la política administrada está habilitada. Los requisitos locales aplicables de requirements.toml rigen la ejecución en una computadora conectada. Los contenedores del modo Work en la nube y las computadoras en la nube de los dots usan sus propios requisitos y configuración de ejecución en lugar del paquete de entorno administrado que usan otros tipos de ejecutores. Las restricciones de ejecución local no se aplican automáticamente a estas computadoras en la nube. Revisa los permisos de las capacidades de la nube y prueba la ejecución local y en la nube por separado.

Mantén en Global los controles del orquestador, incluidas las aprobaciones y la búsqueda web. Usa los controles específicos Políticas de aprobación permitidas y Modos de búsqueda web permitidos donde estén disponibles, y TOML para los demás campos compatibles. Consulta la referencia de configuración para conocer la lista de campos y el ámbito de ejecución.

Requisitos administrados desde la nube

Cuando un usuario inicia sesión con ChatGPT en un plan compatible, los clientes locales compatibles pueden recibir los requisitos asociados al espacio de trabajo que imponen los administradores. Este es un canal de distribución de políticas compatibles con requirements.toml. No otorga acceso al espacio de trabajo ni reemplaza su control de acceso basado en roles (RBAC). Los requisitos de autenticación deben administrarse localmente.

Configura los requisitos habituales con los controles de Seguridad del agente. Para una política que solo permita aprobaciones a solicitud y sandboxes de solo lectura o workspace-write, usa Políticas de aprobación y Modos de sandbox en Límites de la política. Para que también se solicite aprobación antes de ejecutar un punto de entrada de shell compatible, usa Editar como TOML para agregar la tabla [rules] al documento requirements.toml de Global.

El TOML equivalente completo es:

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

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Comprueba que todas las versiones de clientes administrados admitan las claves que selecciones. Asigna la política a los usuarios o grupos previstos y verifica que surta efecto en sus clientes compatibles. Consulta la referencia de configuración para conocer el esquema vigente y la interfaz de administración para comprobar cómo funcionan actualmente las asignaciones.

El servicio selecciona las capas de requisitos administradas por la empresa que corresponden a la identidad que inició sesión. El cliente local evalúa esas capas junto con las demás fuentes de requisitos descritas en Ubicaciones y precedencia. Usa la interfaz de administración vigente para crear y asignar políticas en el espacio de trabajo. No dependas de una copia del algoritmo de coincidencia de grupos. El servicio de administración controla ese comportamiento y puede cambiarlo independientemente del formato de los requisitos locales.

Para conocer las claves compatibles y ver ejemplos, consulta el ejemplo de requirements.toml y la referencia de requirements.toml.

Cómo aplican los clientes locales los requisitos administrados desde la nube

El comportamiento de carga local y caché que se describe a continuación corresponde a los clientes locales compatibles. No determina cuándo entra en vigor un cambio de política de la nube en una tarea que ya está en ejecución y usa el acceso a la computadora local con Work Cloud. Verifica la política efectiva antes de depender de una restricción modificada.

Cuando un usuario inicia un cliente local compatible e inicia sesión con ChatGPT en un plan compatible, el cliente primero busca una entrada válida en la caché que coincida con la identidad. Si no hay ninguna disponible, el cliente solicita el paquete aplicable, con reintentos, y guarda una entrada firmada en la caché si la solicitud se completa. Si la solicitud falla o se agota el tiempo de espera y no hay una entrada válida en la caché, la carga del paquete de configuración de la nube devuelve un error en lugar de iniciar silenciosamente sin la capa de requisitos administrados desde la nube.

Una vez resuelta la caché, el cliente combina los requisitos de la nube con las demás capas de requisitos descritas anteriormente. Una actualización en segundo plano renueva el paquete en caché y lo deja disponible para cargas posteriores de la configuración. Esto no garantiza que una tarea que ya se está ejecutando use de inmediato una política modificada. Algunos ajustes de escritorio requieren reiniciar la app. Sigue las indicaciones de reinicio y verifica los ajustes efectivos antes de depender del cambio.

Verificar la experiencia de los administradores y los empleados

Asigna una persona responsable de cada política administrada, registra qué usuarios o grupos deben recibirla y documenta el motivo empresarial de cualquier restricción de sistema de archivos, red, aprobación o perfil de permisos.

Prueba un flujo de trabajo permitido y uno bloqueado con un usuario que tenga los permisos previstos. Comprueba los ajustes efectivos en el cliente compatible. El rol o grupo del espacio de trabajo por sí solo no impone restricciones en el entorno de ejecución local.

Usa Probar políticas en Seguridad del agente para comprobar qué políticas corresponden al miembro, grupo o rol seleccionado. En una sesión de edición, esta opción comprueba el borrador actual sin guardarlo. El resultado muestra qué políticas se seleccionan. No muestra la configuración final combinada ni indica si un cliente impone una restricción. Después de guardar, prueba los flujos de trabajo permitidos y bloqueados en cada cliente y vía de ejecución pertinentes.

Implementar la configuración administrada en los dispositivos

Usa requisitos locales del sistema o MDM para las restricciones de autenticación y las políticas administradas en los dispositivos. El mecanismo heredado de managed_config.toml tiene una precedencia de inicio diferente de la de Valores predeterminados en Seguridad del agente. El flujo de trabajo de MDM abarca tanto los requisitos como los valores predeterminados heredados.

Administrar la autenticación localmente

Configura allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store y chatgpt_base_url en el archivo requirements.toml del sistema local o en los requisitos de MDM de macOS. Codex ignora estos cuatro campos en los requisitos administrados desde la nube. Los requisitos de autenticación locales se aplican antes de cargar las credenciales y antes de que Codex recupere la política de la nube.

Para exigir el inicio de sesión con ChatGPT en un espacio de trabajo aprobado y guardar las credenciales en el almacén de credenciales del sistema operativo, usa:

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

allowed_login_methods acepta chatgpt, api o ambos. Si lo omites, este ajuste no restringe los métodos de inicio de sesión. Si lo configuras, la lista debe contener al menos un método. api permite la autenticación por API, incluida la de Amazon Bedrock. La restricción del espacio de trabajo también se aplica a los tokens de acceso de Codex.

Los ajustes forced_login_method y forced_chatgpt_workspace_id configurados por el usuario deben cumplir los requisitos. Cuando un usuario selecciona un espacio de trabajo, este también debe figurar en la lista administrada de espacios de trabajo permitidos. Si ningún espacio de trabajo coincide, el inicio de sesión con ChatGPT no está disponible. La autenticación por API sigue disponible si está permitida. Si no hay ningún método de inicio de sesión disponible, Codex no se inicia.

Consulta la referencia de requisitos para conocer los modos de almacenamiento de credenciales y la configuración de URL de servicios.

Imponer los ajustes de OpenTelemetry

En Codex CLI 0.166.0, usa [otel] en requirements.toml para configurar por separado los exportadores de registros, trazas y métricas, etiquetar el entorno y controlar qué contenido exporta Codex. Este ejemplo envía registros a un recopilador OTLP/HTTP y limita a 256 bytes en UTF-8 el texto que se registra por cada resultado de herramienta. Omite el texto de los prompts, el texto de las respuestas finales y las evaluaciones de aprobación automática.

La versión 26.1027.30824 de la app de escritorio para macOS incluye la versión 0.166.0-alpha.5.1 de la CLI. Esa compilación no admite [otel] en requirements.toml, por lo que no puede imponer log_user_prompt = false mediante esta política.

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false
log_agent_responses = false
log_guardian_assessments = false
tool_result = { max_bytes = 256 }
span_attributes = { team = "platform" }
tracestate = { acme = { region = "eu" } }

Los valores administrados prevalecen sobre la configuración local. Para exporter, trace_exporter y metrics_exporter, el requisito de mayor prioridad que configure el exportador correspondiente proporciona su definición completa, incluidos los encabezados y los ajustes de TLS. Cada ajuste escalar y la tabla tool_result también toman el valor de mayor prioridad que se haya definido para cada uno. Los ajustes omitidos se pueden configurar, salvo que otra capa de requisitos los defina.

Los atributos de los segmentos de traza se combinan por nombre de atributo. Los campos de tracestate se combinan por miembro y nombre de campo. Cuando dos entradas coinciden, prevalece el valor de mayor prioridad. Las demás entradas siguen disponibles y una tabla de metadatos vacía no las elimina. Consulta Observabilidad y telemetría para conocer las opciones de los exportadores y el contenido de los registros.

Migrar bases de datos SQLite en NFS

En Linux, Codex crea las bases de datos SQLite nuevas en NFS con el modo de diario DELETE. Para migrar las bases de datos existentes que usan el registro de escritura anticipada (WAL), configura unsafe_enforce_sqlite_journal_mode = true en el nivel superior de requirements.toml. Este ajuste está desactivado de forma predeterminada. Si lo activas, Codex migra las bases de datos antes de abrirlas para escritura.

El montaje NFS debe admitir bloqueos POSIX entre hosts. Las opciones de montaje como nolock y local_lock=all impiden que estos bloqueos funcionen. En cada host, detén todos los clientes SQLite que usen las bases de datos, incluido Codex. Inicia una sola instancia de Codex y mantén detenidos los demás clientes hasta que la migración finalice correctamente. El usuario que ejecute esa instancia necesita acceso de escritura al directorio de las bases de datos y al bloqueo de migración. Los archivos de reemplazo conservan los bits de permisos de Unix y pertenecen a ese usuario. La migración no copia el propietario ni el grupo originales, ni las listas de control de acceso extendidas. Codex guarda los archivos originales en un directorio privado de respaldo.

Valores predeterminados administrados (managed_config.toml)

Usa los valores predeterminados de Seguridad del agente para los valores iniciales compatibles administrados desde la nube. Esta sección explica el mecanismo heredado de managed_config.toml administrado en los dispositivos y su precedencia de inicio diferente. Editar los Valores predeterminados en Seguridad del agente no distribuye un archivo managed_config.toml a los dispositivos de los miembros.

Los valores predeterminados administrados definen la configuración con la que se inicia un cliente local compatible. Durante el inicio, tienen prioridad sobre el archivo config.toml local del usuario y sobre cualquier ajuste especificado con --config en la CLI. Los usuarios pueden cambiar esos ajustes durante la ejecución actual, y los valores predeterminados vuelven a aplicarse la próxima vez que se inicia el cliente.

GPT-5.5 se retira de Codex para quienes inician sesión con ChatGPT el 14 de octubre de 2026 al mediodía, hora del Pacífico (PDT, 19:00 UTC). Si un valor predeterminado administrado, un perfil de MDM de macOS o una configuración guardada fija gpt-5.5 para esos usuarios, reemplázalo por un modelo disponible. Elige gpt-6.1-sol una vez que un administrador lo haya habilitado para los usuarios afectados. Este cambio no afecta a la API de OpenAI ni a las sesiones de Codex autenticadas con una clave de API. Consulta la disponibilidad de modelos en el espacio de trabajo.

Para las configuraciones que aún fijan gpt-5.4 o gpt-5.4-mini, sigue las instrucciones de migración de GPT-5.4.

Asegúrate de que los valores predeterminados administrados cumplan tus requisitos. El entorno de ejecución local rechaza los valores no permitidos.

Precedencia y capas

El entorno de ejecución local combina la configuración efectiva en este orden (las capas superiores prevalecen sobre las inferiores):

• Preferencias administradas (MDM de macOS, máxima precedencia)
• managed_config.toml (archivo administrado o del sistema)
• config.toml (configuración base del usuario)

Los ajustes especificados en la CLI con --config key=value se aplican a la base, pero las capas administradas prevalecen sobre ellos. Por eso, cada ejecución empieza con los valores predeterminados administrados, incluso si proporcionas indicadores locales.

El archivo config.toml de la nube usa la precedencia habitual de configuración, que difiere del orden heredado anterior. El archivo requirements.toml de la nube usa la precedencia de los requisitos.

Ubicaciones

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/sistemas que no son Unix: ~/.codex/managed_config.toml

Si el archivo no existe, el entorno de ejecución local omite la capa administrada.

Ejemplo de managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false            # keep prompts redacted

Límites recomendados

• Da preferencia a workspace-write con aprobaciones para la mayoría de los usuarios. Reserva el acceso completo para contenedores controlados.
• Mantén network_access = false a menos que tu revisión de seguridad permita un recopilador o los dominios que necesiten tus flujos de trabajo.
• Para imponer los ajustes de telemetría, usa los requisitos de OpenTelemetry. Mantén log_user_prompt = false a menos que tu política permita almacenar el contenido de los prompts.
• Revisa periódicamente las diferencias entre el archivo config.toml local y la política administrada para detectar desviaciones. Las capas administradas deben prevalecer sobre los indicadores y archivos locales.

Preferencias administradas de macOS (MDM)

En macOS, los administradores pueden distribuir un perfil de dispositivo que proporcione cargas útiles TOML codificadas en base64 en las siguientes ubicaciones:

• Dominio de preferencias: com.openai.codex
• Claves:
  • config_toml_base64 (valores predeterminados administrados)
  • requirements_toml_base64 (requisitos)

El entorno de ejecución local interpreta estas cargas útiles de “preferencias administradas” como TOML. Para los valores predeterminados administrados (config_toml_base64), las preferencias administradas tienen la máxima precedencia. Para los requisitos (requirements_toml_base64), la precedencia sigue el orden de los requisitos. La misma tabla [features] de los requisitos funciona en requirements_toml_base64. Usa también allí las claves canónicas de funciones.

Procedimiento de configuración de MDM

El entorno de ejecución local respeta las cargas útiles estándar de MDM de macOS, por lo que puedes distribuir los ajustes con herramientas como Jamf Pro, Fleet o Kandji. Para una implementación sencilla:

1. Prepara la carga útil administrada en TOML y codifícala con base64 (sin saltos de línea).
2. Coloca la cadena en tu perfil de MDM, dentro del dominio com.openai.codex, en config_toml_base64 (valores predeterminados administrados) o en requirements_toml_base64 (requisitos).
3. Distribuye el perfil y pide a los usuarios que reinicien el cliente local compatible y confirmen que el resumen de configuración de inicio refleje los valores administrados.
4. Cuando revoques o cambies una política, actualiza la carga útil administrada. El cliente lee la preferencia actualizada la próxima vez que se inicia.

Evita incluir secretos o valores dinámicos que cambien con frecuencia en la carga útil. Aplica al TOML administrado el mismo control de cambios que a cualquier otro ajuste de MDM.