Configuración administrada

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

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

• Requisitos: restricciones impuestas por los administradores que los usuarios no pueden anular.
• Valores predeterminados de configuración: ajustes de config.toml del sistema o administrados en la nube que los usuarios pueden modificar.
• 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.

Configurar marketplaces de complementos y valores predeterminados

Define marketplaces locales o de Git y valores predeterminados de complementos 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.

Consulta Referencia de configuración para conocer las claves de configuración, Precedencia de la configuración para conocer las reglas de sobrescritura y configuración de complementos del repositorio para la configuración a nivel de proyecto. La importación y sincronización con GitHub del espacio de trabajo se gestiona por separado.

Requisitos impuestos por los administradores (requirements.toml)

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

Los requisitos también pueden restringir los indicadores de funciones mediante la tabla [features] de requirements.toml. Ten 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.

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

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

Migrar desde la política de aprobación retirada untrusted

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

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

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

Ubicaciones y precedencia

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

1. El archivo requirements.toml del sistema (/etc/codex/requirements.toml en sistemas Unix, incluidos Linux y macOS, o %ProgramData%\OpenAI\Codex\requirements.toml en Windows).
2. Requisitos administrados por la empresa que se distribuyen 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 de mayor precedencia sobrescriben los valores escalares y de lista ordinarios de las capas inferiores. Las tablas se combinan por clave, mientras que los requisitos como reglas, hooks y restricciones del sistema de archivos se combinan de una manera específica para cada campo. Consulta la referencia de requirements.toml para conocer el esquema actual, en lugar de suponer que todos los campos se combinan de la misma manera.

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

Requisitos administrados en la nube

Cuando un usuario inicia sesión con ChatGPT en un plan compatible, los clientes locales compatibles pueden recibir requisitos impuestos por los administradores y asociados con el espacio de trabajo. Este es un canal de distribución de políticas compatibles con requirements.toml. No otorga acceso al espacio de trabajo ni reemplaza 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 aprobació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" },
]

Confirma que todas las versiones de los clientes administrados admitan las claves que selecciones y prueba la política con un grupo pequeño antes de asignarla a toda la organización. Consulta la referencia de configuración para conocer el esquema actual y la interfaz de administración para conocer el comportamiento actual de las asignaciones.

El servicio selecciona las capas de requisitos administrados por la empresa que se aplican a la identidad que inició sesión. El cliente local evalúa esas capas junto con las otras fuentes de requisitos descritas en Ubicaciones y precedencia. Usa la interfaz de administración actual para la creación y asignación en el espacio de trabajo. No dependas de una copia del algoritmo de coincidencia de grupos; el servicio de administración controla ese comportamiento y puede cambiarlo independientemente del formato de los requisitos locales.

Para conocer las claves admitidas y ver ejemplos, consulta 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 primero busca una entrada de caché válida que coincida con la identidad. Si no hay ninguna entrada válida disponible, el cliente obtiene el paquete correspondiente con reintentos y, si lo logra, escribe una entrada de caché firmada. Si la solicitud falla o se 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 iniciar sin avisar que falta la capa de requisitos administrados en la nube.

Una vez resuelta la caché, el cliente combina los requisitos de la nube con las otras capas de requisitos descritas anteriormente. Una actualización en segundo plano puede actualizar la caché para un inicio posterior; no reemplaza los requisitos que ya se cargaron en el proceso actual.

Verificar la experiencia de administradores y empleados

Asigna a una persona como 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 los perfiles de permisos.

Antes de ampliar la implementación, prueba con un usuario representativo un flujo de trabajo aprobado y otro prohibido de forma intencional. Verifica los ajustes efectivos en el cliente compatible en lugar de suponer que un rol o grupo del espacio de trabajo, por sí solo, hace cumplir la restricción local.

Administrar la autenticación localmente

Establece allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store y chatgpt_base_url en el archivo requirements.toml del sistema local o en los requisitos 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 que se carguen 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, usa:

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

allowed_login_methods acepta chatgpt, api o ambos. Si 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 ajustes forced_login_method y forced_chatgpt_workspace_id configurados por el usuario deben cumplir los requisitos. Cuando un usuario selecciona un espacio de trabajo, este también debe figurar en la lista administrada de espacios de trabajo permitidos. Si 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 no hay ningún método de inicio de sesión disponible, Codex no permite el inicio.

Consulta 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 admitido.

Deshabilitar las capturas de la aplicación

Para deshabilitar las capturas de la aplicación para los usuarios administrados, establece el requisito allow_appshots de nivel superior:

allow_appshots = false

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

Deshabilitar el control remoto del dispositivo

Para deshabilitar el control remoto del dispositivo para los usuarios administrados, establece el requisito allow_remote_control de nivel superior:

allow_remote_control = false

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

Controlar los perfiles de permisos disponibles

Usa allowed_permission_profiles para controlar cuáles de los perfiles de permisos integrados y personalizados pueden seleccionar los usuarios. Este es el equivalente de allowed_sandbox_modes para los perfiles de permisos; usa la lista de elementos permitidos que corresponda a la manera en que tus usuarios seleccionan los permisos.

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

Usa los siguientes ejemplos de perfiles de permisos solo después de que todos los clientes administrados ejecuten una versión compatible. No implementes perfiles personalizados administrados hasta que se complete la actualización de todos los equipos.

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

Permitir los perfiles estándar

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

default_permissions = ":workspace"

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

Agregar un valor predeterminado administrado de mínimo privilegio

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

No implementes 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 selecciona el perfil.

Por ejemplo:

default_permissions = "acme_review_only"

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

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

Permitir solo perfiles definidos por la empresa

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

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

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

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

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

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

Desactivar un perfil permitido por otra fuente

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

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

Sobrescribir los requisitos del sandbox según el host

Usa [[remote_sandbox_config]] cuando una política administrada deba aplicar distintos requisitos del sandbox en distintos hosts. Por ejemplo, puedes mantener una configuración predeterminada más estricta para las laptops y permitir la escritura en el espacio de trabajo en las máquinas de desarrollo o los ejecutores de CI que coincidan. Actualmente, las entradas específicas de cada host solo sobrescriben allowed_sandbox_modes:

allowed_sandbox_modes = ["read-only"]

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

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

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

También puedes restringir 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 con danger-full-access.

Configurar los requisitos de acceso a la red

Usa [experimental_network] en requirements.toml cuando los administradores deban definir los requisitos de acceso a la red de forma centralizada. Estos requisitos son independientes de la opción features.network_proxy del usuario: pueden configurar la conectividad de red del sandbox sin esa bandera de función, pero no otorgan a los comandos acceso a la red cuando el sandbox activo mantiene la conectividad 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" bajo el control del administrador en [experimental_network.domains] y quieras que esas reglas sean exclusivas. Si el valor es true y no hay reglas administradas de autorización, las reglas de autorización de dominios que agreguen los usuarios dejan de tener efecto. No combines el mapa canónico domains con las listas heredadas allowed_domains o denied_domains.

*.example.com solo coincide con subdominios. **.example.com coincide con el dominio raíz y sus subdominios. Una regla de denegación que coincida tiene prioridad sobre una regla de autorización.

La sintaxis de dominios, las reglas para destinos locales o privados, la prioridad de la denegación sobre la autorización y las limitaciones de reenlace de DNS son las mismas que las del comportamiento de red del sandbox descrito en Aprobaciones del agente y seguridad.

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

• Usa allowed_web_search_modes para restringir la búsqueda web.
• Usa features.apps = false para desactivar las integraciones de apps y conectores, y features.plugins = false para desactivar los complementos donde se admita.
• Usa la lista administrada de servidores 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 uso de la computadora.
• Configura el acceso a la red de Codex Cloud en la configuración de su entorno en la nube.

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

Controlar el navegador y Uso de la computadora

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. Configurar una regla de autorización no instala un complemento, no otorga un permiso del sistema operativo ni aprueba una acción que todavía requiera revisión.

Para el acceso del navegador, configura una política de orígenes. Un origen incluye el esquema, el host y, opcionalmente, el puerto, como https://example.com o https://*.example.com:8443. No incluyas una ruta, una consulta ni un fragmento. A diferencia de las reglas de dominio para el acceso a la red de los comandos, las reglas de origen del navegador distinguen entre HTTP y HTTPS y comprueban la coincidencia del puerto.

Este ejemplo restringe el acceso del navegador a un sitio aprobado e impide las cargas de archivos 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 que coinciden se resuelven campo por campo. Una denegación coincidente tiene prioridad; de lo contrario, la política de orígenes predeterminada proporciona los campos que las reglas coincidentes no especifican. La configuración local puede agregar restricciones, pero no puede flexibilizar una denegación administrada. Siguen aplicándose las denegaciones de red y las listas administradas que permiten únicamente determinados destinos de red.

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

Para las apps nativas, establece una política de acceso predeterminada e identifica las apps permitidas. Por ejemplo, esta política de macOS permite Calculadora e impide guardar 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 apps empaquetadas con computer_use.windows.aumids o ejecutables con computer_use.windows.exes. Las reglas para ejecutables requieren publisher_name, product_name y access; binary_name es opcional. Usa la identidad verificada de la app en lugar de basarte solo en su nombre para mostrar.

Consulta la referencia de configuración para ver todos los campos y las restricciones de uso con el equipo bloqueado para dispositivos macOS administrados.

Fijar banderas de funciones

También puedes fijar banderas de funciones para los usuarios que reciben un archivo 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

Usa las claves canónicas de funciones 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 respetar estos valores fijos y rechaza las escrituras incompatibles en config.toml o en la configuración de funciones del archivo de perfil.

• 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 el despliegue externo de paquetes ni extiende el soporte para versiones anteriores de la app. Para obtener orientación sobre la configuración y la implementación gradual, consulta Administrar las actualizaciones de la aplicación.
• browser_use = false desactiva Uso de la computadora en los navegadores y la disponibilidad del agente del navegador.
• 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 la opción correspondiente.
• browser_use_external = false desactiva el Navegador externo.
• computer_use = false desactiva Uso de la computadora, Grabar y reproducir y los flujos relacionados de instalación o configuración.

Si omites estas claves, la política permite las funciones, sujetas a la disponibilidad habitual según el cliente, la plataforma y la implementación gradual.

Restringir el uso de la computadora con el equipo bloqueado

Para impedir que los usuarios habiliten Uso con el equipo bloqueado en una Mac administrada, agrega este requisito:

[computer_use]
allow_locked_computer_use = false

Este requisito elimina los controles para habilitar Uso con el equipo bloqueado. No desactiva Uso con el equipo bloqueado si ya está habilitado. Si lo omites, la disponibilidad habitual del producto y la configuración local del usuario siguen aplicándose.

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

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

Establece guardian_policy_config para reemplazar la sección específica del inquilino 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. La configuración administrada de guardian_policy_config tiene precedencia sobre la configuración local de [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 la lectura de rutas exactas o patrones glob con [permissions.filesystem]. Los usuarios no pueden debilitar estos requisitos con la configuración local.

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

Cuando hay requisitos de denegación de lectura, el entorno de ejecución local rechaza los permisos de acceso completo y mantiene la ejecución local en un sandbox de solo lectura o de espacio de trabajo para poder aplicarlos. En Windows nativo, el requisito administrado deny_read se aplica a las herramientas de acceso directo a archivos; las lecturas de los subprocesos de shell no usan esta regla del sandbox.

Aplicar hooks administrados desde los requisitos

Los administradores también pueden definir hooks de ciclo de vida administrados directamente en requirements.toml. Usa [hooks] para la configuración de los hooks y haz que managed_dir apunte al directorio donde tu MDM o tus herramientas de administración de dispositivos instalan los scripts referenciados.

Para aplicar los hooks administrados incluso a los usuarios que hayan desactivado los hooks localmente, fija [features].hooks = true junto con [hooks]. Para omitir los hooks del usuario, del proyecto, de la sesión y de los complementos sin dejar de permitir los hooks administrados, establece 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.
• Distribuye esos scripts con tu MDM o tu solución de administració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 los hooks provenientes del usuario, del proyecto, de la sesión y de los complementos, pero sigue cargando los hooks de requirements.toml y de otras capas de configuración administradas.

Aplicar reglas de comandos desde los requisitos

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

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, agrega una lista de servidores aprobados en mcp_servers. Para los servidores stdio, define la coincidencia con command; para los servidores HTTP con transmisión, defínela con url:

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

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

Cuando identity.command es una cadena, solo se compara con el valor configurado de command. No se inspeccionan args, cwd, env ni env_vars.

Para restringir una invocación stdio completa, define la coincidencia del ejecutable y de 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 su orden deben coincidir. Las reglas de argumentos y URL admiten coincidencias con exact y prefix, así como coincidencias con regex que abarcan el valor completo. Las reglas estructuradas de comandos tampoco inspeccionan cwd, env ni env_vars. Los servidores MCP incluidos en complementos usan las mismas estructuras 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 complementos

Para desactivar los complementos en los clientes locales compatibles, establece 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 clave de API. Consulta la referencia de features.plugins para conocer la configuración compatible.

Restringir las fuentes de los marketplaces de complementos

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

[marketplaces]
restrict_to_allowed_sources = true

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

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

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

Las reglas de Git comparan la URL normalizada del repositorio y, cuando está presente, el valor exacto de ref. Los patrones de host son expresiones regulares que se comparan con el host de Git en minúsculas; usa ^ y $ para comparar el host completo. Las reglas locales requieren una ruta absoluta y normalizada. Consulta 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 complementos y actualización de marketplaces de Git configurados que no coincidan con las reglas. También filtran los marketplaces configurados y sus complementos durante la ejecución.

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

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

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

Estas restricciones de fuentes solo se aplican cuando un cliente local admite operaciones con marketplaces de complementos: ChatGPT y Codex en la App de escritorio, y Codex CLI. No controlan el uso de complementos en ChatGPT en la web ni en dispositivos móviles, y tampoco agregan complementos a la extensión para 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, tienen prioridad sobre el archivo config.toml local del usuario y cualquier valor especificado con --config en la CLI. 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 los usuarios de Codex que iniciaron sesión con ChatGPT, reemplázalo por gpt-5.6-sol antes del 14 de octubre de 2026. En esa fecha, GPT-5.5 se retira de ChatGPT, ChatGPT Work y Codex en todos los planes. La API de OpenAI no se ve 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 los usuarios que iniciaron sesión con ChatGPT, actualízalo antes del 31 de agosto de 2026. Reemplaza gpt-5.4 por gpt-5.6-terra y gpt-5.4-mini por gpt-5.6-luna. La API de OpenAI y Codex con autenticación mediante tu propia clave de API no se ven afectados. Consulta la disponibilidad de modelos en el espacio de trabajo.

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

Precedencia y organización por capas

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

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

Los valores especificados con --config key=value en la CLI se aplican a la configuración base, pero las capas administradas tienen prioridad sobre ellos. Esto significa que cada ejecución comienza con los valores predeterminados administrados, incluso si proporcionas flags locales.

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

Ubicaciones

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

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

Preferencias administradas de macOS (MDM)

En macOS, los administradores pueden distribuir 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 ú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] de requisitos funciona en requirements_toml_base64; usa también allí las claves canónicas de las funciones.

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 puedes distribuir ajustes con herramientas como Jamf Pro, Fleet o Kandji. Una implementación sencilla sigue estos pasos:

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

Evita incluir secretos o valores dinámicos que cambien con frecuencia en la carga útil. Trata el TOML administrado como cualquier otro ajuste de MDM sujeto a 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

• Prioriza workspace-write con aprobaciones para la mayoría de los usuarios; reserva el acceso completo para contenedores controlados.
• Mantén network_access = false a menos que tu revisión de seguridad permita un recolector o los dominios necesarios para tus flujos de trabajo.
• Usa la configuración administrada para fijar los ajustes de OTel (exportador, entorno), pero mantén log_user_prompt = false a menos que tu política permita explícitamente almacenar el contenido de los prompts.
• Audita periódicamente las diferencias entre el archivo config.toml local y la política administrada para detectar desviaciones; las capas administradas deben tener prioridad sobre los flags y archivos locales.