Configuración administrada

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 empresariales pueden controlar el comportamiento compatible de los clientes locales de dos maneras:

• Requisitos: restricciones impuestas por el administrador que los usuarios no pueden anular.
• Valores predeterminados administrados: valores iniciales que se aplican cuando se inicia un cliente compatible. Los usuarios aún pueden cambiar los ajustes durante una ejecución; el cliente vuelve a aplicar los valores predeterminados administrados la próxima vez que se inicia.

Requisitos impuestos por el administrador (requirements.toml)

Los requisitos limitan los ajustes sensibles para la seguridad (política de aprobación, revisor de aprobaciones, política de revisión automática, modo de entorno aislado, perfiles de permisos, modo de búsqueda web, hooks administrados, qué servidores MCP pueden habilitar los usuarios y qué fuentes de marketplaces de plugins configuradas por el usuario pueden agregar, usar para realizar instalaciones o actualizar). Al resolver la configuración (por ejemplo, desde config.toml, archivos de perfil o anulaciones de configuración de CLI), si un valor entra en conflicto con una regla impuesta, el cliente local usa un valor compatible y notifica al usuario. Si configura una lista de permitidos mcp_servers, el cliente habilita un servidor MCP solo cuando su nombre y 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.

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 impuestos por el administrador asociados con el espacio de trabajo. Este es un canal de entrega para políticas compatibles con requirements.toml. No concede acceso al espacio de trabajo ni sustituye el RBAC del espacio de trabajo.

Abra Configuración administrada para crear y asignar requisitos administrados en la nube. Por ejemplo, esta política exige que los clientes compatibles usen la residencia de datos de Estados Unidos, limita las opciones de aprobación y entorno aislado, y solicita confirmación antes de que se ejecute un punto de entrada de shell compatible:

enforce_residency = "us"
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.

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

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

Use [experimental_network] en requirements.toml cuando los administradores deban definir centralmente los requisitos de acceso a la red. Estos requisitos son independientes del conmutador features.network_proxy del usuario: pueden configurar las redes 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 red desactivada.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

Use experimental_network.managed_allowed_domains_only = true solo cuando también defina reglas de permiso allowed_domains propiedad del administrador y quiera que esa lista de permitidos sea exclusiva. Si tiene el valor true sin reglas de permiso administradas, las reglas de permiso de dominios agregadas por el usuario dejan de ser efectivas.

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.

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 Computer Use funcione después de que un Mac administrado se bloquee, agregue este requisito:

[computer_use]
allow_locked_computer_use = false

Este requisito no habilita Computer Use. Solo impide su uso con el equipo bloqueado en macOS. Si lo omite, los requisitos no limitan el uso con el equipo bloqueado; la disponibilidad normal del producto y el ajuste local del usuario siguen siendo aplicables.

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 operaciones sobre fuentes de marketplaces configuradas por el usuario, establezca restrict_to_allowed_sources = true y defina una o más reglas de origen:

[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 no coincidentes de adición de marketplaces, instalación de plugins y actualización de marketplaces de Git configurados para fuentes configuradas por el usuario. Los marketplaces de OpenAI administrados por Codex siguen disponibles cuando coinciden su fuente y su nombre reservado. Los requisitos no filtran en tiempo de ejecución los marketplaces de usuario ya configurados ni sus plugins.

Estas restricciones de fuentes solo se aplican donde un cliente local admite operaciones de marketplaces de plugins: ChatGPT Work y Codex en la aplicación de escritorio, y Codex CLI. No agregan plugins a Chat, la extensión de IDE ni la aplicación móvil.

Valores predeterminados administrados (managed_config.toml)

Los valores predeterminados administrados se combinan sobre el archivo config.toml local de un usuario y tienen precedencia sobre cualquier anulación --config de CLI, por lo que establecen los valores iniciales cuando se inicia un cliente local compatible. Los usuarios aún pueden cambiar esos ajustes durante una ejecución; el cliente vuelve a aplicar los valores predeterminados administrados la próxima vez que se inicia.

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.

Los requisitos administrados en la nube afectan a la capa de requisitos (no a los valores predeterminados administrados). Consulte la sección anterior Requisitos impuestos por el administrador para conocer la precedencia.

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.