Documentación de ChatGPT
Español
Contacto goolvyouyou@gmail.com

Configuración administrada

Configuración administrada

Distribuya valores predeterminados de configuración e imponga requisitos en los clientes locales compatibles

La configuración administrada controla el comportamiento compatible del entorno de ejecución local para las capacidades incluidas en la aplicación de escritorio de ChatGPT, Codex CLI y la extensión de IDE. Los requisitos compatibles pueden variar según el cliente y la versión. La configuración administrada no concede acceso al espacio de trabajo de ChatGPT, no asigna puestos ni sustituye el control de acceso basado en roles (RBAC) del espacio de trabajo. Use Roles y permisos del espacio de trabajo para el acceso a las funciones del espacio de trabajo y esta página para la política del entorno de ejecución local.

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

  • Requisitos: restricciones impuestas por los administradores 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 anular.
  • Valores predeterminados administrados heredados: valores iniciales de managed_config.toml que se aplican al iniciar un cliente compatible. Los usuarios pueden cambiar los ajustes durante una ejecución; el cliente vuelve a aplicar estos valores predeterminados la próxima vez que se inicia.

Configure los marketplaces de plugins y los valores predeterminados

Defina marketplaces locales o de Git y valores predeterminados de plugins en el archivo config.toml del sistema o en la sección config.toml de Configuración administrada. Estos ajustes son valores predeterminados, no una política obligatoria.

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.

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 de sandbox, perfiles de permisos, modo de búsqueda web, hooks administrados, qué servidores MCP 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 servidor MCP 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.

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 sandbox o perfil de permisos de solo lectura permitido por sus requisitos administrados. Los comandos permitidos por ese sandbox 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.

Ubicaciones y precedencia

Cada cliente local compatible combina los requisitos de menor a mayor precedencia:

  1. 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 administrados por la empresa suministrados 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) suministradas 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.

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.

Abre Configuración administrada para crear y asignar requisitos administrados en la nube. Por ejemplo, esta política limita las opciones de aprobación y sandbox, y solicita confirmación antes de que se ejecute un punto de entrada de shell compatible:

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" },
]

Confirme que todas las versiones de clientes administrados admitan las claves que seleccione y pruebe la política con un grupo pequeño antes de asignarla a toda la organización. Use la referencia de configuración para consultar el esquema actual y la superficie de administración para conocer 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

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.

Después de resolver 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 puede actualizar la caché para un inicio posterior; no sustituye los requisitos ya cargados en el proceso actual.

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.

Antes de ampliar el despliegue, prueba un flujo de trabajo aprobado y otro expresamente no permitido con un usuario representativo. Verifica la configuración efectiva en el cliente compatible en lugar de suponer que un rol o grupo del espacio de trabajo por sí solo aplica la restricción local.

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.

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.

Deshabilitar Appshots

Para deshabilitar Appshots para los usuarios administrados, establezca el requisito de nivel superior allow_appshots:

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.

Deshabilitar el control remoto de dispositivos

Para deshabilitar el control remoto de dispositivos para los usuarios administrados, establezca el requisito de nivel superior allow_remote_control:

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.

Controlar los perfiles de permisos 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.

Anular los requisitos del entorno aislado según el host

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.

También puede limitar el modo de búsqueda web:

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.

Configurar requisitos de acceso a la red

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 de navegador también comprueban las denegaciones de red administradas y las listas exclusivas de permitidos antes de acceder a un origen; esta es una comprobación de política independiente, no un enrutamiento del tráfico del navegador a través del proxy de comandos. No filtra la búsqueda web, las aplicaciones y los conectores, los servidores MCP, el tráfico de aplicaciones nativas, las solicitudes al servicio Codex ni el tráfico de Codex cloud. Usa los controles correspondientes a cada superficie:

  • Usa allowed_web_search_modes para restringir la búsqueda web.
  • Usa features.apps = false para deshabilitar las integraciones de aplicaciones y conectores, y features.plugins = false para deshabilitar los plugins cuando sea compatible.
  • Usa la lista administrada de elementos aprobados mcp_servers para restringir los servidores MCP.
  • Usa requisitos de funciones como browser_use, in_app_browser y computer_use para restringir las capacidades del navegador y de Computer Use.
  • Configura el acceso a la red de Codex cloud en los ajustes de su entorno de nube.

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

Controlar el navegador y Computer Use

Usa las tablas [browser_use] y [computer_use] de requirements.toml para restringir los clientes de escritorio compatibles. Valida la política en las versiones de los clientes y los sistemas operativos de tu implementación. Una regla de permiso configurada no instala un plugin, concede permisos del sistema operativo ni aprueba una acción que aún requiere revisión.

Para el acceso mediante navegador, configura una política de origen. Un origen incluye el esquema, el host y un puerto opcional, como https://example.com o https://*.example.com:8443. No incluyas una ruta, consulta ni fragmento. A diferencia de las reglas de dominio de la red de comandos, las reglas de origen del navegador distinguen HTTP de HTTPS y tienen en cuenta el puerto.

Este ejemplo restringe el acceso del navegador a un sitio aprobado e impide las cargas y el acceso completo a Chrome DevTools Protocol (CDP) en ese sitio:

[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"

Las reglas de origen coincidentes se resuelven por campo. Una denegación coincidente prevalece; de lo contrario, la política de origen predeterminada proporciona los campos que las reglas coincidentes no especifican. La configuración local puede añadir restricciones, pero no puede flexibilizar una denegación administrada. Las denegaciones de red y las listas exclusivas de permitidos administradas siguen aplicándose.

Establece browser_use.disable_auto_review = true para desactivar la revisión automática de aprobaciones de las acciones del navegador, o establece auto_review = "deny" en una política de origen para restringirla en ese origen. Esto controla la gestión de las aprobaciones; no desactiva la supervisión de seguridad del modelo.

Para las aplicaciones nativas, establece una política de acceso predeterminada e identifica las aplicaciones permitidas. Por ejemplo, esta política de macOS permite Calculator e impide guardar las aprobaciones:

[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 mediante computer_use.windows.aumids o archivos ejecutables mediante computer_use.windows.exes. Las reglas de ejecutables requieren publisher_name, product_name y access; binary_name es opcional. Usa la identidad verificada de la aplicación en lugar de basarte únicamente en su nombre para mostrar.

Consulta la referencia de configuración para conocer todos los campos y las restricciones de Locked Use para dispositivos macOS administrados.

Fijar marcas de función

También puede fijar marcas de función para los usuarios que reciban un requirements.toml administrado:

[features]
personality = 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.

  • in_app_browser = false deshabilita el panel integrado del navegador.
  • in_app_updates = false deshabilita el actualizador propio de la aplicación de escritorio de ChatGPT al reiniciarla, donde sea compatible. No afecta a la implementación de paquetes externos ni amplía la compatibilidad con versiones anteriores de la aplicación. Para obtener instrucciones de configuración e implementación, consulte Gestionar actualizaciones de la aplicación.
  • browser_use = false deshabilita Computer Use en navegadores y la disponibilidad de Browser Agent.
  • browser_use_full_cdp_access = false deshabilita el acceso completo a CDP en el entorno de ejecución local, incluido el modo Browser Developer, e impide que la aplicación de escritorio de ChatGPT habilite el ajuste correspondiente.
  • browser_use_external = false deshabilita Browser Use externo.
  • computer_use = false deshabilita Computer Use, Record & Replay y los flujos relacionados de instalación o configuración.

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 de equipos bloqueados

Para impedir que los usuarios habiliten Locked Use en una Mac administrada, añade este requisito:

[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.

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

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.
"""

Aplicar requisitos de denegación de lectura

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.

Aplicar hooks administrados desde los requisitos

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.

Aplicar reglas de comandos desde los requisitos

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é servidores MCP 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 servidores MCP 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 servidores MCP.

Controlar la disponibilidad de plugins

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

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.

Valores predeterminados administrados (managed_config.toml)

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.

Si un valor predeterminado administrado, un perfil MDM de macOS o una configuración guardada fija gpt-5.5 para usuarios de Codex que han iniciado sesión con ChatGPT, sustitúyelo por gpt-5.6-sol antes del 14 de octubre de 2026. GPT-5.5 se retirará de ChatGPT, ChatGPT Work y Codex en todos los planes en esa fecha. La API de OpenAI no se verá afectada. Consulta la disponibilidad de modelos en el espacio de trabajo.

Si un valor predeterminado administrado, un perfil MDM de macOS o una configuración guardada fija gpt-5.4 o gpt-5.4-mini para usuarios que han iniciado sesión con ChatGPT, actualícelo antes del 31 de agosto de 2026. Sustituya gpt-5.4 por gpt-5.6-terra y gpt-5.4-mini por gpt-5.6-luna. OpenAI API y Codex autenticado con su propia API key no se ven afectados. Consulte la disponibilidad de modelos en el espacio de trabajo.

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

Precedencia y estratificación

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.

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 analiza 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 requisitos administrados en la nube descrito anteriormente. La misma tabla [features] del lado de los requisitos funciona en requirements_toml_base64; use también allí claves de función canónicas.

Flujo de trabajo 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.

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.