Codex в компании: как задать агентам правила до первого запуска

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

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

В документации OpenAI это место называется Managed configuration. По-русски я бы называл его управляемой конфигурацией Codex: способом заранее задать, какие режимы разрешены, какие значения включаются по умолчанию и какие границы пользователь не может ослабить сам.

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

Главная ошибка здесь звучит очень человечески: "сначала пусть люди попробуют, а потом разберемся с правилами". Для пилота это иногда нормально. Для массового внедрения — опасно.

Codex работает не только как чат. Он может запускаться в CLI, приложении, IDE, облачной среде, с разными режимами sandbox, approval policy, web search, hooks, MCP-серверами и доступом к файлам. Если каждый пользователь сам выбирает границы, компания получает не один инструмент, а десятки маленьких контуров риска.

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

Что OpenAI называет Managed configuration

В официальной документации Codex есть два разных слоя.

Первый слой — requirements. Это требования администратора, которые пользователь не может переопределить. Они ограничивают чувствительные настройки: approval policy, approvals reviewer, automatic review policy, sandbox mode, web search mode, managed hooks, а также список MCP-серверов, если компания хочет разрешить только проверенные подключения.

Второй слой — managed defaults. Это стартовые значения, которые применяются при запуске Codex. Пользователь может поменять их во время сессии, но при следующем запуске Codex снова применит управляемые defaults.

Разница принципиальная. Requirements — это забор. Managed defaults — это стартовая разметка. Забор нельзя сдвинуть руками пользователя. Разметку можно временно поменять, но система снова вернется к корпоративной норме на следующем старте.

Что компания дает на вход: не промпт, а policy-карту

Для такой статьи важно не перепутать уровень. Пользователь не дает Codex просьбу "будь осторожен". Компания дает администратору и владельцу процесса policy-карту.

В этой карте должны быть роли: кто работает в Codex, какие команды участвуют, есть ли подрядчики, есть ли CI или devbox, какие проекты чувствительные. Дальше — сценарии: ревью, правки, генерация сайтов, работа с локальными файлами, подключение MCP, поиск в интернете, запуск shell-команд, публикационные операции.

Затем идут границы. Например: danger-full-access запрещен для обычных пользователей; web search доступен только в cached-режиме или выключен; определенные MCP-серверы разрешены только по allowlist; чтение .env и ~/.ssh запрещено; hooks включены и не могут быть отключены локально; опасные команды требуют prompt или forbidden-решения.

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

Какой артефакт должен получиться

Хороший итог — не просто файл requirements.toml. Хороший итог — понятная карта управляемой конфигурации.

В ней видно, какие правила являются жесткими requirements. Например, разрешены только read-only и workspace-write, а полный доступ запрещен. Или approval policy должна оставаться в режиме, где рискованные действия требуют подтверждения.

Отдельно видно, какие значения являются defaults. Например, Codex стартует с определенной моделью, режимом, профилем или feature flags. Пользователь может временно изменить настройку, но компания не теряет базовый стандарт.

Еще один артефакт — карта групп. У внутренней команды может быть один набор требований, у подрядчиков другой, у CI третий. Документация OpenAI отдельно подчеркивает: если пользователь попадает в несколько групповых правил, применяется первое подходящее правило, и Codex не добирает недостающие поля из следующих правил. Это важно для администраторов, но для руководителя перевод простой: порядок policy имеет значение.

И наконец, нужна карта исключений. Иногда ноутбуки должны быть строже, а devbox или runner может иметь workspace-write. Для этого в документации есть host-specific sandbox requirements. Но это не доказательство личности устройства, а выбор policy по имени хоста, поэтому не стоит превращать его в единственный фактор доверия.

Как проверить правила без чтения TOML

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

Первый вопрос: что пользователь не может ослабить? Если обычный сотрудник может сам включить полный доступ, убрать approvals или открыть лишние MCP-серверы, это не requirements, а пожелание.

Второй вопрос: что возвращается при следующем запуске? Если пользователь временно поменял настройку в сессии, managed defaults должны снова вернуть стартовое значение при новом запуске Codex.

Третий вопрос: что происходит при конфликте? Документация говорит: если локальный config или CLI override конфликтует с enforced rule, Codex должен вернуться к совместимому значению и уведомить пользователя. Это хороший признак: система не молча игнорирует policy.

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

Пятый вопрос: какие данные вообще нельзя читать? Deny-read для чувствительных путей важен не меньше, чем запрет опасных команд. Если агент не должен видеть .env, SSH-ключи или другой секретный контур, это должно быть не устной просьбой, а enforceable requirement.

Где нужны жёсткие требования, а где достаточно defaults

Не каждую настройку нужно прибивать гвоздями. Если все сделать requirement, команда начнет обходить систему или перестанет получать пользу. Если все оставить default, policy будет слишком мягкой.

Жесткие requirements нужны там, где ошибка может привести к утечке, несанкционированному действию или нарушению внутренней политики. Это sandbox, approvals, deny-read, managed hooks, allowlist MCP-серверов, command rules и web search для чувствительных контуров.

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

Отдельно стоит смотреть на hooks и command rules. Managed hooks позволяют встроить проверку жизненного цикла, например перед использованием shell-команды. Command rules позволяют задать решения prompt или forbidden для опасных команд. Это уже не просто "пользователь должен помнить", а механический gate внутри работы Codex.

Мини-карта внедрения управляемой конфигурации

Начните не с TOML, а с списка сценариев. Где Codex будет использоваться: ревью, редактура, локальные проекты, внутренние сайты, CI, работа с документами, MCP, web search?

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

Определите жесткие requirements: sandbox, approvals, deny-read, web search, MCP allowlist, managed hooks, command rules.

Определите managed defaults: что должно включаться при старте, но может быть изменено внутри сессии без нарушения требований.

Разделите пользователей на группы. Не смешивайте внутреннюю команду, подрядчиков, администраторов и автоматические runner-ы в одну policy.

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

И только потом масштабируйте. Управляемая конфигурация нужна не для красивой галочки enterprise-ready. Она нужна, чтобы Codex можно было давать большему числу людей без надежды на то, что каждый сам идеально помнит границы.

Если governance отвечает на вопрос "что уже происходит с Codex в компании", managed configuration отвечает на вопрос "какие правила будут действовать еще до того, как это начнется". Вместе это и есть переход от эксперимента к управляемой рабочей системе.