Администрирование: роли и управляемая конфигурация

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

Сначала — владельцы

Гайд OpenAI по развёртыванию начинает не с настроек, а с назначения владельцев для каждой границы (admin setup): доступ к рабочему пространству, политика локального исполнения, облако Codex, подключённые системы (Git-хостинг, трекер), отчётность и compliance. В агентстве на 75 человек это могут быть два-три человека, но каждая граница должна иметь имя. Иначе политика песочницы окажется ничьей, и её никто не обновит, когда выйдет новая версия клиента.

Роли и права

По документации на октябрь 2026 года (roles and permissions):

• Встроенные роли: Owner, Admin, Member, Analytics Viewer, плюс пользовательские роли (custom roles).
• Настраивать ролевую модель (RBAC) и создавать пользовательские роли может только Owner. Analytics Viewer видит аналитику рабочего пространства.
• Роли назначаются через группы — вручную или синхронизацией по SCIM. У участника может быть несколько ролей.
• Каждое право в роли — «по умолчанию», «вкл» или «выкл». Права складываются: «выкл» в одной роли не отменяет «вкл» в другой. Поэтому запрещать что-то ролями неудобно — проще не выдавать.

Права, относящиеся к Codex: Use Codex in the cloud и вложенное в него Manage workspace environments (создание и правка общих облачных окружений, по умолчанию выключено). Облако Codex в Enterprise по умолчанию выключено. Локальное использование включается отдельным переключателем — в зависимости от рабочего пространства это общий «Codex and Work Locally» или раздельные настройки для Codex и Work.

Важная граница: доступ к Codex не переопределяет права в репозитории. Если у человека нет доступа к проекту в Git, роль в ChatGPT его не даст.

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

Страница managed configuration описывает три слоя:

• Требования (requirements.toml) — то, что навязывает админ. Если настройка пользователя конфликтует, клиент откатывается на совместимое значение и сообщает об этом. Ключи, которых нет в требованиях, ничем не ограничены.
• Значения по умолчанию (config.toml) — стартовые настройки, которые пользователь может менять в рамках требований.
• Устаревшие управляемые значения (managed_config.toml) — применяются при запуске клиента; пользователь может поменять их на время сеанса, при следующем запуске они вернутся.

Для новых развёртываний ориентируйтесь на требования и значения по умолчанию, а managed_config.toml считайте наследием.

Где задаётся политика

В облаке — Agent Security в консоли администратора. Там визуальный редактор и режим «Edit as TOML» для той же политики. Политика может быть базовой для всего рабочего пространства или переопределять настройки для пользователей, групп и ролей. Внутри политики есть область Global (одобрения, веб-поиск, MCP, плагины, правила команд, хуки) и переопределения для Local и Codex Cloud, которые меняют только настройки исполнения: песочницу, права на файловую систему, сеть (agent security). Глобальными настройками можно управлять через policy API, удобный для Terraform; локальные и облачные — в интерфейсе.

На устройстве — системный файл /etc/codex/requirements.toml (Linux и macOS) или %ProgramData%\OpenAI\Codex\requirements.toml (Windows), а на macOS ещё и MDM-профиль с доменом com.openai.codex и ключом requirements_toml_base64. Ограничения входа (allowed_login_methods, allowed_chatgpt_workspaces) работают только отсюда, облачная политика их игнорирует.

Порядок применения требований для локального исполнения, от низшего к высшему: системный файл, затем облачная политика Agent Security, затем поля устаревшего managed_config.toml, затем MDM на macOS. Правила запрета при этом остаются сильнее разрешений из другого источника.

Стартовая политика агентства

Пример базовых требований. Ключи — по документации на октябрь 2026 года; перед развёртыванием сверьте имена со справочником requirements.toml.

# Права: только чтение или запись в рабочую папку, без полного доступа
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# 3 не указан — значит, запрещён

# Одобрения: агент спрашивает, когда нужно выйти за границы
allowed_approval_policies = ["on-request"]

# Веб-поиск только из кэша, без живых страниц
allowed_web_search_modes = ["cached"]

# Секреты клиентов агент не читает
[permissions.filesystem]
deny_read = ["/**/*.env", "~/.ssh"]

# Опасные команды — только с подтверждением или никогда
[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Пуш только после просмотра человеком." },
]

# Разрешённые MCP-серверы; пустая таблица отключила бы все
[mcp_servers.docs]
identity = { url = "https://mcp.example.com/mcp" }

Что важно знать про этот пример:

• Профили прав (allowed_permission_profiles, default_permissions) требуют Codex 0.138.0 и новее; старые клиенты их игнорируют. Для устаревших развёртываний есть allowed_sandbox_modes. Не раскатывайте политику, пока весь парк не обновился.
• deny_read блокирует чтение по маскам; при его наличии клиент отклоняет полный доступ. На нативном Windows правило действует для файловых инструментов агента, но не для чтения из shell-подпроцессов.
• Правила команд в требованиях могут быть только "prompt" или "forbidden" — разрешать через них нельзя. Они объединяются с обычными файлами .rules, и побеждает самое строгое решение.
• MCP-список сверяет сервер по identity.command или identity.url. Пустая таблица mcp_servers отключает все серверы.

Сетевые ограничения ([experimental_network]) документация помечает как экспериментальные и предупреждает об ограниченной поддержке Windows — сначала тестируйте на пилотной группе. Подробно про сеть и песочницу — в уроке про модель безопасности.

Чего конфигурация не делает

• Не выдаёт доступ к рабочему пространству и не заменяет роли.
• Конфигурация в репозитории (.codex, .agents) не может выдать доступ к рабочему пространству, моделям или подключённым системам — только сузить поведение.
• Не даёт полного аудита локальных действий: для этого нужны Compliance API и телеметрия (см. урок про инциденты).

Командные стандарты поверх политики — общий AGENTS.md, навыки, конфигурация проекта — тема урока «Командные стандарты» в курсе для тимлидов.