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

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

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

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

Настройка маркетплейсов плагинов и значений по умолчанию

Задайте локальные маркетплейсы или маркетплейсы Git и значения по умолчанию для плагинов в системном config.toml или в разделе config.toml на странице Управляемая конфигурация. Эти настройки задают значения по умолчанию, а не обязательную политику.

Ключи конфигурации описаны в справочнике по конфигурации, приоритет конфигурации определяет порядок переопределения, а настройки плагинов для репозитория задают конфигурацию на уровне проекта. Импорт из GitHub в рабочее пространство и синхронизация настраиваются отдельно.

Требования, устанавливаемые администратором (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 справочника по конфигурации.

Переход с выведенной из эксплуатации политики подтверждений untrusted

Codex и ChatGPT Work больше не поддерживают approval_policy = "untrusted". Удалите эту настройку из управляемых значений по умолчанию, устаревшего managed_config.toml и любых пользовательских, проектных, профильных или стартовых конфигураций, в которых она задана.

Для интерактивной работы только на чтение выберите approval_policy = "on-request" вместе с песочницей только для чтения или профилем разрешений, допускаемым вашими управляемыми требованиями. Команды, разрешённые этой песочницей, могут выполняться без подтверждения.

Чтобы сохранить более строгие подтверждения команд, не задавайте явно approval_policy, установите trust_level = "untrusted" в записи проекта в пользовательском файле ~/.codex/config.toml и оставьте untrusted в allowed_approval_policies. Это также отключает локальную конфигурацию проекта. Явное указание on-request переопределяет эту политику. См. раздел Переход с выведенной из эксплуатации политики подтверждений untrusted, где приведены примеры и описаны компромиссы в отношении безопасности.

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

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

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. Требованиями к аутентификации необходимо управлять локально.

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

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

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

Проверьте работу для администратора и сотрудника

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

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

Локальное управление аутентификацией

Задайте allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store и chatgpt_base_url в локальном системном файле requirements.toml или в требованиях MDM для macOS. Codex игнорирует эти четыре поля в облачных управляемых требованиях. Локальные требования к аутентификации применяются до загрузки учётных данных и до получения облачной политики Codex.

Чтобы требовать вход через ChatGPT в разрешённое рабочее пространство и хранить учётные данные в хранилище учётных данных ОС, используйте:

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

allowed_login_methods принимает chatgpt, api или оба значения. Если параметр не задан, эта настройка не ограничивает способы входа. Если задан, список должен содержать хотя бы один способ. api разрешает аутентификацию через API, включая Amazon Bedrock. Ограничение рабочего пространства также распространяется на токены доступа Codex.

Заданные пользователем forced_login_method и forced_chatgpt_workspace_id должны соответствовать требованиям. Выбранное пользователем рабочее пространство также должно присутствовать в управляемом списке разрешённых рабочих пространств. Если подходящих рабочих пространств нет, вход через ChatGPT недоступен. Аутентификация через API остаётся доступной, если она разрешена. Если ни один способ входа недоступен, Codex отказывается запускаться.

См. справочник по требованиям, где описаны режимы хранения учётных данных и настройка URL сервиса.

Пример requirements.toml

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

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

Здесь untrusted сохраняет более строгий порядок подтверждений, определяемый trust_level = "untrusted"; это не делает approval_policy = "untrusted" поддерживаемой настройкой для явного указания.

Отключение 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]
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"

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

*.example.com соответствует только поддоменам. **.example.com соответствует корневому домену и его поддоменам. Совпавшее запрещающее правило имеет приоритет над разрешающим.

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

Прокси-сервер маршрутизирует локальные команды, выполняемые внутри песочницы. Инструменты браузера также проверяют управляемые сетевые запреты и исключительные списки разрешений перед обращением к источнику; это отдельная проверка политики, а не маршрутизация трафика браузера через прокси-сервер команд. Она не фильтрует веб-поиск, приложения и коннекторы, MCP servers, трафик нативных приложений, запросы к сервису Codex или облачный трафик Codex. Используйте элементы управления для каждой поверхности:

• Используйте allowed_web_search_modes, чтобы ограничить веб-поиск.
• Используйте features.apps = false, чтобы отключить интеграции приложений и коннекторов, а features.plugins = false — чтобы отключить плагины там, где это поддерживается.
• Используйте управляемый список одобренных mcp_servers, чтобы ограничить MCP servers.
• Используйте требования к функциям, такие как browser_use, in_app_browser и computer_use, чтобы ограничить возможности браузера и Computer Use.
• Настройте сетевой доступ облака Codex в параметрах его облачной среды.

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

Управление браузером и Computer Use

Используйте таблицы [browser_use] и [computer_use] в requirements.toml, чтобы ограничивать поддерживаемые клиенты для компьютера. Проверьте политику на версиях клиентов и операционных системах в вашем развертывании. Настроенное разрешающее правило не устанавливает плагин, не предоставляет разрешение операционной системы и не подтверждает действие, которое всё ещё требует проверки.

Для доступа через браузер настройте политику источников. Источник включает схему, хост и необязательный порт, например https://example.com или https://*.example.com:8443. Не включайте путь, строку запроса или фрагмент. В отличие от правил доменов сети для команд, правила источников браузера различают HTTP и HTTPS и учитывают порт.

Этот пример ограничивает доступ браузера одобренным сайтом и запрещает на нём отправку файлов и полный доступ по протоколу Chrome DevTools Protocol (CDP):

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

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

Задайте browser_use.disable_auto_review = true, чтобы отключить автоматическую проверку подтверждений для действий браузера, или задайте auto_review = "deny" в политике источника, чтобы ограничить её для этого источника. Это управляет обработкой подтверждений, но не отключает контроль безопасности модели.

Для нативных приложений задайте политику доступа по умолчанию и укажите разрешённые приложения. Например, эта политика macOS разрешает Calculator и запрещает сохранённые подтверждения:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Политики Windows могут идентифицировать упакованные приложения с помощью computer_use.windows.aumids или исполняемые файлы с помощью computer_use.windows.exes. Для правил исполняемых файлов требуются publisher_name, product_name и access; binary_name является необязательным. Используйте проверенный идентификатор приложения, а не только его отображаемое имя.

Полный перечень полей приведён в справочнике по конфигурации, а ограничения управляемого режима Locked Use для устройств macOS — в разделе Ограничения Locked Use.

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

Также можно закрепить флаги функций для пользователей, получающих управляемый 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 в локальной среде выполнения, включая режим разработчика браузера, и не позволяет приложению ChatGPT для компьютера включить соответствующую настройку.
• browser_use_external = false отключает внешний Browser Use.
• computer_use = false отключает Computer Use, Record & Replay и связанные процессы установки или настройки.

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

Ограничение Locked Use

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

[computer_use]
allow_locked_computer_use = false

Это требование удаляет элементы управления для включения Locked Use. Оно не отключает Locked Use, если режим уже включён. Если требование пропущено, продолжат действовать обычная доступность продукта и локальная настройка пользователя.

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

Используйте 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 servers, которые может включать локальный клиент, добавьте список одобренных mcp_servers. Для stdio MCP servers сопоставляйте по 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 servers, поставляемые в составе плагинов, используют те же формы идентификаторов в plugins.<plugin>.mcp_servers.<server>.

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

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

Чтобы отключить плагины в поддерживаемых локальных клиентах, задайте для 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, если их источники не соответствуют правилам. Они также фильтруют настроенные маркетплейсы и их плагины во время выполнения.

Курируемые OpenAI маркетплейсы Git, включая каталог с API key, также должны соответствовать списку разрешённых источников. Чтобы разрешить их, добавьте следующий источник Git без ограничения ref:

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

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

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

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

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

Если управляемая настройка по умолчанию, профиль macOS MDM или сохранённая конфигурация закрепляет gpt-5.5 для пользователей Codex, вошедших через ChatGPT, замените её на gpt-5.6-sol до 14 октября 2026 года. В этот день GPT-5.5 станет недоступна в ChatGPT, ChatGPT Work и Codex на всех тарифных планах. OpenAI API это не затронет. См. раздел Доступность моделей в рабочем пространстве.

Если управляемое значение по умолчанию, профиль MDM macOS или сохранённая конфигурация закрепляют 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. Подробнее см. в разделе Доступность моделей в рабочем пространстве.

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

Приоритет и наложение уровней

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

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

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

Для облачного config.toml действует обычный приоритет конфигурации, а не описанный выше устаревший порядок. Для облачного requirements.toml действует приоритет требований.

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

• 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

Локальная среда выполнения поддерживает стандартные полезные данные MDM для macOS, поэтому настройки можно распространять с помощью таких инструментов, как 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 и управляемой политикой, чтобы выявлять расхождения; управляемые уровни должны иметь приоритет над локальными флагами и файлами.