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

Управляемая конфигурация позволяет корпоративным администраторам задавать поддерживаемые требования и значения по умолчанию для ChatGPT Work и Codex. Требования ограничивают действия пользователей и задач. Значения по умолчанию задают исходные настройки. Поддержка зависит от продукта, версии клиента и среды выполнения.

Начните с раздела Безопасность агентов в консоли администратора для поддерживаемых настроек, управляемых из облака. Для типовых задач используйте элементы управления настройками или выберите Редактировать как TOML, чтобы просмотреть, скопировать или изменить текст конфигурации. Оба представления изменяют одну и ту же политику; TOML также предоставляет доступ к поддерживаемым полям без отдельных элементов управления. Для использования настроек, управляемых из облака, не нужно распространять локальный файл. Для ограничений аутентификации и развёртываний под управлением устройств предусмотрена отдельная локальная настройка.

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

• Требования: ограничения, принудительно заданные администратором, которые пользователи не могут переопределить.

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

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

Базовые настройки Global, переопределения для сред и списки полей оркестратора и исполнителя описаны в разделе Agent Security.

Настройка политики в разделе «Безопасность агентов»

Если раздел «Безопасность агентов» включён, владельцы и администраторы рабочей области, а также участники с правами администратора Codex могут управлять политиками. Доступ к редактору политик не предоставляет участникам доступ к функциям, которыми управляет политика.

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

1. Откройте Консоль администратора > Безопасность агентов и выберите По умолчанию для рабочей области или нужную политику в разделе Переопределения.
2. Откройте Требования, чтобы задать обязательные ограничения, или Значения по умолчанию, чтобы задать начальные значения, которые участники могут менять в пределах этих ограничений.
3. Храните настройки подтверждений, веб-поиска и другие общие настройки агента в разделе Глобальные. Если доступно, используйте Добавить настройки среды в соответствующей карточке, чтобы добавить Локальные среды или Облачные среды Codex для поддерживаемых настроек выполнения. Пустой документ среды наследует настройки из раздела «Глобальные»; он не копирует и не фиксирует текущие базовые настройки.
4. Используйте элементы управления, описанные в этом руководстве. Для расширенных полей выберите Редактировать как TOML и измените requirements.toml или config.toml соответствующей области действия. Выберите Использовать элементы управления настройками, чтобы вернуться в визуальный редактор.
5. Просмотрите сообщения проверки, затем выберите Сохранить изменения. Применение правила в редакторе правил обновляет черновик, но само по себе не сохраняет политику.
6. Проверьте выбор политики и поведение поддерживаемых клиентов, как описано в разделе Проверка работы для администратора и сотрудника.

Доступные редакторы сред и поддерживаемые поля зависят от рабочей области и политики. См. раздел Где применяются настройки, прежде чем переносить настройку из раздела «Глобальные» в среду. Настройка в разделе «Глобальные» не обязательно применяется ко всем продуктам или способам выполнения.

Копирование или повторное использование конфигурации

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

1. Откройте исходную политику и выберите Редактировать как TOML.
2. Выберите область действия для копирования: Глобальные или доступную вкладку среды. Скопируйте текст из раздела Требования (requirements.toml), Значения по умолчанию (config.toml) или из обоих разделов — в зависимости от того, что нужно использовать повторно.
3. Откройте целевую политику, выберите Редактировать как TOML и укажите соответствующую область действия. Вставьте требования в requirements.toml, а значения по умолчанию — в config.toml. Перед заменой текста проверьте существующие настройки целевой политики; сохраните остальные настройки, которые должны продолжать действовать.
4. Просмотрите сообщения проверки, целевые аудитории и приоритет целевой политики, затем выберите Сохранить изменения. Проверьте итоговое поведение клиентов, прежде чем полагаться на скопированную политику.

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

Попробуйте пример ниже: измените настройку, затем выберите Редактировать как TOML, чтобы увидеть её конфигурацию. Вернитесь через Использовать элементы управления настройками, чтобы продолжить экспериментировать.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Выбор подходящего элемента управления

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

Используйте раздел Безопасность агентов в консоли администратора, чтобы управлять доступом к браузеру и нативным приложениям для поддерживаемых настольных клиентов. Начните с элементов управления интерфейса. Примеры TOML ниже служат справочником по конфигурации для распространения политик в файлах и настроек, для которых нужен редактор TOML.

Browser Use управляет действиями агента в браузере. Computer Use управляет действиями агента в нативных настольных приложениях. Настройки встроенной панели браузера отделены от Browser Use. См. раздел Сеансы браузера и существующие авторизации, чтобы узнать о различиях между способами работы с браузером.

Перед началом работы

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

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

В разделе Доступность функций настольного приложения проверьте Использование браузера, Использование внешнего браузера и Использование компьютера. Принудительно отключить отключает соответствующую функцию; разрешающее правило для сайта или приложения не отменяет это ограничение. Отдельно проверьте Полный доступ к CDP; Запретить включение пользователем не позволяет пользователям включать его.

Эти настройки настольного приложения не управляют размещённым в облаке браузером Work Cloud. Настройте Использование облачного браузера и Доступ облака к сети отдельно в разделе Консоль администратора > Разрешения и роли > Возможности рабочего пространства > Возможности облачного компьютера. См. как Agent Security применяется к Work Cloud.

Настройка доступа к браузеру

1. Откройте Консоль администратора > Безопасность агента. Используйте Настройки рабочего пространства по умолчанию для базовых настроек рабочего пространства или откройте нужную политику в разделе Переопределения. В разделе Требования перейдите к Настройкам браузера настольного приложения.
2. В разделе Правила для сайтов откройте меню действий строки По умолчанию и выберите Изменить настройки по умолчанию. Чтобы ограничить доступ одобренными сайтами, установите для Доступа к сайту значение Блокировать, затем выберите Применить правило. Строка По умолчанию задаёт значения для параметров, которые в совпадающем правиле для сайта оставлены в состоянии Использовать правило по умолчанию.
3. Выберите Добавить правило для сайта. В поле Сайт или шаблон введите источник: схему, имя хоста и необязательный порт. Например, https://example.com — допустимое значение; https://example.com/files — нет. Не указывайте путь, строку запроса или фрагмент. HTTP и HTTPS — разные источники. Укажите порт, если он отличается от стандартного порта схемы.
4. Настройте Доступ к сайту и проверьте Скачивание, Отправку файлов и Отладку/CDP. Выберите Разрешить или Блокировать в зависимости от задачи либо оставьте значение Использовать правило по умолчанию. Отладка/CDP управляет полным доступом к Chrome DevTools Protocol для отладки браузера. Значение Разрешить сохраняет обычные проверки политик и одобрений.
5. Проверьте Автоматическую проверку, Всегда разрешать и Срок действия одобрения для сайта. Для Срока действия одобрения доступны варианты На этот ход и На эту беседу. Также проверьте Историю браузера, Сохранение одобрений для сайтов и Автоматическое одобрение запросов в разделе Настройки браузера настольного приложения.
6. Выберите Добавить правило, проверьте сообщения валидации и нажмите Сохранить изменения. Проверьте разрешённый и заблокированный сайты в поддерживаемом клиенте, который получает эту политику. Проверьте отправку файлов, скачивание и другие ограниченные действия отдельно.

Добавить правило для сайта

Строка «По умолчанию» применяется, когда в правиле для сайта разрешение оставлено со значением «По умолчанию». Если правила пересекаются, для каждого разрешения приоритет имеет значение «Блокировать».

Сайт или шаблон 

Доступ к сайтуИспользовать правило по умолчанию

СкачиваниеИспользовать правило по умолчанию

Отправка файловИспользовать правило по умолчанию

Отладка/CDPИспользовать правило по умолчанию

Автоматическая проверкаИспользовать правило по умолчанию

Всегда разрешатьИспользовать правило по умолчанию

Срок действия одобренияИспользовать правило по умолчанию

При отключении автоматической проверки действий в браузере эти действия передаются пользователю для одобрения. Мониторинг безопасности модели при этом не отключается.

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

Computer Use также может управлять браузером как нативным приложением. Правила Browser Use для сайтов и возможностей не распространяются на этот способ работы. Проверьте доступ к нативным приложениям отдельно; см. границы безопасности браузера.

Настройка доступа к нативным приложениям

1. В разделе Требования перейдите к Настройкам настольных приложений > Правилам для приложений.
2. Используйте меню действий строки По умолчанию, чтобы настроить доступ для приложений, для которых нет подходящего правила. Чтобы ограничить Computer Use одобренными приложениями, заблокируйте доступ по умолчанию и добавьте разрешающие правила для этих приложений.
3. Выберите Добавить правило для приложения. В диалоговом окне Изменить правило выберите Идентификатор пакета macOS, Windows AUMID или Исполняемый файл Windows в поле Приложение. Введите точный Идентификатор приложения — идентификатор пакета или Application User Model ID (AUMID). Для Исполняемого файла Windows укажите Имя издателя и Название продукта; Имя двоичного файла указывать необязательно. Используйте проверенные сведения об идентичности приложения, а не отображаемое имя или путь к файлу.
4. Задайте Доступ к приложению для правила, затем выберите Добавить правило. Проверьте Сохранение одобрений для приложений в разделе Настройки настольных приложений, проверьте сообщения валидации и нажмите Сохранить изменения. Отключение сохранения одобрений по-прежнему допускает одобрения для текущего сеанса; разрешение сохранять одобрения само по себе не одобряет приложение.
5. Проверьте разрешённое и заблокированное приложения в каждой поддерживаемой операционной системе вашего развёртывания. Убедитесь, что разрешения операционной системы по-прежнему действуют и пользователи по-прежнему должны предоставлять необходимые одобрения.

Изменить правило

Задайте доступ к приложениям по умолчанию и переопределите его для подходящих приложений.

ПриложениеИдентификатор пакета macOS

Идентификатор приложения 

Доступ к приложениюВыберите доступ

См. поля политики Computer Use, чтобы узнать о требованиях к идентичности приложений в Windows, и ограничения использования при заблокированном компьютере для управляемых компьютеров Mac.

Проверка действующей политики

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

Если настройка не действует, убедитесь, что клиент, операционная система и способ доставки политики поддерживают её. Обратите особое внимание на Work Cloud с доступом к локальному компьютеру: некоторые поля поддерживаются частично или требуют проверки. См. совместимость с Work в справочнике по конфигурации.

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

Справочник по конфигурации TOML

Следующие примеры описывают ту же логику политики для requirements.toml. Используйте их при управлении политикой через файлы или редактор TOML. Чтобы использовать элементы управления в Agent Security, редактировать локальный файл не требуется.

Этот пример для браузера запрещает доступ по умолчанию, разрешает https://example.com, блокирует отправку файлов и полный доступ 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" в политике источника, чтобы ограничить проверку для этого источника.

Чтобы включить инструменты сайтов для рабочего пространства Enterprise, соответствующего условиям, задайте browser_use.allow_webmcp = true. Это управляемое включение применяется к встроенному браузеру настольного приложения. Значение false или отсутствие параметра сохраняет стандартные проверки доступности функции; false не устанавливает запрет. Пользовательские настройки и разрешения сайтов по-прежнему действуют.

Этот пример для нативных приложений разрешает Calculator в macOS, запрещает остальные приложения по умолчанию и не позволяет сохранять разрешения для приложений между сеансами:

[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 необязателен.

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

Другие элементы управления настольным приложением

Следующие элементы управления настольным приложением охватывают доступность функций, Locked Use, Appshots и удалённое управление устройством. Для доступности функций и Locked Use используйте специальные настройки; Appshots и удалённое управление устройством настраивайте через Редактировать как TOML. Об ограничениях адресов назначения для трафика настольного приложения см. Управление сетевыми адресами назначения настольного приложения.

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

Для функций настольного приложения, представленных в Agent security, откройте Глобальные настройки > Требования > Доступность функций настольного приложения. Задайте для Встроенный браузер, Использование браузера, Использование внешнего браузера или Использование компьютера значение Принудительно отключено, чтобы отключить соответствующую возможность, затем выберите Сохранить изменения. Для Полный доступ CDP выберите Запретить включение пользователем, чтобы пользователи не могли его включить. Разрешение функции не отменяет ограничения её доступности, связанные с продуктом, платформой или этапом развёртывания.

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

[features]
hooks = 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 или файле профиля.

Управляемый параметр unified_exec = false сохраняет возможность выполнения команд, но отключает возобновляемые процессы и инструмент write_stdin. Пользовательская конфигурация не может отключить эту функцию.

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

Отключение только Browser Use не блокирует все способы работы с браузером. Функция Computer Use для нативных приложений по-прежнему может управлять браузером, если эта возможность и доступ к приложению разрешены; правила Browser Use для сайтов и возможностей к этому способу не применяются. Чтобы заблокировать его, задайте для Использование компьютера значение Принудительно отключено (computer_use = false) или запретите приложение браузера в правилах приложений, если другие нативные приложения должны оставаться доступными. Отдельно проверьте параметры Использование внешнего браузера и Встроенный браузер. См. раздел Сеансы браузера и существующие входы в аккаунты, чтобы узнать, какие элементы управления применяются к каждому способу.

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

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

Чтобы запретить пользователям включать Locked Use на управляемом Mac, откройте Глобальные настройки > Требования > Элементы управления настольным приложением, задайте для Разрешить использование при блокировке значение Отключено и выберите Сохранить изменения. Эта настройка не отключает Locked Use на Mac, где функция уже включена.

Эквивалентное требование для редактора TOML или доставки через средства управления устройствами:

[computer_use]
allow_locked_computer_use = false

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

Отключение Appshots

Appshots позволяют поддерживаемым клиентам включать снимки приложений. Чтобы отключить их для пользователей с облачным управлением, откройте Редактировать как TOML в Agent security и задайте поле верхнего уровня allow_appshots в глобальном документе requirements.toml. Для развёртываний с управлением на уровне устройств используйте соответствующий локальный источник требований:

allow_appshots = false

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

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

Чтобы отключить удалённое управление устройством для пользователей с облачным управлением, используйте Редактировать как TOML в Agent security и задайте поле верхнего уровня allow_remote_control в глобальном документе requirements.toml. Вы можете также задать allow_remote_control в поддерживаемом локальном источнике требований:

allow_remote_control = false

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

Настройка подтверждений и разрешений на выполнение

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

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

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

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

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

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

Настройка ограничений для подтверждений, песочницы и веб-поиска

Используйте Требования > Ограничения политики, чтобы ограничить доступные в поддерживаемых клиентах варианты. Эти элементы управления ограничивают конфигурацию; они не задают начальное значение. Задайте начальное значение отдельно в разделе Значения по умолчанию.

1. В разделе Глобальные настройки откройте Политики подтверждения и выберите допустимые варианты. Например, Запрашивать при необходимости позволяет агенту запрашивать подтверждение для таких действий, как расширение прав за пределы песочницы. Никогда не запрашивать запрещает запросы подтверждения, но не предоставляет неограниченные права на выполнение.
2. Откройте Режимы песочницы, чтобы ограничить выбор устаревших режимов. Только чтение ограничивает запись, Запись в рабочую область разрешает запись в рабочей области и настроенных корневых каталогах с доступом на запись, а Полный доступ отключает изоляцию файловой системы. Используйте требования к профилям разрешений для развёртываний, в которых вместо sandbox_mode используются профили разрешений.
3. В разделе Глобальные настройки откройте Режимы веб-поиска, чтобы ограничить веб-поиск. Выберите Кэшированный, чтобы разрешить поиск по кэшу без поиска в реальном времени, или Отключён, чтобы отключить веб-поиск. Ограничения веб-поиска действуют отдельно от сетевых правил для команд.
4. Проверьте допустимые варианты и соответствующие значения по умолчанию, затем нажмите Сохранить изменения.

Если требование не задано, эта политика не вводит соответствующего ограничения. Другие применимые политики продолжают действовать. Параметр Запрашивать для недоверенных команд соответствует untrusted в списке разрешённых значений требований; он не восстанавливает поддержку устаревшей явной настройки approval_policy = "untrusted". Для этого случая следуйте приведённым ниже инструкциям по миграции.

Чтобы ограничить веб-поиск, перейдите в Глобальные настройки > Требования > Ограничения политик > Режимы веб-поиска. Эквивалентная настройка TOML:

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

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

Задайте значения конфигурации по умолчанию

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

1. Откройте карточку Значения по умолчанию в политике. Общие для агента значения задавайте в разделе Глобальные настройки; для поддерживаемых настроек выполнения используйте доступную вкладку среды.
2. В разделе Выполнение команд выберите начальные значения Политики подтверждения и Проверяющего запросы подтверждения, а также применимый Режим песочницы или Разрешения по умолчанию. Проверяющий определяет, кто по умолчанию рассматривает запросы подтверждения; политика подтверждения определяет, когда могут возникать такие запросы.
3. В разделе Веб-поиск выберите начальный режим Веб-поиска и Контекст веб-поиска. В разделе Приложения и инструменты проверьте параметры Приложения/коннекторы, Инструменты открытого мира и Разрушительные инструменты для поддерживаемых инструментов приложений.
4. Убедитесь, что значения по умолчанию соответствуют вашим Требованиям, затем нажмите Сохранить изменения.

Используйте Редактировать как TOML для поддерживаемых значений по умолчанию без элементов управления в интерфейсе, например для конфигурации каталога плагинов. Эти облачные значения по умолчанию используют обычный порядок приоритетов конфигурации. Они отличаются от устаревшего порядка приоритетов managed_config.toml, при котором управляемые значения по умолчанию имеют при запуске приоритет над локальной конфигурацией.

Пример 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" поддерживаемой настройкой для явного указания.

Перейдите с устаревшей политики подтверждения 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 для ознакомления с примерами и компромиссами в области безопасности.

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

Чтобы включить автоматическую проверку по умолчанию, перейдите в Глобальные настройки > Значения по умолчанию > Выполнение команд > Проверяющий запросы подтверждения. Значение по умолчанию позволяет пользователям выбрать другого разрешённого проверяющего. Чтобы сделать автоматическую проверку обязательной или задать инструкции вашей организации по проверке, используйте Редактировать как TOML и измените глобальный requirements.toml. Эти требования действуют отдельно от элементов управления автоматической проверкой в браузере.

Используйте 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.
"""

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

Используйте Значения по умолчанию > Выполнение команд > Разрешения по умолчанию, чтобы выбрать встроенный профиль, с которым пользователи начинают работу. Чтобы ограничить выбор профилей или определить собственные профили, используйте Редактировать как TOML и настройте requirements.toml для соответствующей глобальной области или поддерживаемой среды выполнения. Сам по себе выбор профиля по умолчанию не ограничивает доступные профили.

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

Обеспечьте соблюдение требований запрета чтения

Используйте Редактировать как TOML, чтобы добавить ограничения файловой системы в requirements.toml для соответствующей глобальной области или поддерживаемой среды выполнения. Эти ограничения блокируют чтение конфиденциальных путей; режим только чтения по умолчанию сам по себе не скрывает файлы.

Администраторы могут запретить чтение по точным путям или 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 применяется к инструментам прямого доступа к файлам; чтение из подпроцессов оболочки не использует это правило песочницы.

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

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

Используйте [[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. Сопоставление имени хоста предназначено только для выбора политики; не рассматривайте его как подтверждённое доказательство подлинности устройства.

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

Используйте Редактировать как TOML в разделе безопасности агента, чтобы добавить правила команд и ограничения серверов MCP в глобальный requirements.toml. Правила команд задают решения о подтверждении или запрете для соответствующих команд; ограничения MCP определяют, какие идентификаторы серверов клиент может включать. Элемент управления Политики подтверждения не создаёт ни один из этих наборов правил.

Администраторы также могут применять ограничительные правила команд из 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.

Настройте сетевой доступ

Сетевой доступ команд и настольных приложений регулируется разными элементами управления. Начните с Управления использованием сети для поддерживаемого трафика команд, изучите ограничения среды и среды выполнения, затем при необходимости используйте отдельные требования для настольных приложений. Правила сайтов для браузера описаны в разделе Управление браузером и Computer Use.

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

Используйте Требования > Управление использованием сети, чтобы управлять поддерживаемым сетевым доступом команд в разделе безопасности агента. Настройте общие базовые параметры в разделе Глобальные настройки или на доступной вкладке Локальные среды либо Облачные среды Codex, чтобы задать настройки выполнения для конкретной среды.

1. Установите для Управляемого сетевого доступа значение Вкл., чтобы применять правила доменов к управляемому трафику команд. Само по себе добавление правил доменов не активирует управляемый прокси.
2. В разделе Сетевые правила выберите Добавить сетевое правило. Введите Домен, например api.openai.com или **.example.com, без схемы URL и пути. Выберите Разрешить или Запретить в поле Доступ, затем выберите Сохранить правило, чтобы обновить черновик. Повторите для других адресов назначения.
3. Установите для Разрешать только домены, добавленные администраторами значение Вкл., если пользовательские настройки и одобрения отдельных доменов не должны расширять управляемый список разрешённых доменов. Добавьте необходимые разрешающие записи; список только из запрещающих записей не разрешает доступ к другим адресам назначения.
4. Проверьте настройку Разрешить доступ к локальной сети для рабочих процессов, которым нужны локальные прослушивающие сокеты или частные адреса назначения. Прямые локальные подключения могут обходить правила доменов прокси. Прежде чем менять эту настройку, ознакомьтесь с приведёнными ниже ограничениями подключения Codex Cloud.
5. Проверьте унаследованные правила и сообщения проверки, затем выберите Сохранить изменения. В каждой затронутой среде выполнения проверьте запрос, который должен пройти успешно, и запрос, который должен быть заблокирован.

Установка для Управляемого сетевого доступа значения Выкл. удаляет сетевые правила, заданные в этой области, и сохраняет явное значение отключения; доступ к интернету при этом не отключается. Значение Не задано удаляет сетевые настройки, заданные в этой области, позволяя применить действующую политику или значения среды выполнения по умолчанию. Удаление настроек среды может привести к применению унаследованных правил Global. Используйте Редактировать как TOML для расширенных сетевых полей или существующих устаревших списков доменов, которые визуальный редактор не может представить.

Используйте [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 и другой трафик отдельных возможностей. Используйте средства управления для каждого компонента:

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

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

При поддерживаемых способах управляемого выполнения в Codex Cloud требования Agent Security ограничивают сетевой доступ команд. Настройки доступа к интернету среды Codex Cloud применяются отдельно. Разрешённый домен в Agent Security не отменяет ограничение в настройках доступа к интернету среды Cloud. Эти средства управления сетевым доступом команд сами по себе не отключают облачный веб-поиск, приложения или MCP. ChatGPT Work Cloud использует отдельные разрешения для возможностей и не наследует эти требования Agent Security.

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

Нет разрешённых адресов назначения в итоговой конфигурации: Когда для Управляемого сетевого доступа и Разрешать только домены, добавленные администраторами установлено значение «Вкл.», обычным управляемым командам нужны разрешённые адреса назначения в итоговой конфигурации. Если разрешающие записи не настроены и не унаследованы, у этих команд нет разрешённых адресов назначения. Политика только из запрещающих записей не разрешает неявно доступ к остальному интернету. Перед сохранением добавьте необходимые разрешающие записи и проверьте унаследованные правила. Это ограничение относится к прокси управляемых команд, а не ко всем инструментам или одобренному выполнению с полным выходом за ограничения песочницы.

Доступ Codex Cloud к локальным и частным сетям: Явное значение Off для доступа к локальным и частным сетям может помешать Codex Cloud подключиться к вышестоящему прокси, даже если домен назначения разрешён. Проверьте итоговое значение allow_local_binding и определите, какая политика или настройка его задаёт. При использовании поддерживаемого прокси-подключения Cloud значение по умолчанию равно true, только если его не задаёт ни одно применимое требование, выбранный сетевой профиль или настройка функции прокси. Унаследованное значение false также считается явно заданной настройкой. Если это поддерживается, задайте переопределение Cloud с более высоким приоритетом, чтобы изменить это значение для Codex Cloud, не меняя значение Global, используемое в Local. Это не добавляет разрешающих записей для доменов. Прежде чем полагаться на переопределение, убедитесь, что исполнитель его поддерживает. Не применяйте это значение Cloud по умолчанию к Local.

Если требования среды не заданы, применяются требования Global. Значение Выкл. для Управляемого сетевого доступа не связано с настройкой доступа к интернету в среде Cloud. См. Элементы управления выполнением в разделе безопасности агентов для получения сведений об области выполнения.

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

В рамках одной политики порядок от высшего приоритета к низшему таков: переопределение среды для конкретной ОС → переопределение среды для всех ОС → Global. Политика с более высоким приоритетом по-прежнему имеет преимущество перед политикой с более низким приоритетом, даже если последняя более конкретна. Для некоторых требований действуют особые правила объединения полей. Затем среда выполнения обеспечивает соблюдение итоговых требований. Рассматривайте приведённые ниже сетевые особенности отдельных полей отдельно от приоритета политик.

В этих примерах сравниваются настройки среды и Global в рамках одной политики, когда управляемый сетевой доступ уже настроен и политика с более высоким приоритетом не изменяет значения. Они описывают особенности объединения отдельных полей и поведения среды выполнения.

Настройка разного доступа к доменам для разных сред

Для одного и того же правила домена в рамках политики заданное администратором переопределение среды может разрешить домен, запрещённый в Global, или запретить домен, разрешённый в Global. Если переопределение среды отсутствует, наследуется правило Global. Другие действующие запрещающие правила или средства контроля доступа по-прежнему могут заблокировать запрос.

Как объединяются правила доменов

Эти результаты относятся к одному и тому же ключу домена в рамках одной политики, когда политика с более высоким приоритетом не изменяет результат. Значение с более высоким приоритетом заменяет значение того же ключа. Другие унаследованные ключи сохраняются. Разрешающее правило не позволяет обойти другое подходящее запрещающее правило, например унаследованный шаблон с подстановочными знаками. Пустая карта правил среды не удаляет унаследованные правила.

Пример: Запретите packages.example.com в Global и разрешите его в Development. В Development доступ может быть разрешён при соблюдении указанных выше условий. Production наследует запрет Global, если он не переопределён.

Убедитесь, что развёрнутый исполнитель поддерживает эти правила объединения. Их поддержку обычными управляемыми исполнителями ещё необходимо проверить.

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

Другие сетевые ограничения среды выполнения

Все перечисленные ниже поля находятся в разделе experimental_network файла requirements.toml. Стрелки показывают значение Global, за которым следует значение среды в рамках той же политики. Эти примеры локального выполнения не подтверждают поддержку тех же настроек в Orchestrator.

Активация прокси, режим доступа только к разрешённым доменам, поведение вышестоящего прокси и правила Unix-сокетов зависят от исполнителя. Не переносите правила объединения ключей доменов на эти настройки. Проверьте итоговые значения и протестируйте развёрнутую среду выполнения. Сведения о локальных и частных подключениях Codex Cloud см. в разделе Настройка требований к сетевому доступу.

Проверка поведения перед внедрением

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

Управление сетевыми адресами назначения настольного приложения

Используйте Редактировать как TOML в разделе безопасности агентов, чтобы настроить эти требования для настольного приложения в Global. Интерфейс Управление использованием сети управляет сетевым доступом команд, для которого действует отдельная политика.

Используйте [application.network] в requirements.toml, чтобы ограничить сетевые адреса назначения настольного приложения. При enabled = true внешние запросы должны использовать HTTPS или WSS и точно соответствовать домену со значением "allow" в [application.network.domains]. Поддомены автоматически не разрешаются. Пустая карта доменов запрещает все внешние адреса назначения. Поддерживаемые ключи перечислены в справочнике конфигурации.

Эта политика действует отдельно от правил сетевого доступа команд и правил источников браузера. Она не ограничивает адреса назначения для нативных модулей или запускаемых процессов и не регулирует выполнение в Work Cloud.

Настройка плагинов и управляемых хуков

Для этих задач используйте Редактировать как TOML в разделе безопасности агентов или поддерживаемый локальный источник конфигурации. Настройки маркетплейсов по умолчанию, обязательные ограничения плагинов и управляемые хуки служат разным целям; выберите задачу, соответствующую нужной вам политике.

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

Используйте Безопасность агентов > Редактировать как TOML, чтобы задать локальные маркетплейсы или маркетплейсы Git и настройки плагинов по умолчанию в документе config.toml области Global. Эти настройки также можно распространять через системный config.toml. Они задают начальную конфигурацию маркетплейсов и плагинов, а не обязательную политику. Чтобы ограничить источники, которые могут использовать участники, настройте требования к источникам маркетплейсов.

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

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

Используйте Редактировать как TOML в разделе безопасности агентов для обязательных настроек функций плагинов в requirements.toml области Global или распространяйте их через локальные требования для клиентов на управляемых устройствах. Настройки по умолчанию > Приложения и инструменты > Приложения/коннекторы задаёт настройки инструментов приложений по умолчанию; это не обязательный переключатель features.plugins. Сведения о разрешениях плагинов в рабочей области см. в разделе Приложения и коннекторы.

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

features.plugins = false

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

Ограничение источников маркетплейса плагинов

Используйте Редактировать как TOML, чтобы настроить требования к источникам маркетплейсов в глобальном requirements.toml, или доставляйте их через локальные требования. Эти правила ограничивают локальные источники и источники Git, которые пользователи могут добавлять и использовать. Они не связаны с настройками маркетплейса по умолчанию.

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

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

Управляемые хуки выполняют заданные администратором действия при поддерживаемых событиях задач или инструментов. Используйте Редактировать как TOML в Agent Security, чтобы настроить их в глобальном requirements.toml; отдельного редактора хуков в интерфейсе настроек нет. Описанные ниже варианты выполнения определяют, какие типы хуков могут запускаться.

Когда включены управляемая политика и удалённые хуки, Work Cloud с локальным доступом и dots используют управляемые администратором удалённые MCP-хуки в облачном оркестраторе. Настройте обработчики mcp_tool в глобальном requirements.toml. Work Cloud без локального доступа и личные аккаунты не используют эти корпоративные хуки. При облачной оркестрации не поддерживаются обработчики команд и оболочки, запросов и агентов; хуки из локальной конфигурации, плагинов или локальных каталогов; хуки с областью действия, ограниченной средой; а также MCP-хуки SessionEnd, даже если инструменты выполняются локально. Когда и оркестрация, и выполнение происходят локально, существующие поддерживаемые хуки продолжают работать в полностью локальных обсуждениях Work и Codex. Администраторы по-прежнему могут настраивать поддерживаемые управляемые хуки в Agent Security для этих рабочих процессов.

Прежде чем полагаться на эти хуки, проверьте доступность обратных вызовов, необходимые события и поведение при сбоях. Явный отказ в поддерживаемом формате может заблокировать действие, но ошибка обратного вызова PreToolUse, превышение времени ожидания или некорректный ответ могут привести к сбою хука без блокировки инструмента. MCP-хуки не обеспечивают полный журнал аудита Compliance API. Приведённые ниже примеры скриптов и каталогов по-прежнему относятся к Codex.

Администраторы также могут определять управляемые хуки жизненного цикла непосредственно в 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 и других управляемых слоёв конфигурации.

Область действия и приоритет политик

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

Для Work с локальным доступом и dots поддерживаемая политика Global регулирует работу общего облачного оркестратора, когда включена управляемая политика; применимые требования к локальному выполнению регулируют работу подключённого компьютера. В облачных контейнерах Work сохраняются существующие политики Work Cloud, а поддерживаемые средства контроля устройств по-прежнему применяются к локальному выполнению. Поведение конфигурации Codex остаётся прежним. Управляемая конфигурация не предоставляет место в рабочем пространстве или доступ к функциям. Эти возможности описаны в разделе Роли и разрешения рабочего пространства.

Agent Security и доступ к локальному компьютеру в Work Cloud

Используйте Agent Security в консоли администратора для управления политиками и конфигурацией. Этот раздел заменяет «Политики и конфигурация». Agent Security доступен в консоли администратора независимо от доступа к локальному компьютеру в Work Cloud. Существующие политики, назначения и порядок сохраняются. Проверьте существующие политики в Agent Security. Доступ к локальному компьютеру в Work Cloud включается отдельно. Рекомендации по миграции см. в разделе Agent Security.

Перед переносом автоматизации политик в Agent Security:

1. Определите затронутые интеграции. Составьте список конфигураций Terraform и скриптов, обновляющих политики, и укажите, какими политиками они управляют.

2. Используйте API политик для управления настройками Global. Для управления настройками Local или Codex Cloud используйте интерфейс Agent Security. Существующие рабочие процессы с API для Global остаются доступны после миграции. Проверьте скрипты и интеграции Terraform и убедитесь, что назначения и порядок политик не изменились.

3. Внесите необходимые изменения и протестируйте автоматизацию. Убедитесь, что запланированное обновление применяется к нужной политике Agent Security и что соответствующие меры контроля действуют.

Миграция политик не предоставляет Work или dots доступ к локальному компьютеру. Перед развёртыванием рекомендуется проверить или создать политики, однако процедура подтверждения не требует создания политики для включения доступа. Перед включением Разрешить доступ к локальному компьютеру проверьте перенесённую базовую конфигурацию или создайте облачную базовую конфигурацию, если сейчас ваши политики доставляются только через MDM. Если в какой-либо облачной политике включён параметр enforce_residency, настройка Разрешить доступ к локальному компьютеру недоступна как для Work, так и для dots. Эта защитная мера не настраивает регион хранения данных рабочего пространства и сама по себе не отключает Work Cloud или dots.

Переопределения для сред позволяют изменять поддерживаемые настройки в пределах политики. В рамках одной политики приоритет убывает в следующем порядке: переопределение для среды конкретной ОС → переопределение для среды всех ОС → Global. Политика с более высоким приоритетом по-прежнему имеет преимущество перед политикой с более низким приоритетом, даже если последняя более конкретна. Для некоторых требований действуют правила объединения, зависящие от поля. Проверьте, какие редакторы переопределений и поля доступны в вашем рабочем пространстве.

Когда включены управляемая политика и удалённые хуки, Work Cloud с локальным доступом и dots используют управляемые администратором удалённые MCP-хуки в облачном оркестраторе. Настройте обработчики mcp_tool в глобальном requirements.toml. Work Cloud без локального доступа и личные аккаунты не используют эти корпоративные хуки. При облачной оркестрации не поддерживаются обработчики команд и оболочки, запросов и агентов; хуки из локальной конфигурации, плагинов или локальных каталогов; хуки с областью действия, ограниченной средой; а также MCP-хуки SessionEnd, даже если инструменты выполняются локально. Когда и оркестрация, и выполнение происходят локально, существующие поддерживаемые хуки продолжают работать в полностью локальных обсуждениях Work и Codex. Администраторы по-прежнему могут настраивать поддерживаемые управляемые хуки в Agent Security для этих рабочих процессов. Прежде чем полагаться на эти хуки, проверьте доступность обратных вызовов, необходимые события и поведение при сбоях. Явный отказ в поддерживаемом формате может заблокировать действие, но ошибка обратного вызова PreToolUse, превышение времени ожидания или некорректный ответ могут привести к сбою хука без блокировки инструмента. MCP-хуки не обеспечивают полный журнал аудита Compliance API. См. Справочник по конфигурации.

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

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

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

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

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

Приоритет при доступе к локальному компьютеру в Work Cloud

Для Work с локальным доступом и dots различайте политику Global для оркестратора и политику выполнения. Применимые локальные требования регулируют работу подключённого компьютера. Облачные контейнеры Work и облачные компьютеры dots используют собственную конфигурацию выполнения и требования вместо управляемого пакета среды, который используют другие исполнители.

При локальном выполнении требования MDM и устаревшего механизма управления устройствами имеют более высокий приоритет, чем Agent Security. Системный файл требований устройства имеет более низкий приоритет, чем Agent Security. В рамках каждой политики сначала применяются переопределения среды для конкретной ОС, затем переопределения для всех ОС, а затем Global. При сравнении разных политик приоритет политики важнее специфичности.

Требования задают ограничения, а значения конфигурации по умолчанию — начальные значения. Для Work с локальным доступом и dots поддерживаемая политика Global применяется через общий облачный оркестратор, если включена управляемая политика. Применимые локальные требования requirements.toml регулируют выполнение на подключённом компьютере. Облачные контейнеры Work и облачные компьютеры dots используют собственные конфигурацию выполнения и требования вместо управляемого пакета среды, используемого другими типами исполнителей. Локальные ограничения выполнения не распространяются на эти облачные компьютеры автоматически. Проверьте разрешения облачных возможностей и протестируйте локальное и облачное выполнение по отдельности.

Храните настройки оркестратора, включая подтверждения и веб-поиск, в Global. Где доступны отдельные элементы управления «Разрешённые политики подтверждения» и «Разрешённые режимы веб-поиска», используйте их, а для остальных поддерживаемых полей — TOML. Список полей и область их применения при выполнении приведены в справочнике по конфигурации.

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

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

Настройте общие требования с помощью элементов управления безопасностью агентов. Для политики, допускающей только подтверждения on-request и песочницы read-only или workspace-write, используйте Политики подтверждения и Режимы песочницы в разделе Ограничения политики. Чтобы также запрашивать подтверждение перед запуском поддерживаемой точки входа оболочки, используйте Редактировать как TOML, чтобы добавить таблицу [rules] в requirements.toml раздела Global.

Полный эквивалент в TOML:

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.

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

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

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

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

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

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

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

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

Развёртывание конфигурации, управляемой на уровне устройства

Используйте локальные системные требования или MDM для ограничений аутентификации и политик, управляемых на уровне устройства. Устаревший механизм managed_config.toml отличается от Значений по умолчанию в Agent security порядком приоритетов при запуске. Рабочий процесс MDM охватывает как требования, так и устаревшие значения по умолчанию.

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

Задайте 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 сервиса приведены в справочнике по требованиям .

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

Используйте значения по умолчанию в Agent security для поддерживаемых начальных значений, управляемых из облака. В этом разделе рассматривается устаревший механизм управления на уровне устройства managed_config.toml и его особый порядок приоритетов при запуске. Изменение Значений по умолчанию в Agent security не развёртывает файл managed_config.toml на устройствах участников.

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

Поддержка GPT-5.5 в Codex при входе через ChatGPT прекращается 14 октября 2026 года в полдень по тихоокеанскому летнему времени (19:00 UTC). Если управляемое значение по умолчанию, профиль macOS MDM или сохранённая конфигурация закрепляет gpt-5.5 для этих пользователей, замените её доступной моделью. Выберите gpt-6.1-sol после того, как администратор включит её для затронутых пользователей. OpenAI API и сеансы Codex с аутентификацией через API key это не затронет. См. доступность моделей в рабочем пространстве.

Для конфигураций, в которых всё ещё закреплена gpt-5.4 или gpt-5.4-mini, следуйте рекомендациям по переходу с GPT-5.4.

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

Приоритет и уровни

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

• Управляемые настройки (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

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

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

Управляемые настройки 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.