Configuración administrada

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

Empiece en Seguridad de agentes en la consola de administración para configurar los ajustes compatibles administrados en la nube. Use los controles de configuración para las tareas habituales o seleccione Editar como TOML para inspeccionar, copiar o editar el texto de configuración. Ambas vistas editan la misma política; TOML también muestra los campos compatibles que no tienen un control específico. No necesita distribuir un archivo local para usar los ajustes administrados en la nube. Las restricciones de autenticación y las implementaciones administradas por dispositivos tienen una configuración local independiente.

Los administradores de Enterprise pueden controlar el comportamiento compatible de los clientes locales mediante:

• Requisitos: restricciones impuestas por el administrador 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 seguir cambiando los ajustes durante una ejecución. El cliente vuelve a aplicar estos valores predeterminados la próxima vez que se inicia.

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

Configure una política en Seguridad de agentes

Donde Seguridad de agentes esté habilitada, los propietarios y administradores del espacio de trabajo y los miembros con permisos de administración de Codex pueden administrar políticas. El acceso al editor de políticas no concede a los miembros acceso a las funciones que controla una política.

Use Valores predeterminados del espacio de trabajo como base del espacio de trabajo. Use Anulaciones cuando determinados usuarios, grupos o roles necesiten ajustes diferentes. Una excepción por destinatarios selecciona quién recibe una política; un ajuste de entorno selecciona dónde se aplican los controles de ejecución compatibles.

1. Abra Consola de administración > Seguridad de agentes y seleccione Valores predeterminados del espacio de trabajo o la política que quiera editar en Anulaciones.
2. Abra Requisitos para establecer límites obligatorios o Valores predeterminados para establecer valores iniciales que los miembros puedan cambiar dentro de esos límites.
3. Mantenga los ajustes de aprobación, búsqueda web y otros ajustes que afectan a todo el agente en Global. Cuando esté disponible, use Agregar ajustes de entorno en la tarjeta correspondiente para agregar Entornos locales o Entornos de Codex Cloud para los ajustes de ejecución compatibles. Un documento de entorno vacío hereda los ajustes de Global; no copia ni fija la configuración base actual.
4. Use los controles descritos en esta guía. Para los campos avanzados, seleccione Editar como TOML y edite el archivo requirements.toml o config.toml del ámbito correspondiente. Seleccione Usar controles de configuración para volver al editor visual.
5. Revise los mensajes de validación y seleccione Guardar cambios. Aplicar una regla en un editor de reglas actualiza el borrador; no guarda la política por sí solo.
6. Compruebe la selección de políticas y el comportamiento de los clientes compatibles como se describe en Confirme la experiencia del administrador y del empleado.

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

Copie o reutilice una configuración

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

1. Abra la política de origen y seleccione Editar como TOML.
2. Elija el ámbito que quiera copiar: Global o una pestaña de entorno disponible. Copie el texto de Requisitos (requirements.toml), Valores predeterminados (config.toml) o ambos, según lo que quiera reutilizar.
3. Abra la política de destino, seleccione Editar como TOML y elija el ámbito correspondiente. Pegue los requisitos en requirements.toml y los valores predeterminados en config.toml. Revise los ajustes existentes en el destino antes de sustituir el texto; conserve los ajustes no relacionados que deban seguir aplicándose.
4. Revise los mensajes de validación y los destinatarios y la prioridad de la política de destino, y seleccione Guardar cambios. Confirme el comportamiento resultante del cliente antes de confiar en 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, otros documentos de entorno ni la configuración efectiva combinada a partir de otras políticas y ajustes del dispositivo. Copie los ajustes de entorno por separado cuando sea necesario. Cambiar de vista o copiar texto no guarda los cambios de una política.

Pruebe el siguiente ejemplo: cambie un ajuste y seleccione Editar como TOML para ver su configuración. Vuelva con Usar controles de configuración para seguir experimentando.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Elija el control adecuado

Controle el navegador y Computer Use

Use Seguridad de agentes en la consola de administración para gestionar el acceso al navegador y a las aplicaciones nativas en los clientes de escritorio compatibles. Empiece con los controles de la interfaz. Los siguientes ejemplos de TOML ofrecen una referencia de configuración para la distribución de políticas mediante archivos y los ajustes que requieren el editor TOML.

Browser Use controla la actividad del agente en un navegador. Computer Use controla la actividad del agente en las aplicaciones nativas de escritorio. Los ajustes del panel del navegador integrado son independientes de Browser Use. Consulte sesiones del navegador e inicios de sesión existentes para conocer las diferencias entre las vías de acceso al navegador.

Antes de empezar

Use una cuenta con permiso para administrar políticas de Seguridad de agentes. Confirme qué personas reciben la política y qué versiones del cliente y sistemas operativos necesita admitir. Consulte Seguridad de agentes para conocer las asignaciones de políticas, los ajustes de Global y las excepciones de entorno compatibles.

Use Requisitos para establecer límites que los usuarios no puedan anular. Valores predeterminados establece los valores iniciales dentro de esos límites. Permitir un sitio o una aplicación no instala un plugin, no concede permisos del sistema operativo, no inicia la sesión de un usuario ni aprueba una acción que aún requiere revisión.

En Disponibilidad de funciones de escritorio, revise Uso del navegador, Uso del navegador externo y Uso del equipo. Forzar desactivación desactiva la función correspondiente; una regla que permita un sitio o una aplicación no anula esta opción. Revise Acceso completo a CDP por separado; Bloquear activación por parte del usuario impide que los usuarios lo activen.

Estos controles de escritorio no configuran el navegador alojado de Work Cloud. Gestione 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 del equipo en la nube. Consulte cómo se aplica Agent Security a Work Cloud.

Configurar el acceso al navegador

1. Abra Consola de administración > Seguridad de agentes. Use Valores predeterminados del espacio de trabajo como configuración base del espacio de trabajo, o abra la política correspondiente en Anulaciones. En Requisitos, vaya a Controles del navegador de escritorio.
2. En Reglas de sitios, abra las acciones de la fila Predeterminado y elija Editar valor predeterminado. Para limitar el acceso a los sitios aprobados, establezca Acceso al sitio en Bloquear y, después, elija Aplicar regla. La fila Predeterminado proporciona los valores que una regla de sitio coincidente deja en Usar regla predeterminada.
3. Elija Añadir regla de sitio. En Sitio o patrón, introduzca un origen: un esquema, un nombre de host y un puerto opcional. Por ejemplo, https://example.com es válido; https://example.com/files no lo es. No incluya una ruta, una consulta ni un fragmento. HTTP y HTTPS son orígenes diferentes. Especifique el puerto cuando difiera del predeterminado del esquema.
4. Configure Acceso al sitio y revise Descargas, Cargas y Depuración/CDP. Elija Permitir o Bloquear según corresponda, o deje un ajuste en Usar regla predeterminada. Depuración/CDP controla el acceso completo a Chrome DevTools Protocol para la depuración del navegador. Permitir deja que continúen las comprobaciones habituales de políticas y aprobaciones.
5. Revise Revisión automática, Permitir siempre y Duración de la aprobación para el sitio. Duración de la aprobación ofrece Este turno y Este hilo. Revise también Historial del navegador, Guardar aprobaciones de sitios y Aprobar solicitudes automáticamente en Controles del navegador de escritorio.
6. Elija Añadir regla, revise los mensajes de validación y seleccione Guardar cambios. Pruebe un sitio permitido y uno bloqueado en un cliente compatible que reciba la política. Pruebe las cargas, las descargas y otras acciones restringidas por separado.

Añadir regla de sitio

La fila Predeterminado se aplica cuando una regla de sitio deja un permiso en Predeterminado. Si las reglas se superponen, prevalece Bloquear 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

Al desactivar la revisión automática de las acciones del navegador, estas se envían al usuario para su aprobación. Esto no desactiva la supervisión de seguridad del modelo.

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 denegaciones de red administradas y las listas exclusivas de elementos permitidos también se aplican a las herramientas del navegador. Consulte los campos de la política del navegador para conocer los patrones de origen y el comportamiento de aprobación.

Computer Use también puede manejar un navegador como una aplicación nativa. Las reglas de sitios y capacidades de Browser Use no se aplican a esta vía. Revise el acceso a aplicaciones nativas por separado; consulte los límites de seguridad del navegador.

Configurar el acceso a aplicaciones nativas

1. En Requisitos, vaya a Controles de aplicaciones de escritorio > Reglas de aplicaciones.
2. Use las acciones de la fila Predeterminado para configurar el acceso de las aplicaciones sin una regla coincidente. Para limitar Computer Use a las aplicaciones aprobadas, bloquee el acceso de forma predeterminada y añada reglas que permitan esas aplicaciones.
3. Elija Añadir regla de aplicación. En el cuadro de diálogo Editar regla, seleccione ID de paquete de macOS, AUMID de Windows o Ejecutable de Windows en Aplicación. Introduzca el Identificador de aplicación exacto correspondiente a un ID de paquete o un Application User Model ID (AUMID). Para Ejecutable de Windows, introduzca Nombre del editor y Nombre del producto; Nombre del binario es opcional. Use información verificada sobre la identidad de la aplicación, no un nombre para mostrar ni una ruta de archivo.
4. Configure Acceso a la aplicación para la regla y, después, elija Añadir regla. Revise Guardar aprobaciones de aplicaciones en Controles de aplicaciones de escritorio, revise los mensajes de validación y seleccione Guardar cambios. Desactivar las aprobaciones guardadas sigue permitiendo aprobaciones para la sesión actual; permitir que se guarden aprobaciones no aprueba una aplicación.
5. Pruebe una aplicación permitida y una bloqueada en cada sistema operativo compatible de su implementación. Confirme que los permisos del sistema operativo siguen aplicándose y que los usuarios aún deben proporcionar las aprobaciones requeridas.

Editar regla

Configure el acceso predeterminado a las aplicaciones y anúlelo para las aplicaciones coincidentes.

AplicaciónID de paquete de macOS

Identificador de aplicación 

Acceso a la aplicaciónElegir acceso

Consulte los campos de la política de Computer Use para conocer los requisitos de identidad de Windows y las restricciones de uso con el equipo bloqueado para los Mac administrados.

Comprobar la política efectiva

Si un sitio o una aplicación permitidos siguen bloqueados, compruebe otras 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 elude otra denegación aplicable. Consulte las ubicaciones y la precedencia de los requisitos.

Si un ajuste no tiene efecto, verifique que el cliente, el sistema operativo y la vía de entrega de la política lo admitan. Preste especial atención a Work Cloud con acceso al equipo local: algunos campos tienen compatibilidad parcial o requieren validación. Consulte Compatibilidad con Work en la Referencia de configuración.

Compruebe los permisos del espacio de trabajo y los controles de plugins por separado cuando un usuario no pueda acceder a la función o al plugin requerido.

Referencia de configuración TOML

Los siguientes ejemplos describen la misma intención de política para requirements.toml. Úselos al gestionar la política mediante archivos o el editor TOML. No es necesario editar un archivo local para usar los controles disponibles en Agent Security.

Este ejemplo de navegador deniega el acceso de forma predeterminada, permite 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 desactivar la revisión automática de las acciones del navegador, establezca browser_use.disable_auto_review = true, o establezca auto_review = "deny" en una política de origen para restringirla en ese origen.

Para habilitar las herramientas del sitio en un espacio de trabajo Enterprise elegible, establece browser_use.allow_webmcp = true. Esta activación administrada se aplica al navegador integrado de la aplicación de escritorio. Establecerlo en false u omitirlo mantiene vigentes las comprobaciones normales de disponibilidad de funciones; false no impone un bloqueo. Las preferencias del usuario y los permisos del sitio siguen aplicándose.

Este ejemplo de aplicaciones nativas permite Calculadora en macOS, deniega otras aplicaciones de forma predeterminada y evita que las aprobaciones de aplicaciones 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 aplicaciones empaquetadas con computer_use.windows.aumids o archivos ejecutables con computer_use.windows.exes. Las reglas de ejecutables requieren publisher_name, product_name y access; binary_name es opcional.

Para consultar todos los campos y valores admitidos, use la referencia de requirements.toml. Para desactivar una capacidad en lugar de restringir sitios o aplicaciones individuales, consulte Fijar indicadores de funciones.

Otros controles de escritorio

Los siguientes controles de escritorio abarcan la disponibilidad de funciones, Locked Use, Appshots y el control remoto de dispositivos. Use los ajustes específicos para la disponibilidad de funciones y Locked Use; configure Appshots y el control remoto de dispositivos con Editar como TOML. Para conocer las restricciones de destino del tráfico de la aplicación de escritorio, consulte Controlar los destinos de red de la aplicación de escritorio.

Fijar indicadores de funciones

Para las funciones de escritorio disponibles en Agent security, abra Global > Requisitos > Disponibilidad de funciones de escritorio. Establezca Navegador integrado, Uso del navegador, Uso del navegador externo o Uso del equipo en Forzar desactivación para desactivar esa capacidad y, a continuación, seleccione Guardar cambios. Para Acceso completo a CDP, elija Bloquear activación por parte del usuario para impedir que los usuarios lo habiliten. Permitir una función no anula su disponibilidad según el producto, la plataforma o el despliegue.

Para otros indicadores de funciones admitidos, use Editar como TOML y el documento requirements.toml de Global, o una fuente local de requisitos admitida. Los siguientes ejemplos incluyen valores fijados para funciones tanto del entorno de ejecución como 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

Use las claves de función canónicas de la tabla [features] de config.toml para las funciones del entorno de ejecución. El entorno de ejecución local normaliza las funciones reconocidas para cumplir estos valores fijados y rechaza las escrituras en conflicto en config.toml o los ajustes de funciones de archivos de perfil.

Un valor administrado de unified_exec = false mantiene disponible la ejecución de comandos, pero desactiva los procesos reanudables y la herramienta write_stdin. La configuración del usuario no puede desactivar esta función.

• in_app_browser = false desactiva el panel del navegador integrado.
• in_app_updates = false desactiva el actualizador propio de la aplicación de escritorio de ChatGPT al reiniciar, donde se admita. No afecta al despliegue de paquetes externos ni amplía la compatibilidad con versiones anteriores de la aplicación. Para obtener orientación sobre la configuración y el despliegue, consulte Gestionar las actualizaciones de la aplicación.
• browser_use = false desactiva las capacidades admitidas de uso del navegador. El uso del navegador externo y el uso del equipo mediante aplicaciones nativas tienen controles independientes.
• browser_use_full_cdp_access = false desactiva el acceso completo a CDP en el entorno de ejecución local, incluido el modo de desarrollador del navegador, e impide que la aplicación de escritorio de ChatGPT habilite el ajuste correspondiente.
• browser_use_external = false desactiva el uso del navegador por parte del agente mediante extensiones de navegador admitidas.
• computer_use = false desactiva el uso del equipo mediante aplicaciones nativas, incluido el manejo de un navegador como aplicación nativa, junto con Record & Replay y los flujos relacionados de instalación o configuración.

Desactivar únicamente el uso del navegador no bloquea todas las vías de acceso al navegador. El uso del equipo mediante aplicaciones nativas aún puede manejar un navegador cuando se permiten esa capacidad y el acceso a la aplicación; las reglas de sitios y capacidades del uso del navegador no se aplican a esa vía. Para bloquearla, establezca Uso del equipo en Forzar desactivación (computer_use = false), o deniegue la aplicación del navegador en Reglas de aplicaciones si otras aplicaciones nativas deben seguir disponibles. Revise Uso del navegador externo y Navegador integrado por separado. Consulte sesiones del navegador e inicios de sesión existentes para conocer los controles que se aplican a cada vía.

Si omite estas claves, la política permite las funciones, sujetas a la disponibilidad normal del cliente, la plataforma y la implementación.

Restringir el uso del equipo bloqueado

Para impedir que los usuarios habiliten Locked Use en un Mac administrado, abra Global > Requisitos > Controles de aplicaciones de escritorio, establezca Permitir el uso mientras está bloqueado en Desactivado y seleccione Guardar cambios. Este ajuste no desactiva Locked Use en un Mac donde ya esté habilitado.

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

[computer_use]
allow_locked_computer_use = false

Este requisito elimina los controles para habilitar Locked Use. No desactiva Locked Use si ya está habilitado. Si lo omites, se siguen aplicando la disponibilidad normal del producto y la configuración local del usuario.

Desactivar Appshots

Appshots permite que los clientes compatibles incluyan instantáneas de aplicaciones. Para desactivarlo para los usuarios administrados desde la nube, abra Editar como TOML en Agent security y establezca el campo de nivel superior allow_appshots en el documento requirements.toml de Global. Para los despliegues administrados por dispositivos, use la fuente local de requisitos correspondiente:

allow_appshots = false

Donde Appshots esté disponible, allow_appshots = false lo deshabilita. Si omite la clave, los requisitos no limitan Appshots y se aplican las comprobaciones normales de disponibilidad del producto. Los clientes del servidor de aplicaciones que leen los requisitos efectivos mediante configRequirements/read reciben la misma restricción que allowAppshots; un valor de allowAppshots omitido o establecido en null no deshabilita Appshots.

Desactivar el control remoto de dispositivos

Para desactivar el control remoto de dispositivos para los usuarios administrados desde la nube, use Editar como TOML en Agent security y establezca el campo de nivel superior allow_remote_control en el documento requirements.toml de Global. Puede también establecer allow_remote_control en una fuente local de requisitos admitida:

allow_remote_control = false

Donde el control remoto de dispositivos sea compatible, allow_remote_control = false lo deshabilita. Si omite la clave, los requisitos no limitan el control remoto de dispositivos y se aplican las comprobaciones normales de disponibilidad del producto. Este requisito no deshabilita las conexiones remotas SSH.

Configurar aprobaciones y permisos de ejecución

Use esta sección para configurar el comportamiento de las aprobaciones, los límites de permisos y los valores predeterminados iniciales. Comience por Límites de la política y Valores predeterminados. Las tareas posteriores explican los requisitos TOML para imponer el revisor, los perfiles de permisos personalizados, las restricciones del sistema de archivos, las anulaciones de host y las reglas de comandos.

Requisitos impuestos por el administrador (requirements.toml)

Los requisitos restringen los ajustes sensibles para la seguridad (política de aprobación, revisor de aprobaciones, política de revisión automática, modo del entorno aislado, perfiles de permisos, modo de búsqueda web, hooks administrados, qué MCP servers pueden habilitar los usuarios y qué fuentes de marketplaces de plugins pueden usar). Al resolver la configuración (por ejemplo, desde config.toml, archivos de perfil o anulaciones de configuración de la CLI), si un valor entra en conflicto con una regla obligatoria, el cliente local recurre a un valor compatible y notifica al usuario. Si configura una lista de permitidos de mcp_servers, el cliente habilita un MCP server solo cuando tanto su nombre como su identidad coinciden con una entrada aprobada; de lo contrario, el cliente lo deshabilita.

Los requisitos también pueden limitar las marcas de función mediante la tabla [features] de requirements.toml. Tenga en cuenta que las funciones no siempre son sensibles para la seguridad, pero las empresas pueden fijar valores si lo desean. Las claves omitidas quedan sin restricciones.

Para Codex 0.138.0 o posterior, prefiera los perfiles de permisos con allowed_permission_profiles y el valor default_permissions administrado. Use allowed_sandbox_modes solo para implementaciones heredadas que aún configuren sandbox_mode.

Para consultar la lista exacta de claves, consulte la sección requirements.toml de la Referencia de configuración.

Configurar límites de aprobación, entorno aislado y búsqueda web

Use Requisitos > Límites de la política para limitar las opciones admitidas del cliente. Estos controles restringen la configuración; no seleccionan el valor inicial. Configure el valor inicial por separado en Valores predeterminados.

1. En Global, abra Políticas de aprobación y seleccione los tipos de aprobación permitidos. Por ejemplo, Preguntar cuando sea necesario permite al agente solicitar aprobación para acciones como la elevación de permisos del entorno aislado. No preguntar nunca impide las solicitudes de aprobación; no concede una ejecución sin restricciones.
2. Abra Modos de entorno aislado para limitar las opciones de entorno aislado heredadas. Solo lectura restringe las escrituras, Escritura en el espacio de trabajo permite escribir en el espacio de trabajo y en las raíces de escritura configuradas, y Acceso completo elimina el aislamiento del sistema de archivos. Use los requisitos de perfiles de permisos para implementaciones que utilicen perfiles de permisos en lugar de sandbox_mode.
3. En Global, abra Modos de búsqueda web para limitar la búsqueda web. Elija En caché para permitir búsquedas en caché sin búsquedas en tiempo real, o Desactivada para desactivar la búsqueda web. Las restricciones de búsqueda web son independientes de las reglas de red para comandos.
4. Revise las opciones permitidas y los valores predeterminados correspondientes y, a continuación, seleccione Guardar cambios.

Dejar un requisito sin definir no impone ningún límite en esa política. Las demás políticas aplicables siguen vigentes. La opción Preguntar para comandos no confiables corresponde a untrusted en la lista de permitidos de los requisitos; no restablece la configuración explícita retirada approval_policy = "untrusted". Siga las instrucciones de migración que aparecen a continuación para ese caso.

Para limitar la búsqueda web, use 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 vivo incluso en sesiones danger-full-access.

Establecer los valores predeterminados de configuración

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

1. Abra la tarjeta Valores predeterminados de la política. Mantenga los valores predeterminados de todo el agente en Global; use una pestaña de entorno disponible para los valores predeterminados de ejecución compatibles.
2. En Ejecución de comandos, elija la Política de aprobación inicial y el Revisor de aprobaciones, así como el Modo de entorno aislado o los Permisos predeterminados aplicables. El revisor determina quién revisa las solicitudes de aprobación de forma predeterminada; la política de aprobación determina cuándo pueden producirse las solicitudes.
3. En Búsqueda web, elija el modo inicial de Búsqueda web y el Contexto de búsqueda web. En Aplicaciones y herramientas, revise Aplicaciones/conectores, Herramientas de mundo abierto y Herramientas destructivas para las herramientas de aplicaciones compatibles.
4. Confirme que los valores predeterminados cumplen sus Requisitos y, a continuación, seleccione Guardar cambios.

Use Editar como TOML para los valores predeterminados compatibles que no dispongan de controles visuales, como la configuración del marketplace de plugins. Estos valores predeterminados en la nube utilizan la precedencia normal de configuración. Se diferencian de la precedencia heredada de managed_config.toml, que sitúa los valores predeterminados administrados por encima de la configuración local al 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 derivado de trust_level = "untrusted"; no convierte approval_policy = "untrusted" en un ajuste explícito compatible.

Migre la política de aprobación retirada untrusted

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

Para un uso interactivo de solo lectura, seleccione approval_policy = "on-request" con un entorno aislado o perfil de permisos de solo lectura permitido por sus requisitos administrados. Los comandos permitidos por ese entorno aislado pueden ejecutarse sin aprobación.

Para mantener aprobaciones de comandos más estrictas, omita un valor explícito de approval_policy y establezca trust_level = "untrusted" en la entrada del proyecto en el archivo de usuario ~/.codex/config.toml, y mantenga untrusted en allowed_approval_policies. Esto también deshabilita la configuración local del proyecto. Establecer on-request explícitamente anula esa política. Consulte Migre desde la política de aprobación retirada untrusted para ver ejemplos y las implicaciones de seguridad.

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

Para establecer la revisión automática como opción predeterminada, use Global > Valores predeterminados > Ejecución de comandos > Revisor de aprobaciones. Un valor predeterminado permite a los usuarios elegir otro revisor permitido. Para exigir la revisión automática o proporcionar las instrucciones de revisión de su organización, use Editar como TOML y edite el archivo global requirements.toml. Estos requisitos son independientes de los controles de revisión automática del navegador.

Use allowed_approvals_reviewers para exigir o permitir la revisión automática. Establézcalo en ["auto_review"] para exigir la revisión automática o incluya "user" cuando los usuarios puedan elegir la aprobación manual.

Establezca guardian_policy_config para sustituir la sección específica del tenant de la política de revisión automática. El entorno de ejecución local sigue usando la plantilla integrada del revisor y el contrato de salida. El valor administrado guardian_policy_config tiene precedencia sobre el valor local [auto_review].policy.

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

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Controlar los perfiles de permisos disponibles

Use 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 los usuarios o definir perfiles personalizados, use Editar como TOML y configure requirements.toml para el ámbito global o de entorno de ejecución compatible que corresponda. Elegir un valor predeterminado por sí solo no restringe los perfiles disponibles.

Use allowed_permission_profiles para controlar qué perfiles de permisos integrados y personalizados pueden seleccionar los usuarios. Este es el equivalente de allowed_sandbox_modes para perfiles de permisos; use la lista de permitidos que coincida con la forma en que sus usuarios seleccionan los permisos.

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

Use los ejemplos de perfiles de permisos siguientes solo después de que todos los clientes administrados ejecuten una versión compatible. No implemente perfiles personalizados administrados hasta que se haya completado la actualización de toda la flota.

Cuando está presente, la tabla constituye 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 acceso de solo lectura y al espacio de trabajo, pero no acceso completo:

default_permissions = ":workspace"

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

Agregar un valor predeterminado administrado de privilegios mínimos

Los administradores pueden definir un perfil personalizado en la misma fuente de requisitos. Use nombres de perfil específicos de la organización que no entren en conflicto con los nombres de la configuración cargada de los usuarios. Los nombres personalizados no pueden comenzar por : ni usar el nombre reservado filesystem.

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

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

Omita todos los perfiles integrados cuando los usuarios solo deban seleccionar 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 ampliar :workspace aunque los usuarios no puedan seleccionar directamente el perfil integrado :workspace.

Desactivar un perfil permitido por otra fuente

Las listas de permisos se combinan por nombre de perfil. Como los requisitos de la nube tienen mayor precedencia que los requisitos del sistema, los requisitos de la nube pueden usar false para desactivar un perfil permitido por 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.

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

Aplicar requisitos de denegación de lectura

Use Editar como TOML para añadir restricciones del sistema de archivos al archivo requirements.toml global o del entorno de ejecución compatible que corresponda. Estas restricciones bloquean la lectura de rutas sensibles; un valor predeterminado de solo lectura por sí solo no oculta archivos.

Los administradores pueden denegar lecturas de rutas exactas o patrones glob con [permissions.filesystem]. Los usuarios no pueden debilitar estos requisitos mediante 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 existen 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 entorno aislado de solo lectura o del espacio de trabajo para poder aplicarlos. En Windows nativo, el valor administrado deny_read se aplica a las herramientas directas de archivos; las lecturas de subprocesos del shell no usan esta regla del entorno aislado.

Anular los requisitos del entorno aislado según el host

Use Editar como TOML en Seguridad de agentes para crear requisitos específicos de cada 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.

Use [[remote_sandbox_config]] cuando una política administrada deba aplicar distintos requisitos del entorno aislado en hosts diferentes. Por ejemplo, puede mantener un valor predeterminado más estricto para portátiles y permitir escrituras en el espacio de trabajo en equipos de desarrollo o ejecutores de CI coincidentes. Actualmente, las entradas específicas del host solo anulan 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 hostname_patterns con el nombre de host resuelto mediante el mejor esfuerzo. Prefiere el nombre de dominio completo cuando está disponible y, de lo contrario, usa el nombre de host local. La coincidencia no distingue entre mayúsculas y minúsculas; * coincide con cualquier secuencia de caracteres y ? coincide con un carácter.

La primera entrada [[remote_sandbox_config]] coincidente prevalece dentro de la misma fuente de requisitos. Si no coincide ninguna entrada, el entorno de ejecución local conserva el valor de nivel superior allowed_sandbox_modes. La coincidencia del nombre de host solo sirve para seleccionar políticas; no la trate como una prueba autenticada del dispositivo.

Aplicar reglas de comandos desde los requisitos

Use Editar como TOML en Seguridad de agentes para añadir reglas de comandos y restricciones de MCP servers al archivo global requirements.toml. Las reglas de comandos especifican decisiones de aprobación o denegación para los comandos coincidentes; las restricciones de MCP limitan qué identidades de servidor puede habilitar el cliente. El control Políticas de aprobación no permite crear ninguno de estos conjuntos de reglas.

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

A diferencia de .rules, las reglas de requisitos deben especificar decision, y esa decisión 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 qué MCP servers puede habilitar un cliente local, agregue una lista de aprobados mcp_servers. Para servidores stdio, establezca la coincidencia con command; para servidores HTTP transmitibles, establézcala con url:

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

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

La forma de cadena de identity.command solo coincide con el valor command configurado. No inspecciona args, cwd, env ni env_vars.

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

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

El ejecutable, la cantidad de argumentos y el orden de los argumentos deben coincidir. Las reglas de argumentos y URL admiten la coincidencia con exact, prefix y el valor completo regex. Las reglas de comandos estructuradas siguen sin inspeccionar cwd, env ni env_vars. Los MCP servers incluidos en plugins usan las mismas formas de identidad en plugins.<plugin>.mcp_servers.<server>.

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

Configurar el acceso a la red

El acceso a la red de los comandos y el de las aplicaciones de escritorio utilizan controles diferentes. Empiece por Controles de uso de la red para el tráfico de comandos compatible, revise los límites del entorno y del entorno de ejecución y, después, utilice los requisitos independientes de las aplicaciones de escritorio si es necesario. Las reglas de sitios del navegador siguen estando en Controlar el navegador y Computer Use.

Configurar requisitos de acceso a la red

Use Requisitos > Controles de uso de la red para administrar el acceso a la red de los comandos compatibles en Seguridad de agentes. Configure una base compartida en Global, o en una pestaña disponible de Entornos locales o Entornos de Codex Cloud para los ajustes de ejecución específicos de cada entorno.

1. Establezca Red administrada en Activado para aplicar reglas de dominio al tráfico de comandos administrado. Añadir reglas de dominio por sí solo no activa el proxy administrado.
2. En Reglas de red, seleccione Añadir regla de red. Introduzca un Dominio, como api.openai.com o **.example.com, sin esquema de URL ni ruta. Elija Permitir o Denegar en Acceso y luego seleccione Guardar regla para actualizar el borrador. Repita el proceso para otros destinos.
3. Establezca Permitir solo dominios añadidos por administradores en Activado si la configuración del usuario y las aprobaciones por dominio no deben ampliar la lista de dominios permitidos administrada. Incluya las entradas Permitir necesarias; una lista que solo deniega no permite otros destinos.
4. Revise Permitir acceso a la red local para los flujos de trabajo que necesitan servicios de escucha locales o destinos privados. Las conexiones locales directas pueden eludir las reglas de dominio del proxy. Revise los límites de conectividad de Codex Cloud que se indican a continuación antes de cambiar esta configuración.
5. Revise las reglas heredadas y los mensajes de validación y luego seleccione Guardar cambios. Pruebe una solicitud que deba completarse correctamente y otra que deba bloquearse en cada entorno de ejecución afectado.

Establecer Red administrada en Desactivado borra las reglas de red definidas en ese ámbito y guarda un valor explícito de desactivación; no desactiva el acceso a internet. Sin establecer elimina la configuración de red definida en ese ámbito para que puedan aplicarse la política correspondiente o los valores predeterminados del entorno de ejecución. Eliminar la configuración del entorno puede hacer que se apliquen las reglas heredadas de Global. Use Editar como TOML para los campos de red avanzados o las listas de dominios heredadas existentes que el editor visual no puede representar.

Usa [experimental_network] en requirements.toml cuando los administradores deban definir de forma centralizada los requisitos de acceso a la red. Estos requisitos son independientes del selector de usuario features.network_proxy: pueden configurar la conexión de red del entorno aislado sin esa marca de función, pero no conceden acceso de red a los comandos cuando el entorno aislado activo mantiene la conexión de red desactivada. Establece experimental_network.enabled = true para activar el proxy administrado; las reglas de dominio por sí solas no activan el proxy.

[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 cuando también definas entradas "allow" administradas por los administradores en [experimental_network.domains] y quieras que esas reglas sean exclusivas. Si es true y no hay reglas de permiso administradas, las reglas de permiso de dominios añadidas por el usuario dejan de ser efectivas. No combines el mapa canónico domains con las listas heredadas allowed_domains o denied_domains.

*.example.com coincide únicamente con subdominios. **.example.com coincide con el dominio raíz y sus subdominios. Una regla de denegación coincidente prevalece sobre una regla de permiso.

La sintaxis de dominios, las reglas de destinos locales y privados, el comportamiento de denegación sobre permiso y las limitaciones de revinculación de DNS son iguales que en el comportamiento de red del entorno aislado descrito en Aprobaciones y seguridad del agente.

El proxy enruta los comandos locales que se ejecutan dentro del entorno aislado. Las herramientas del navegador también comprueban las denegaciones de red administradas y las listas exclusivas de permitidos antes de acceder a un origen. Se trata de una comprobación de políticas independiente, que no enruta el tráfico del navegador a través del proxy de comandos. No filtra la búsqueda web, las aplicaciones y los conectores, los MCP servers, el tráfico de aplicaciones nativas, las solicitudes al servicio de Codex ni otro tráfico específico de cada capacidad. Use los controles de cada interfaz:

• Use allowed_web_search_modes para restringir la búsqueda web.
• Use features.apps = false para desactivar las integraciones de aplicaciones y conectores, y features.plugins = false para desactivar los plugins donde se admita.
• Use la lista administrada de mcp_servers aprobados para restringir los MCP servers.
• Use requisitos de funcionalidades como browser_use, in_app_browser y computer_use para restringir las capacidades de uso del navegador y del equipo.
• Para los comandos administrados compatibles de Codex Cloud, configure por separado los requisitos de Agent Security y los ajustes de internet del entorno de Cloud.

Una lista de dominios permitidos para comandos no sustituye estos controles específicos de cada capacidad.

En las vías de ejecución administradas compatibles de Codex Cloud, los requisitos de Agent Security restringen el acceso a la red de los comandos. Los ajustes de internet del entorno de Codex Cloud se aplican por separado. Un dominio permitido en Agent Security no anula una restricción de los ajustes de internet del entorno de Cloud. Estos controles de red de comandos no desactivan por sí solos la búsqueda web alojada, las aplicaciones ni MCP. ChatGPT Work Cloud tiene permisos de capacidades independientes y no hereda estos requisitos de Agent Security.

Una lista administrada de permitidos para comandos se aplica a los comandos que usan el proxy administrado. Cuando la política permite la elevación completa fuera del entorno aislado y esta se aprueba, esa ejecución puede eludir el proxy de comandos. Una concesión de acceso limitado a la red es distinta de una elevación completa fuera del entorno aislado. Configure requisitos obligatorios de aprobación y del entorno aislado para el límite previsto, y pruebe tanto los comandos ordinarios como los ejecutados con privilegios elevados.

Sin destinos permitidos efectivos: Cuando Red administrada y Permitir solo dominios añadidos por administradores están activados, los comandos administrados ordinarios necesitan destinos permitidos efectivos. Si no hay entradas Permitir configuradas ni heredadas, esos comandos no tienen destinos permitidos. Una política que solo deniega no permite implícitamente el resto de internet. Añada las entradas Permitir necesarias y compruebe las reglas heredadas antes de guardar. Esta restricción se aplica al proxy de comandos administrado, no a todas las herramientas ni a las elevaciones completas aprobadas de los permisos del entorno aislado.

Conectividad local/privada de Codex Cloud: Un valor explícito de Desactivado para la conectividad local/privada puede impedir que Codex Cloud acceda a su proxy ascendente, incluso si el dominio de destino está permitido. Comprueba el valor final de allow_local_binding e identifica qué política o ajuste lo proporciona. En la ruta de proxy de Cloud compatible, el valor predeterminado es true solo cuando ningún requisito aplicable, perfil de red seleccionado o ajuste de la función de proxy proporciona un valor. Un valor false heredado también cuenta como un ajuste explícito. Cuando sea compatible, establece una anulación de Cloud de mayor prioridad para cambiar este valor en Codex Cloud sin modificar el valor de Global que usa Local. Esto no añade entradas de dominios permitidos. Verifica la compatibilidad del ejecutor antes de depender de la anulación. No apliques este valor predeterminado de Cloud a Local.

Cuando los requisitos del entorno están vacíos, se aplican los requisitos de Global. Establecer Red administrada en Desactivado es independiente de la configuración de acceso a internet del entorno Cloud. Consulte Controles de ejecución de Seguridad de agentes 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 misma política, el orden de mayor a menor prioridad es: anulación del entorno específica del sistema operativo → anulación del entorno para todos los sistemas operativos → Global. Una política de mayor prioridad sigue prevaleciendo sobre una de menor prioridad, incluso cuando esta última es más específica. Algunos requisitos tienen reglas de combinación específicas de cada campo. El entorno de ejecución aplica después los requisitos resultantes. Considere los siguientes casos de red específicos de cada campo por separado de la prioridad de las políticas.

Estos ejemplos comparan la configuración del entorno y la de Global dentro de una misma política, con la red administrada ya configurada y sin que ninguna política de mayor prioridad cambie los valores. Describen el comportamiento de combinación y de ejecución específico de cada campo.

Configure distintos accesos a dominios según el entorno

Para una misma regla de dominio dentro de una política, una anulación del entorno definida por un administrador puede permitir un dominio denegado en Global o denegar un dominio permitido en Global. Si no hay una anulación del entorno, se hereda la regla de Global. Otras reglas Deny o controles de acceso vigentes 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 ninguna política de mayor prioridad cambie el resultado. Un valor de mayor prioridad sustituye el valor de la misma clave. Las demás claves heredadas se conservan. Una regla Allow no elude otra regla Deny coincidente, como un comodín heredado. Un mapa de entorno vacío no elimina las reglas heredadas.

Ejemplo: Deniegue packages.example.com en Global y permítalo en Development. Development puede permitirlo bajo las condiciones anteriores. Production hereda la regla Deny de Global, salvo que se anule.

Confirme que el ejecutor desplegado admite estas reglas de combinación. La compatibilidad de los ejecutores administrados habituales aún debe validarse.

Límites de Orchestrator. El entorno de ejecución en la nube no admite puertos de escucha HTTP/SOCKS administrados ni servicios de escucha de proxy en direcciones que no sean de bucle local; la compatibilidad con las reglas de sockets depende de la vía de ejecución. Un ajuste de ejecución local de la tabla siguiente no constituye una configuración compatible con Orchestrator.

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

Todos los nombres de campo siguientes se encuentran bajo experimental_network en requirements.toml. Las flechas muestran un valor de Global seguido de un valor del entorno dentro de la misma política. Estos casos de ejecución local no confirman que Orchestrator admita los mismos ajustes.

La activación del proxy, la exclusividad, el comportamiento del proxy ascendente y las reglas de sockets Unix tienen un comportamiento específico de cada ejecutor. No generalice la combinación de claves de dominio a estos ajustes. Verifique los valores vigentes y pruebe el entorno de ejecución desplegado. Para la conectividad local o privada de Codex Cloud, consulte Configure los requisitos de acceso a la red.

Verifique el comportamiento antes de la implementación

Pruebe los destinos reales, los servicios de escucha locales, el comportamiento del proxy y las rutas de sockets que utilizan sus flujos de trabajo. Compruebe una acción que deba completarse correctamente y otra que deba bloquearse en cada entorno afectado. Compruebe que la versión del entorno de ejecución desplegada admite cada ajuste que utilice.

Controlar los destinos de red de la aplicación de escritorio

Use Editar como TOML en Seguridad de agentes para configurar estos requisitos específicos de la aplicación de escritorio en Global. La interfaz de Controles de uso de la red gestiona la conectividad de red de los comandos, que constituye una política independiente.

Usa [application.network] en requirements.toml para restringir los destinos de red de la aplicación de escritorio. Con enabled = true, las solicitudes externas deben usar HTTPS o WSS y coincidir con un dominio exacto 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 las reglas de red de los comandos y de origen del navegador. No impone restricciones de destino a los módulos nativos ni a los procesos iniciados, y no regula la ejecución de Work Cloud.

Configurar plugins y hooks administrados

Para estas tareas, use Editar como TOML en Seguridad de agentes o una fuente de configuración local compatible. Los valores predeterminados de los marketplaces, las restricciones obligatorias de plugins y los hooks administrados tienen distintas finalidades; elija la tarea que corresponda a la política que necesita.

Configurar marketplaces de plugins y valores predeterminados

Use Seguridad de agentes > Editar como TOML para definir marketplaces locales o de Git y valores predeterminados de plugins en el documento config.toml de Global. También puede distribuir esta configuración en el config.toml del sistema. Proporciona una configuración inicial de marketplaces y plugins, no una política obligatoria. Para limitar las fuentes que los miembros pueden usar, configure los requisitos de las fuentes de marketplaces.

Consulte la Referencia de configuración para conocer las claves de configuración, Precedencia de configuración para conocer las reglas de anulación y los ajustes de plugins del repositorio para la configuración del proyecto. La importación y sincronización de GitHub del espacio de trabajo se gestiona por separado.

Controlar la disponibilidad de plugins

Use Editar como TOML en Seguridad de agentes para establecer la configuración obligatoria de las funciones de plugins en requirements.toml de Global, o distribúyala mediante requisitos locales para clientes administrados a nivel de dispositivo. Valores predeterminados > Aplicaciones y herramientas > Aplicaciones/conectores establece los valores predeterminados de las herramientas de aplicaciones; no es el interruptor obligatorio features.plugins. Para los permisos de plugins del espacio de trabajo, consulte Aplicaciones y conectores.

Para desactivar los plugins en los clientes locales compatibles, establezca features.plugins en false dentro de requirements.toml:

features.plugins = false

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

Restringir las fuentes de marketplaces de plugins

Use Editar como TOML para configurar los requisitos de origen de los marketplaces en el archivo Global requirements.toml, o distribúyalos mediante requisitos locales. Estas reglas limitan qué orígenes locales o de Git pueden añadir y usar los usuarios. Son independientes de los valores predeterminados de los marketplaces.

Para restringir las fuentes de marketplaces de plugins, establezca restrict_to_allowed_sources = true y defina 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 coinciden con la URL normalizada del repositorio y, cuando está presente, con un valor ref exacto. Los patrones de host son expresiones regulares que se comparan con el host de Git en minúsculas; use ^ y $ para una coincidencia de host completo. Las reglas locales requieren una ruta absoluta y normalizada. Consulte la referencia de requirements.toml para conocer el esquema completo y el comportamiento de combinación.

Estos requisitos rechazan las operaciones de adición de marketplaces, instalación de plugins y actualización de marketplaces de Git configurados que no coincidan con las reglas. También filtran los marketplaces configurados y sus plugins durante la ejecución.

Los marketplaces de Git seleccionados por OpenAI, incluido el catálogo de API key, también deben coincidir con la lista de fuentes permitidas. Para permitirlos, incluya 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, omita esa fuente y asegúrese de que ninguna regla de host más amplia la permita. Los plugins incluidos y los plugins del espacio de trabajo instalados de forma remota son independientes de esta política de fuentes de Git seleccionadas.

Estas restricciones de origen solo se aplican cuando un cliente local admite operaciones del marketplace de plugins: ChatGPT y Codex en la aplicación de escritorio, y Codex CLI. No controlan el uso de plugins en ChatGPT para la web o dispositivos móviles, ni añaden plugins a la extensión del IDE.

Aplicar hooks administrados desde los requisitos

Los hooks administrados ejecutan acciones definidas por el administrador ante eventos de tareas o herramientas compatibles. Use Editar como TOML en Agent Security para configurarlos en el archivo Global requirements.toml; los controles de configuración no incluyen un editor específico de hooks. Las rutas de ejecución que se describen a continuación determinan qué tipos de hooks pueden ejecutarse.

Cuando la política administrada y los hooks remotos están habilitados, Work Cloud con acceso local y dots usan hooks MCP remotos administrados por los administradores en el orquestador de la nube. Configura los controladores mcp_tool en requirements.toml de Global. Work Cloud sin acceso local y las cuentas personales no usan estos hooks empresariales. Los controladores de comandos/shell, prompts y agentes; los hooks de la configuración local, los plugins o los directorios locales; los hooks con ámbito de entorno; y los hooks MCP SessionEnd no son compatibles con la orquestación en la nube, incluso cuando las herramientas se ejecutan localmente. Cuando tanto la orquestación como la ejecución son locales, los hooks compatibles existentes siguen funcionando en los hilos exclusivamente locales de Work y Codex. Los administradores pueden seguir configurando hooks administrados compatibles en Agent Security para esos flujos de trabajo.

Antes de depender de estos hooks, prueba la conectividad de las llamadas de retorno, los eventos necesarios y el comportamiento ante fallos. Una denegación explícita compatible puede bloquear una acción, pero un error, un tiempo de espera agotado o una respuesta mal formada en una llamada de retorno de PreToolUse pueden hacer que el hook falle sin bloquear la herramienta. Los hooks MCP no proporcionan un registro de auditoría completo de Compliance API. Los siguientes ejemplos de scripts y directorios mantienen su ámbito de Codex.

Los administradores también pueden definir hooks administrados del ciclo de vida directamente en requirements.toml. Use [hooks] para la propia configuración de los hooks y haga que managed_dir apunte al directorio donde sus herramientas de MDM o gestión de puntos de conexión instalan los scripts referenciados.

Para aplicar hooks administrados incluso a usuarios que los hayan desactivado localmente, fije [features].hooks = true junto con [hooks]. Para omitir hooks de usuario, proyecto, sesión y plugin sin dejar de permitir hooks administrados, establezca allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

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

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Notas:

• El entorno de ejecución local aplica la configuración de hooks de requirements.toml, pero no distribuye los scripts de managed_dir.
• Suministre esos scripts con su solución de MDM o gestión de dispositivos.
• Los comandos de hooks administrados deben hacer referencia a rutas absolutas de scripts dentro del directorio administrado configurado.
• allow_managed_hooks_only = true omite hooks de fuentes de usuario, proyecto, sesión y plugin, pero sigue cargando hooks de requirements.toml y otras capas de configuración administradas.

Comprenda el ámbito y la precedencia de las políticas

Use esta sección para comprobar dónde se aplica una política, cómo se combinan los requisitos, cómo reciben los clientes la configuración administrada en la nube y cómo verificar el resultado.

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

Agent Security y acceso al equipo local con Work Cloud

Use Agent Security en la consola de administración para administrar las políticas y la configuración. Sustituye a Políticas y configuración. Agent Security está disponible en la consola de administración, independientemente del acceso al equipo local con Work Cloud. Se conservan las políticas, las asignaciones y el orden existentes. Revise sus políticas existentes en Agent Security. El acceso al equipo local con Work Cloud se habilita por separado de forma opcional. Consulte Agent Security para obtener orientación sobre la migración.

Antes de trasladar la automatización de políticas a Seguridad de agentes:

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

2. Usa la API de políticas para gestionar los ajustes de Global. Para gestionar los ajustes de Local o Codex Cloud, usa la interfaz de Seguridad de agentes. Los flujos de trabajo existentes de la API de Global siguen disponibles tras la migración. Prueba tus scripts e integraciones de Terraform y confirma que las asignaciones y el orden de las políticas no hayan cambiado.

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

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

Las anulaciones por entorno permiten variar los ajustes compatibles dentro de una política. Dentro de una política determinada, el orden de mayor a menor prioridad es: anulación por entorno específica del sistema operativo → anulación por entorno para todos los sistemas operativos → Global. Una política de mayor prioridad sigue prevaleciendo sobre una de menor prioridad, incluso cuando esta última es más específica. Algunos requisitos tienen reglas de combinación específicas de cada campo. Confirma qué editores de anulaciones y campos están disponibles para tu espacio de trabajo.

Cuando la política administrada y los hooks remotos están habilitados, Work Cloud con acceso local y dots usan hooks MCP remotos administrados por el administrador en el orquestador en la nube. Configura los manejadores de mcp_tool en el archivo requirements.toml de Global. Work Cloud sin acceso local y las cuentas personales no usan estos hooks empresariales. Los manejadores de comandos/shell, prompts y agentes; los hooks de la configuración local, los plugins o los directorios locales; los hooks con alcance de entorno; y los hooks MCP de SessionEnd no son compatibles con la orquestación en la nube, incluso cuando las herramientas se ejecutan localmente. Cuando tanto la orquestación como la ejecución son locales, los hooks compatibles existentes siguen funcionando en los hilos exclusivamente locales de Work y Codex. Los administradores pueden seguir configurando hooks administrados compatibles en Seguridad de agentes para esos flujos de trabajo. Antes de depender de estos hooks, prueba la conectividad de las llamadas de retorno, los eventos necesarios y el comportamiento ante fallos. Una denegación explícita compatible puede bloquear una acción, pero un error, un tiempo de espera agotado o una respuesta mal formada en una llamada de retorno de PreToolUse pueden hacer que el hook falle sin bloquear la herramienta. Los hooks MCP no proporcionan un registro de auditoría completo de la Compliance API. Consulta la Referencia de configuración.

Ubicaciones y precedencia

Para la ejecución local, los requisitos se aplican de menor a mayor prioridad como se indica a continuación. Este orden también se aplica a los pasos locales del acceso al equipo local con Work Cloud:

1. 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. Requisitos de Seguridad de agentes distribuidos en el paquete de configuración en la nube.
3. Campos heredados de managed_config.toml que el cliente local reinterpreta como requisitos.
4. Preferencias administradas de macOS (MDM) distribuidas mediante com.openai.codex:requirements_toml_base64.

Las capas con mayor precedencia anulan los valores escalares y de lista ordinarios de las capas inferiores. Las tablas se combinan por clave, mientras que requisitos como reglas, hooks y restricciones del sistema de archivos tienen comportamientos de composición específicos de cada campo. Use la referencia de requirements.toml para consultar el esquema actual en lugar de suponer que todos los campos se combinan de la misma manera.

Por 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; use requirements.toml para listas de permitidos explícitas.

Precedencia para el acceso al equipo local con Work Cloud

Para Work con acceso local y dots, distingue la política Global del orquestador de la política de ejecución. Los requisitos locales aplicables rigen el equipo conectado. Los contenedores de Work en la nube y los equipos en la nube de dots usan su propia configuración y sus propios requisitos de ejecución, en lugar del paquete de entorno administrado que utilizan otros ejecutores.

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

Los requisitos imponen restricciones, mientras que los valores predeterminados de configuración proporcionan valores iniciales. Para Work con acceso local y dots, la política Global compatible se aplica a través del orquestador compartido en la nube cuando la política administrada está habilitada. Los requisitos locales aplicables de requirements.toml rigen la ejecución en un equipo conectado. Los contenedores de Work en la nube y los equipos en la nube de dots usan su propia configuración y sus propios requisitos de ejecución, en lugar del paquete de entorno administrado que utilizan otros tipos de ejecutores. Las restricciones de ejecución local no se aplican automáticamente a estos equipos en la nube. Revisa los permisos de las capacidades en la nube y prueba por separado la ejecución local y en la nube.

Mantenga los controles del orquestador, incluidas las aprobaciones y la búsqueda web, en Global. Use los controles específicos Políticas de aprobación permitidas y Modos de búsqueda web permitidos cuando estén disponibles, y TOML para los demás campos compatibles. Consulte la Referencia de configuración para ver la lista de campos y su ámbito de ejecución.

Requisitos administrados en la nube

Cuando un usuario inicia sesión con ChatGPT en un plan compatible, los clientes locales compatibles pueden recibir requisitos obligatorios establecidos por el administrador y asociados al espacio de trabajo. Este es un canal de distribución de políticas compatibles con requirements.toml. No concede acceso al espacio de trabajo ni sustituye su RBAC. Los requisitos de autenticación deben administrarse localmente.

Configure los requisitos comunes con los controles de seguridad de agentes. Para una política que permita únicamente aprobaciones on-request y entornos aislados read-only o workspace-write, use Políticas de aprobación y Modos de entorno aislado en Límites de la política. Para solicitar también aprobación antes de que se ejecute un punto de entrada de shell compatible, use Editar como TOML para añadir la tabla [rules] a requirements.toml en Global.

El equivalente completo en TOML 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" },
]

Compruebe que todas las versiones de los clientes administrados admitan las claves que seleccione. Asigne la política a los usuarios o grupos previstos y verifique que surta efecto en sus clientes compatibles. Use la referencia de configuración para consultar el esquema actual y la interfaz de administración para consultar el comportamiento actual de las asignaciones.

El servicio selecciona las capas de requisitos administradas por la empresa que se aplican a la identidad que ha iniciado sesión. El cliente local evalúa esas capas junto con las demás fuentes de requisitos descritas en Ubicaciones y precedencia. Use la superficie de administración actual para crear y asignar elementos en el espacio de trabajo. No dependa de un algoritmo de coincidencia de grupos copiado; el servicio de administración controla ese comportamiento y puede cambiarlo independientemente del formato de requisitos local.

Para conocer las claves compatibles y ver ejemplos, consulte Ejemplo de requirements.toml y la referencia de requirements.toml.

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

El comportamiento de carga y caché local que se describe a continuación corresponde a los clientes locales compatibles. No establece cuándo surte efecto una política de nube modificada en una tarea que ya está en ejecución y utiliza el acceso al equipo local con Work Cloud. Verifique la política vigente antes de confiar en una restricción modificada.

Cuando un usuario inicia un cliente local compatible e inicia sesión con ChatGPT en un plan compatible, el cliente comprueba primero si existe una entrada de caché válida que coincida con la identidad. Si no hay ninguna entrada válida disponible, el cliente obtiene el paquete aplicable con reintentos y escribe una entrada de caché firmada si la operación se completa correctamente. Si la solicitud falla o agota el tiempo de espera y no hay una caché válida disponible, la carga del paquete de configuración en la nube devuelve un error en lugar de iniciarse silenciosamente sin la capa de requisitos administrados en 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 actualiza el paquete almacenado en caché y lo pone a disposición de las siguientes cargas de configuración. Esto no garantiza que una tarea que ya esté en ejecución use inmediatamente una política modificada. Algunos ajustes de escritorio requieren reiniciar la aplicación; siga cualquier indicación de reinicio y verifique los ajustes efectivos antes de confiar en el cambio.

Confirma la experiencia del administrador y del empleado

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 del sistema de archivos, la red, las aprobaciones o el perfil de permisos.

Pruebe un flujo de trabajo permitido y otro bloqueado con un usuario que tenga los permisos previstos. Compruebe los ajustes vigentes en el cliente compatible. Un rol o grupo del espacio de trabajo por sí solo no impone una restricción en el entorno de ejecución local.

Use Probar políticas en Seguridad de agentes para comprobar qué políticas coinciden con una selección de miembro, grupo o rol. En una sesión editable, esto comprueba el borrador actual sin guardarlo. El resultado muestra la selección de políticas, no la configuración final combinada ni si un cliente aplica una restricción. Después de guardar, pruebe los flujos de trabajo permitidos y bloqueados en cada cliente y vía de ejecución pertinentes.

Implemente la configuración administrada en los dispositivos

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

Administre la autenticación localmente

Establezca allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store y chatgpt_base_url en el archivo del sistema local requirements.toml o en los requisitos de MDM de macOS. Codex ignora estos cuatro campos en los requisitos administrados en la nube. Los requisitos de autenticación locales se aplican antes de cargar las credenciales y antes de que Codex obtenga 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, use:

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 se omite, este ajuste no restringe los métodos de inicio de sesión. Si se establece, la lista debe contener al menos un método. api permite la autenticación mediante API, incluido Amazon Bedrock. La restricción del espacio de trabajo también se aplica a los tokens de acceso de Codex.

Los valores de 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 no coincide ningún espacio de trabajo, el inicio de sesión con ChatGPT no está disponible. La autenticación mediante API sigue disponible cuando está permitida. Si ningún método de inicio de sesión está disponible, Codex se niega a iniciarse.

Consulte la referencia de requisitos para conocer los modos de almacenamiento de credenciales y la configuración de la URL del servicio.

Valores predeterminados administrados (managed_config.toml)

Use los Valores predeterminados de Seguridad de agentes para los valores iniciales compatibles administrados en la nube. Esta sección trata el mecanismo heredado de administración en dispositivos managed_config.toml y su distinta precedencia de inicio. Editar los Valores predeterminados en Seguridad de agentes no implementa un archivo managed_config.toml en los dispositivos de los miembros.

Los valores predeterminados administrados establecen la configuración con la que se inicia un cliente local compatible. Al iniciarse, sustituyen el config.toml local del usuario y cualquier anulación de la CLI mediante --config. Los usuarios aún 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 con el inicio de sesión de ChatGPT el 14 de octubre de 2026 al mediodía PDT (19:00 UTC). Si un valor predeterminado administrado, un perfil 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 cuando un administrador lo haya habilitado para los usuarios afectados. La API de OpenAI y las sesiones de Codex autenticadas con una API key no se ven afectadas. Consulta la disponibilidad de modelos del espacio de trabajo.

Para las configuraciones que todavía fijan gpt-5.4 o gpt-5.4-mini, sigue las orientaciones para migrar desde GPT-5.4.

Asegúrese de que sus valores predeterminados administrados cumplan sus requisitos; el entorno de ejecución local rechaza los valores no permitidos.

Precedencia y capas

El entorno de ejecución local ensambla la configuración efectiva en este orden (la parte superior anula la inferior):

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

Las anulaciones --config key=value de CLI se aplican a la base, pero las capas administradas las anulan. Esto significa que cada ejecución comienza con los valores predeterminados administrados aunque proporcione marcas locales.

El archivo config.toml en la nube usa la precedencia de configuración normal, no el orden heredado anterior. El archivo requirements.toml en la nube usa la precedencia de requisitos.

Ubicaciones

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

Si falta el archivo, 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"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Medidas de protección recomendadas

• Prefiera workspace-write con aprobaciones para la mayoría de los usuarios; reserve el acceso completo para contenedores controlados.
• Mantenga network_access = false a menos que su revisión de seguridad permita un recopilador o los dominios requeridos por sus flujos de trabajo.
• Use la configuración administrada para fijar los ajustes de OTel (exportador, entorno), pero mantenga log_user_prompt = false a menos que su política permita explícitamente almacenar el contenido de las instrucciones.
• Audite periódicamente las diferencias entre el archivo config.toml local y la política administrada para detectar desviaciones; las capas administradas deben prevalecer sobre las marcas y los archivos locales.

Preferencias administradas de macOS (MDM)

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

• 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 de «preferencias administradas» como TOML. Para los valores predeterminados administrados (config_toml_base64), las preferencias administradas tienen la máxima prioridad. Para los requisitos (requirements_toml_base64), la prioridad sigue el orden de los requisitos. La misma tabla [features] de los requisitos funciona en requirements_toml_base64; use allí también las claves canónicas de las funciones.

Flujo de configuración de MDM

El entorno de ejecución local respeta las cargas útiles estándar de MDM de macOS, por lo que puede distribuir ajustes con herramientas como Jamf Pro, Fleet o Kandji. Una implementación ligera tiene este aspecto:

1. Cree el TOML de la carga útil administrada y codifíquelo con base64 (sin ajuste de línea).
2. Coloque la cadena en su perfil MDM, bajo el dominio com.openai.codex, en config_toml_base64 (valores predeterminados administrados) o requirements_toml_base64 (requisitos).
3. Envíe el perfil y pida a los usuarios que reinicien el cliente local compatible y confirmen que el resumen de configuración de inicio refleje los valores administrados.
4. Al revocar o cambiar la política, actualice la carga útil administrada; el cliente lee la preferencia actualizada la próxima vez que se inicia.

Evite incluir secretos o valores dinámicos que cambien con frecuencia en la carga útil. Trate el TOML administrado como cualquier otro ajuste de MDM sujeto al control de cambios.