Codex config задаёт настройки через несколько слоёв: CLI-переопределение имеет обычный приоритет над доверенным проектом, профилем и пользовательским файлом, а обязательные требования могут ограничить результат. Проверять значение нужно в текущем запуске: `/debug-config` показывает загруженные слои, `/status` — активную политику подтверждений. Для диагностики достаточно одного разрешённого параметра и сведений о доверии к проекту; читать реальные секреты или менять рабочий конфиг ради проверки незачем.
Карта уровней
Codex выбирает значение по приоритету: флаги CLI, конфиг доверенного проекта, выбранный профиль, пользовательский файл, управляемые и системные настройки, затем встроенный вариант. Обязательные требования организации могут ограничить этот выбор независимо от обычного порядка файлов.
Запрос «codex config» обычно возникает, когда изменение в одном файле словно исчезает после запуска. Причина часто в другом слое, который записал тот же ключ выше по приоритету. Пользовательский файл хранит личные значения по умолчанию; профиль добавляет набор для конкретного режима работы; проектный файл распространяет настройки внутри репозитория; флаг запуска меняет значение для текущего запуска. Разбирайте ситуацию по ключу и активному окружению, учитывая все загруженные файлы.
Официальная схема OpenAI добавляет ниже пользовательского уровня облачные настройки рабочего пространства, системный файл и встроенные значения. Управляемые требования стоят отдельно: они задают границы разрешённого поведения и могут отклонить даже параметр, указанный через CLI. Поэтому фраза «флаг всегда сильнее политики» ошибочна. Самый полезный первый шаг — назвать точный параметр, текущую рабочую папку, выбранный профиль и способ запуска, затем посмотреть загруженные слои.
Здесь рассматривается приоритет конфигурации вообще. Статья о MCP для Codex разбирает запись сервера в `config.toml`; порядок всех слоёв рассмотрен здесь. Для общей картины применения инструмента в команде пригодится обзор Codex в команде разработки. Проверку разрешений и проектного доверия проводите отдельно от обсуждения содержимого подключений: сами подключаемые сервисы здесь настраивать незачем.
Безопасный пример
Возьмём параметр `approval_policy` со значением `on-request`, которое означает запрос согласования перед действиями, требующими его по действующей политике. Такой параметр удобно читать через команду `/status`: официальный справочник указывает, что она показывает активную политику подтверждений. Пример в статье показывает порядок приоритета без изменений рабочих настроек. Доступность значения дополнительно зависит от требований организации.
| Уровень | Где искать | Что происходит с ключом |
|---|---|---|
| CLI | Флаг запуска либо `--config` | Перекрывает обычные файловые значения на текущий запуск |
| Проект | .codex/config.toml от корня до рабочей папки | Ближайший файл выигрывает только в доверенном проекте |
| Профиль | Выбранный файл профиля пользователя | Перекрывает базовый пользовательский файл |
| Пользователь | ~/.codex/config.toml | Задаёт личное значение по умолчанию |
| Нижние уровни | Управляемый, системный, встроенный | Работают при отсутствии значения выше |
Если базовый пользовательский файл содержит `approval_policy = "on-request"`, профиль может оставить ключ без записи: тогда наследуется базовое значение. Проект может явно задать тот же режим как общую договорённость команды. CLI позволяет указать его для одного запуска через поддерживаемый флаг или `--config`; итог для текущей сессии проверяют через `/status`. Совпадение значения на нескольких уровнях само по себе скрывает источник, поэтому `/debug-config` нужен для просмотра загруженных слоёв и их порядка.
Для наглядной проверки приоритета достаточно сравнить запуск из доверенного проекта с запуском вне его, оставив остальные параметры неизменными. Если проектный слой содержит ту же запись, показатель `/status` останется прежним, а `/debug-config` покажет отличие в наборе активных слоёв. Разницу в самом значении исследуйте только на разрешённых вариантах, предварительно согласовав тест с владельцем устройства. Так тест остаётся наблюдаемым без чтения секретов и правки боевой конфигурации.
Доверие проекта
Codex загружает `.codex/config.toml` проекта лишь после подтверждения доверия к проекту. Это существенная часть приоритета: файл рядом с кодом становится активным после подтверждения доверия. Если проект помечен как недоверенный, проектные настройки, локальные правила и хуки пропускаются; пользовательские и системные уровни остаются. При переходе в подкаталог доверенного проекта Codex учитывает проектные файлы от корня до текущей папки, а ближайший определяет конфликтующее значение.
- Уточните текущую рабочую папку и корень проекта, для которого проверяете настройку.
- Убедитесь, что владелец проекта разрешил доверять его содержимому; зафиксируйте решение без обхода запроса доверия.
- Сопоставьте выбранный профиль и пользовательский файл с проектными слоями через `/debug-config`.
- Проверьте активную политику подтверждений через `/status` и сравните её с ожидаемым значением.
- При расхождении проверьте флаг запуска и требования организации до правки файлов.
Доверие к проекту означает согласие учитывать проектный слой, поэтому его устанавливает владелец среды по принятому порядку. Сервер и политика рабочего пространства проверяют полномочия на разрешённые действия; текст конфигурации из репозитория сам по себе лишён права расширять доступ. Модель может помочь разобрать диагностический вывод, но спорное объяснение подтверждает ответственный человек по официальной документации и результату текущего запуска.
Некоторые параметры вообще нельзя перенести в проектный файл: официальный справочник относит к таким, например, ключи провайдера, уведомлений и телеметрии. Codex сообщает предупреждение, если встретит их в проектном слое. Поэтому наличие строки в файле требует проверки фактического применения. Содержимое персональных конфигов и учётных данных в отчёт проверки копировать незачем; достаточно имени ключа, источника слоя и наблюдаемого статуса.
Хотите разобрать приоритет настроек в вашей команде?
Проверка значения
Для чтения результата используйте два вида диагностики. `/debug-config` показывает слои в порядке приоритета, их активность и источники обязательных требований. `/status` показывает активную политику подтверждений и другие параметры сессии. Первая команда отвечает, откуда могло прийти значение; вторая показывает, что действует сейчас для выбранного проверочного ключа. Нельзя подменять вторую догадкой по файлу, особенно если запуск сопровождался флагами или изменением доверия.
Если клиент сообщает о неизвестном ключе, запускайте отдельную проверку с `--strict-config` в разрешённой тестовой среде: документация описывает этот флаг как способ считать неизвестные поля ошибкой. Перед запуском сверяйте синтаксис TOML и имя поля с актуальным справочником. Ориентируйтесь на официальное описание установленной версии клиента. Необходимость проверить версию особенно важна для профилей: официальный справочник описывает отдельный файл профиля и способ выбора через `--profile`.
Записывайте результаты компактно: проверяемый ключ, рабочая папка, наличие доверия, активный профиль, флаг запуска, список загруженных слоёв и значение из `/status`. Уберите из журнала пути к частным данным, строки аутентификации и содержимое других ключей. Если показатель расходится с ожиданием, меняйте в тесте только одно условие и повторяйте диагностику. Такой лист помогает объяснить поведение команды без копирования всего `config.toml`.
Для обучения команды работе с ИИ полезно дать одинаковую процедуру диагностики, чтобы участники сообщали наблюдаемый слой и значение. Ответственный администратор проверяет ограничения организации и утверждает изменение общего конфига. В статье про права и секреты ИИ-агентов отдельно разобрана граница доступа; здесь она важна только как условие применения настройки.
Приёмка настройки
Приёмка начинается с ожидаемого результата для выбранного ключа и явного списка слоёв. Укажите, кто владеет пользовательским значением, кто утверждает проектный файл и кто имеет право задавать флаги запуска. Затем проверьте разрешённый тестовый запуск: `/debug-config` показывает активный проектный слой, а `/status` показывает ожидаемую политику подтверждений. Повторите просмотр вне проекта и с выбранным профилем, чтобы увидеть, какие уровни действительно участвуют.
Зафиксируйте исключения. Проект без доверия теряет проектный слой; неизвестный ключ обнаруживается строгой проверкой; параметр, запрещённый в проектной конфигурации, сопровождается предупреждением; управляемое требование может ограничить даже самый высокий обычный слой. Каждое исключение требует отдельного решения владельца среды. Расхождение разбирайте без повышения полномочий и обхода политики: цель проверки — объяснить эффективное значение и выбрать допустимое место для настройки.
Назовите один ключ и ожидаемое значение для разрешённого тестового запуска. Сверьте порядок слоёв через `/debug-config`, а активный результат через `/status`. Только после этого меняйте согласованный файл или флаг.
Готовность подтверждается, когда другой участник команды может повторить диагностику без доступа к чужим секретам и получить ту же цепочку объяснения. В журнале остаются источник значения, ограничения политики и ответственный за спорный вывод. Если активное значение осталось непонятным, обозначьте вывод как предположение и запросите у администратора сведения об управляемых требованиях. При обновлении Codex перепроверяйте команды и допустимые поля по официальной документации, поскольку детали продукта могут меняться.