Управляемая конфигурация

Управляемая конфигурация определяет поддерживаемое поведение локальной среды выполнения для охватываемых возможностей в настольном приложении ChatGPT, Codex CLI и расширении IDE. Поддерживаемые требования могут различаться в зависимости от клиента и версии. Управляемая конфигурация не предоставляет доступ к рабочему пространству ChatGPT, не назначает лицензии и не заменяет управление доступом на основе ролей рабочего пространства (RBAC). Для доступа к функциям рабочего пространства используйте раздел Роли и разрешения рабочего пространства, а эту страницу — для локальной политики среды выполнения.

Администраторы Enterprise могут управлять поддерживаемым поведением локальных клиентов двумя способами:

• Требования: устанавливаемые администратором ограничения, которые пользователи не могут переопределить.
• Управляемые значения по умолчанию: начальные значения, применяемые при запуске поддерживаемого клиента. Пользователи по-прежнему могут изменять настройки во время выполнения; клиент повторно применяет управляемые значения по умолчанию при следующем запуске.

Требования, устанавливаемые администратором (requirements.toml)

Требования ограничивают настройки, влияющие на безопасность (политику одобрения, проверяющего одобрения, политику автоматической проверки, режим песочницы, профили разрешений, режим веб-поиска, управляемые перехватчики, серверы MCP, которые могут включать пользователи, а также источники торговых площадок плагинов, настроенные пользователями, которые они могут добавлять, использовать для установки или обновлять). Если при разрешении конфигурации (например, из config.toml, файлов профилей или переопределений конфигурации CLI) значение конфликтует с обязательным правилом, локальный клиент возвращается к совместимому значению и уведомляет пользователя. Если настроен список разрешений mcp_servers, клиент включает сервер MCP, только когда его имя и идентификатор соответствуют одобренной записи; в противном случае клиент отключает его.

Требования также могут ограничивать флаги функций через таблицу [features] в requirements.toml. Учтите, что функции не всегда влияют на безопасность, но при необходимости организации могут закрепить их значения. Пропущенные ключи остаются без ограничений.

Для Codex 0.138.0 и более поздних версий предпочтительно использовать профили разрешений с allowed_permission_profiles и управляемым default_permissions. Используйте allowed_sandbox_modes только для устаревших развёртываний, в которых по-прежнему настраивается sandbox_mode.

Точный список ключей см. в разделе requirements.toml справочника по конфигурации.

Расположение и приоритет

Каждый поддерживаемый локальный клиент объединяет требования в следующем порядке, от меньшего приоритета к большему:

1. Системный requirements.toml (/etc/codex/requirements.toml в системах Unix, включая Linux и macOS, или %ProgramData%\OpenAI\Codex\requirements.toml в Windows).
2. Управляемые организацией требования, доставленные в облачном пакете конфигурации.
3. Устаревшие поля managed_config.toml, которые локальный клиент интерпретирует как требования.
4. Управляемые настройки macOS (MDM), доставленные через com.openai.codex:requirements_toml_base64.

Слои с более высоким приоритетом переопределяют обычные скалярные значения и списки из слоёв с меньшим приоритетом. Таблицы объединяются по ключам, а для таких требований, как правила, перехватчики и ограничения файловой системы, действуют особые правила объединения для отдельных полей. Используйте справочник requirements.toml с актуальной схемой и не предполагайте, что все поля объединяются одинаково.

Для обратной совместимости поддерживаемые локальные клиенты интерпретируют устаревшие поля approval_policy, approvals_reviewer и sandbox_mode как требования. При этом преобразовании при необходимости добавляются варианты совместимости; для явных списков разрешений используйте requirements.toml.

Требования, управляемые из облака

Когда пользователь входит через ChatGPT в рамках поддерживаемого плана, поддерживаемые локальные клиенты могут получать устанавливаемые администратором требования, связанные с рабочим пространством. Это канал доставки политики, совместимой с requirements.toml. Он не предоставляет доступ к рабочему пространству и не заменяет RBAC рабочего пространства.

Откройте Управляемую конфигурацию, чтобы создать и назначить управляемые из облака требования. Например, следующая политика требует от поддерживаемых клиентов использовать хранение данных в США, ограничивает варианты одобрения и песочницы и запрашивает подтверждение перед запуском поддерживаемой точки входа оболочки:

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

Убедитесь, что каждая версия управляемого клиента поддерживает выбранные ключи, и протестируйте политику на небольшой группе перед назначением всей организации. Актуальную схему см. в справочнике по конфигурации, а актуальное поведение назначения — в интерфейсе администрирования.

Сервис выбирает слои управляемых организацией требований, применимые к вошедшему пользователю. Локальный клиент оценивает эти слои вместе с другими источниками требований, описанными в разделе Расположение и приоритет. Используйте актуальный интерфейс администрирования для создания и назначения на стороне рабочего пространства. Не полагайтесь на скопированный алгоритм сопоставления групп: за это поведение отвечает служба администрирования, и оно может изменяться независимо от локального формата требований.

Поддерживаемые ключи и примеры см. в разделах Пример requirements.toml и справочник requirements.toml.

Как локальные клиенты применяют управляемые из облака требования

Когда пользователь запускает поддерживаемый локальный клиент и входит через ChatGPT в рамках поддерживаемого плана, клиент сначала ищет действительную запись кэша, соответствующую идентификатору. Если действительная запись недоступна, клиент с повторными попытками получает применимый пакет и после успешного выполнения записывает подписанную запись кэша. Если запрос завершается ошибкой или превышает время ожидания и действительный кэш недоступен, загрузка облачного пакета конфигурации возвращает ошибку, а не запускается без предупреждения и без слоя управляемых из облака требований.

После разрешения кэша клиент объединяет облачные требования с остальными слоями требований, описанными выше. Фоновое обновление может обновить кэш для последующего запуска; оно не заменяет требования, уже загруженные в текущий процесс.

Пример requirements.toml

Этот пример блокирует --ask-for-approval never и --sandbox danger-full-access (включая --yolo):

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

Отключение Appshots

Чтобы отключить Appshots для управляемых пользователей, задайте требование верхнего уровня allow_appshots:

allow_appshots = false

Там, где доступны Appshots, allow_appshots = false отключает их. Если ключ не указан, требования не ограничивают Appshots и применяются обычные проверки доступности продукта. Клиенты сервера приложения, которые считывают действующие требования через configRequirements/read, получают то же ограничение, что и allowAppshots; пропущенное значение allowAppshots или значение null не отключает Appshots.

Отключение удалённого управления устройством

Чтобы отключить удалённое управление устройством для управляемых пользователей, задайте требование верхнего уровня allow_remote_control:

allow_remote_control = false

Там, где поддерживается удалённое управление устройством, allow_remote_control = false отключает его. Если ключ не указан, требования не ограничивают удалённое управление устройством и применяются обычные проверки доступности продукта. Это требование не отключает удалённые подключения SSH.

Управление доступными профилями разрешений

Используйте allowed_permission_profiles, чтобы управлять тем, какие встроенные и пользовательские профили разрешений могут выбирать пользователи. Это аналог allowed_sandbox_modes для профилей разрешений; используйте список разрешений, соответствующий способу выбора разрешений вашими пользователями.

Для списков разрешений профилей требуется Codex 0.138.0 или более поздней версии. Codex 0.137.0 и более ранние версии игнорируют allowed_permission_profiles и управляемый default_permissions.

Используйте приведённые ниже примеры профилей разрешений только после того, как все управляемые клиенты будут работать на поддерживаемой версии. Не развёртывайте управляемые пользовательские профили до завершения обновления всего парка клиентов.

При наличии таблицы она представляет полный список разрешённых профилей. Она разрешает профили со значением true и запрещает пропущенные профили или профили со значением false, включая встроенные профили, добавленные в будущих версиях Codex.

Разрешение стандартных профилей

Эта политика разрешает доступ только для чтения и доступ к рабочей области, но не полный доступ:

default_permissions = ":workspace"

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

Добавление управляемого значения по умолчанию с минимальными привилегиями

Администраторы могут определить пользовательский профиль в том же источнике требований. Используйте специфичные для организации имена профилей, которые не будут конфликтовать с именами в загруженной конфигурации пользователей. Пользовательские имена не могут начинаться с : или использовать зарезервированное имя filesystem.

Не развёртывайте управляемые пользовательские профили на клиентах с Codex 0.137.0 или более ранними версиями. Эти клиенты распознают таблицу профилей, но не управляемое значение по умолчанию, которое выбирает профиль.

Например:

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"

Разрешение только профилей, определённых организацией

Не указывайте встроенные профили, если пользователи должны выбирать только профили, определённые администратором:

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"

Пользовательский профиль может расширять :workspace, даже если пользователи не могут напрямую выбрать встроенный профиль :workspace.

Отключение профиля, разрешённого другим источником

Списки разрешений объединяются по имени профиля. Поскольку облачные требования имеют более высокий приоритет, чем системные требования, в облачных требованиях можно использовать false, чтобы отключить профиль, разрешённый системным файлом.

Облачные требования:

default_permissions = ":read-only"

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

Системные требования:

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

Явно задайте для default_permissions разрешённый профиль. Если значение пропущено, локальная среда выполнения использует по умолчанию :workspace, только когда явно разрешены и :workspace, и :read-only. Если allowed_permission_profiles отсутствует, управляемые требования не ограничивают имена профилей, которые могут выбирать пользователи. Каждая запись должна указывать встроенный профиль или пользовательский профиль, определённый в загруженной конфигурации либо источнике требований. Определяйте пользовательские профили в управляемых требованиях, чтобы централизованно управлять их поведением.

Переопределение требований песочницы в зависимости от узла

Используйте [[remote_sandbox_config]], когда одна управляемая политика должна применять разные требования песочницы на разных узлах. Например, можно сохранить более строгие значения по умолчанию для ноутбуков, разрешив при этом запись в рабочую область на подходящих компьютерах разработки или исполнителях CI. Записи для конкретных узлов сейчас переопределяют только 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"]

Локальная среда выполнения сравнивает каждую запись hostname_patterns с именем узла, определённым по мере возможности. При наличии предпочтение отдаётся полному доменному имени, иначе используется локальное имя узла. Сопоставление выполняется без учёта регистра; * соответствует любой последовательности символов, а ? — одному символу.

В пределах одного источника требований используется первая совпавшая запись [[remote_sandbox_config]]. Если совпадений нет, локальная среда выполнения сохраняет значение верхнего уровня allowed_sandbox_modes. Сопоставление имени узла служит только для выбора политики; не рассматривайте его как аутентифицированное подтверждение устройства.

Также можно ограничить режим веб-поиска:

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

allowed_web_search_modes = [] разрешает только "disabled". Например, allowed_web_search_modes = ["cached"] запрещает веб-поиск в реальном времени даже в сеансах danger-full-access.

Настройка требований к сетевому доступу

Используйте [experimental_network] в requirements.toml, когда администраторам необходимо централизованно определять требования к сетевому доступу. Эти требования не зависят от пользовательского переключателя features.network_proxy: они могут настраивать сеть песочницы без этого флага функции, но не предоставляют командам сетевой доступ, если активная песочница оставляет сеть отключённой.

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

Используйте experimental_network.managed_allowed_domains_only = true, только если вы также определили принадлежащие администратору allowed_domains и хотите сделать этот список разрешений исключительным. Если задано true без управляемых разрешающих правил, добавленные пользователями правила разрешения доменов перестают действовать.

Синтаксис доменов, правила для локальных и частных адресатов, приоритет запрета над разрешением и ограничения перепривязки DNS совпадают с поведением сети песочницы, описанным в разделе Одобрения агента и безопасность.

Закрепление флагов функций

Также можно закреплять флаги функций для пользователей, получающих управляемый requirements.toml:

[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

Для функций среды выполнения используйте канонические ключи функций из таблицы [features] файла config.toml. Локальная среда выполнения нормализует распознанные функции в соответствии с этими закреплёнными значениями и отклоняет конфликтующие записи в config.toml или настройки функций в файлах профилей.

• in_app_browser = false отключает встроенную панель браузера.
• in_app_updates = false отключает собственное средство обновления настольного приложения ChatGPT при перезапуске там, где это поддерживается. Это не влияет на развёртывание внешних пакетов и не продлевает поддержку старых версий приложения. Инструкции по настройке и развёртыванию см. в разделе Управление обновлениями приложения.
• browser_use = false отключает Computer Use в браузерах и доступность Browser Agent.
• browser_use_full_cdp_access = false отключает полный доступ CDP в локальной среде выполнения, включая режим Browser Developer, и не позволяет настольному приложению ChatGPT включить соответствующую настройку.
• browser_use_external = false отключает внешний Browser Use.
• computer_use = false отключает Computer Use, Record & Replay и связанные процессы установки или настройки.

Если эти ключи не указаны, политика разрешает функции с учётом обычной доступности для клиента, платформы и этапа развёртывания.

Ограничение использования заблокированного компьютера

Чтобы запретить Computer Use работать после блокировки управляемого Mac, добавьте следующее требование:

[computer_use]
allow_locked_computer_use = false

Это требование не включает Computer Use. Оно лишь запрещает использование на заблокированном устройстве macOS. Если его не указать, требования не ограничивают такое использование; по-прежнему применяются обычная доступность продукта и локальная настройка пользователя.

Настройка политики автоматической проверки

Используйте allowed_approvals_reviewers, чтобы потребовать или разрешить автоматическую проверку. Задайте ["auto_review"], чтобы сделать автоматическую проверку обязательной, или включите "user", если пользователи могут выбирать ручное одобрение.

Задайте guardian_policy_config, чтобы заменить зависящий от арендатора раздел политики автоматической проверки. Локальная среда выполнения по-прежнему использует встроенный шаблон проверяющего и контракт выходных данных. Управляемый guardian_policy_config имеет приоритет над локальным [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.
"""

Принудительное применение запретов на чтение

Администраторы могут запрещать чтение точных путей или путей по шаблонам glob с помощью [permissions.filesystem]. Пользователи не могут ослабить эти требования локальной конфигурацией.

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

При наличии запретов на чтение локальная среда выполнения отклоняет разрешения полного доступа и сохраняет локальное выполнение в песочнице только для чтения или рабочей области, чтобы обеспечить их соблюдение. В нативной Windows управляемый deny_read применяется к прямым файловым инструментам; чтение в дочерних процессах оболочки не использует это правило песочницы.

Принудительное применение управляемых перехватчиков из требований

Администраторы также могут определять управляемые перехватчики жизненного цикла непосредственно в requirements.toml. Используйте [hooks] для самой конфигурации перехватчика, а в managed_dir укажите каталог, куда средства MDM или управления конечными точками устанавливают указанные скрипты.

Чтобы принудительно применять управляемые перехватчики даже для пользователей, отключивших их локально, закрепите [features].hooks = true вместе с [hooks]. Чтобы пропустить пользовательские, проектные, сеансовые и плагинные перехватчики, сохранив при этом управляемые, задайте 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"

Примечания:

• Локальная среда выполнения применяет конфигурацию перехватчиков из requirements.toml, но не распространяет скрипты из managed_dir.
• Доставляйте эти скрипты с помощью решения MDM или управления устройствами.
• Команды управляемых перехватчиков должны ссылаться на абсолютные пути скриптов в настроенном управляемом каталоге.
• allow_managed_hooks_only = true пропускает перехватчики из пользовательских, проектных, сеансовых и плагинных источников, но по-прежнему загружает их из requirements.toml и других слоёв управляемой конфигурации.

Принудительное применение правил команд из требований

Администраторы также могут применять ограничивающие правила команд из requirements.toml с помощью таблицы [rules]. Эти правила объединяются с обычными файлами .rules, и приоритет по-прежнему имеет наиболее строгое решение.

В отличие от .rules, правила требований должны содержать decision, причём это решение должно быть "prompt" или "forbidden" (но не "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." },
]

Чтобы ограничить серверы MCP, которые может включить локальный клиент, добавьте список одобренных mcp_servers. Для серверов stdio выполняйте сопоставление по command, а для серверов потокового HTTP — по url:

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

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

Строковая форма identity.command сопоставляется только с настроенным command. Она не проверяет args, cwd, env или env_vars.

Чтобы ограничить полный вызов stdio, сопоставьте исполняемый файл и каждый позиционный аргумент:

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

Исполняемый файл, количество и порядок аргументов должны совпадать. Правила аргументов и URL поддерживают сопоставление exact, prefix и полного значения regex. Структурированные правила команд по-прежнему не проверяют cwd, env или env_vars. Серверы MCP, встроенные в плагины, используют те же формы идентификации в plugins.<plugin>.mcp_servers.<server>.

Если mcp_servers присутствует, но пуст, локальный клиент отключает все серверы MCP.

Управление доступностью плагинов

Чтобы отключить плагины в поддерживаемых локальных клиентах, задайте для features.plugins значение false в requirements.toml:

features.plugins = false

Эта настройка также применяется, когда пользователи входят в Codex с помощью API key. Поддерживаемую конфигурацию см. в справочнике по features.plugins.

Ограничение источников торговых площадок плагинов

Чтобы ограничить операции с настроенными пользователем источниками торговых площадок, задайте restrict_to_allowed_sources = true и определите одно или несколько правил источников:

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

Правила Git сопоставляются с нормализованным URL репозитория и, при наличии, точным ref. Шаблоны узлов — это регулярные выражения, сопоставляемые с именем узла Git в нижнем регистре; используйте ^ и $ для сопоставления всего имени узла. Для локальных правил требуется абсолютный, нормализованный путь. Полную схему и правила объединения см. в справочнике по requirements.toml.

Эти требования отклоняют операции добавления несопоставленных торговых площадок, установки плагинов и обновления настроенных торговых площадок Git для источников, настроенных пользователями. Управляемые Codex торговые площадки OpenAI остаются доступными, когда совпадают их источник и зарезервированное имя. Требования не фильтруют уже настроенные пользовательские торговые площадки или их плагины во время выполнения.

Эти ограничения источников применяются только там, где локальный клиент поддерживает операции с торговыми площадками плагинов: в ChatGPT Work и Codex в настольном приложении, а также Codex CLI. Они не добавляют плагины в Chat, расширение IDE или мобильное приложение.

Управляемые значения по умолчанию (managed_config.toml)

Управляемые значения по умолчанию объединяются поверх локального пользовательского config.toml и имеют приоритет над любыми переопределениями CLI --config, задавая начальные значения при запуске поддерживаемого локального клиента. Пользователи по-прежнему могут изменять эти настройки во время выполнения; клиент повторно применяет управляемые значения по умолчанию при следующем запуске.

Если управляемое значение по умолчанию, профиль macOS MDM или сохранённая конфигурация закрепляют gpt-5.4 или gpt-5.4-mini для пользователей, вошедших через ChatGPT, обновите их до 31 августа 2026 года. Замените gpt-5.4 на gpt-5.6-terra, а gpt-5.4-mini — на gpt-5.6-luna. OpenAI API и Codex, аутентифицированные с помощью вашего собственного API key, не затрагиваются. См. раздел Доступность моделей в рабочем пространстве.

Убедитесь, что управляемые значения по умолчанию соответствуют требованиям; локальная среда выполнения отклоняет запрещённые значения.

Приоритет и наложение слоёв

Локальная среда выполнения собирает действующую конфигурацию в следующем порядке (верхние уровни переопределяют нижние):

• Управляемые настройки (macOS MDM; наивысший приоритет)
• managed_config.toml (системный или управляемый файл)
• config.toml (базовая конфигурация пользователя)

Переопределения CLI --config key=value применяются к базовой конфигурации, но управляемые слои переопределяют их. Это означает, что каждый запуск начинается с управляемых значений по умолчанию, даже если вы указали локальные флаги.

Управляемые из облака требования влияют на слой требований, а не на управляемые значения по умолчанию. Порядок приоритета описан выше в разделе о требованиях, устанавливаемых администратором.

Расположение

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows и другие системы, не относящиеся к Unix: ~/.codex/managed_config.toml

Если файл отсутствует, локальная среда выполнения пропускает управляемый слой.

Управляемые настройки macOS (MDM)

В macOS администраторы могут отправить профиль устройства с закодированными в base64 полезными данными TOML по адресу:

• Домен настроек: com.openai.codex
• Ключи:
  • config_toml_base64 (управляемые значения по умолчанию)
  • requirements_toml_base64 (требования)

Локальная среда выполнения анализирует эти полезные данные «управляемых настроек» как TOML. Для управляемых значений по умолчанию (config_toml_base64) управляемые настройки имеют наивысший приоритет. Для требований (requirements_toml_base64) порядок приоритета соответствует описанному выше порядку управляемых из облака требований. Та же таблица [features] на стороне требований работает в requirements_toml_base64; используйте и там канонические ключи функций.

Рабочий процесс настройки MDM

Локальная среда выполнения поддерживает стандартные полезные данные macOS MDM, поэтому настройки можно распространять с помощью таких инструментов, как Jamf Pro, Fleet или Kandji. Простой процесс развёртывания выглядит так:

1. Создайте TOML с управляемыми полезными данными и закодируйте его с помощью base64 (без переноса строк).
2. Поместите строку в профиль MDM в домене com.openai.codex по ключу config_toml_base64 (управляемые значения по умолчанию) или requirements_toml_base64 (требования).
3. Отправьте профиль, затем попросите пользователей перезапустить поддерживаемый локальный клиент и убедиться, что в сводке конфигурации при запуске отображаются управляемые значения.
4. При отмене или изменении политики обновите управляемые полезные данные; клиент прочитает обновлённую настройку при следующем запуске.

Не встраивайте в полезные данные секреты или часто изменяющиеся динамические значения. Применяйте к управляемому TOML такой же контроль изменений, как и к другим настройкам MDM.

Пример 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

Рекомендуемые защитные ограничения

• Для большинства пользователей предпочтительно использовать workspace-write с одобрениями; полный доступ предоставляйте только в контролируемых контейнерах.
• Сохраняйте network_access = false, если только проверка безопасности не разрешает сборщик или домены, необходимые для ваших рабочих процессов.
• Используйте управляемую конфигурацию для закрепления настроек OTel (экспортёра, среды), но сохраняйте log_user_prompt = false, если ваша политика явно не разрешает хранить содержимое запросов.
• Периодически проверяйте различия между локальным config.toml и управляемой политикой, чтобы выявлять расхождения; управляемые слои должны иметь приоритет над локальными флагами и файлами.