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

Приоритет выстроен от разового к постоянному, и это логично. Выше всего - флаги CLI и разовые переопределения через -c key=value: они для эксперимента здесь и сейчас. Ниже - проектный .codex/config.toml, читаемый от корня репозитория к текущему каталогу. Ещё ниже - выбранный файл профиля, затем пользовательский config.toml, затем системный /etc/codex/config.toml на Unix, если он есть, и только в самом низу встроенные значения по умолчанию. Системный слой легко забыть, а он реален: настройка, которую вы не находите ни в проекте, ни у себя, может приходить именно оттуда. Более конкретный и более близкий к моменту слой перекрывает общий, поэтому одну и ту же настройку в разных слоях встречает разное решение.

Полезно один раз увидеть разовое переопределение и команды диагностики рядом. Ниже - codex -c с временным значением и команды /debug-config и /status в TUI. К этой форме возвращаются, когда поведение не совпадает с ожиданием: чаще всего дело не в "баге", а в том, что какой-то слой перекрыл ваш. Разовое -c удобно именно для эксперимента - проверить эффект настройки, не трогая постоянные файлы.

Managed requirements.toml стоит особняком и меняет саму логику стека. Это не просто ещё один слой значений по умолчанию: он может запрещать значения, которые нижние слои не имеют права расширить. Обычный слой можно перекрыть слоем выше; managed-требование - нельзя, в этом его смысл. Организация задаёт им обязательные границы, и попытка ослабить их проектным или пользовательским config не сработает - именно так и должна вести себя централизованная политика.

Полезно один раз свести приоритет слоёв в таблицу, чтобы не гадать, какой из них победит. Ниже - карта от CLI-флагов до встроенных значений. К ней возвращаются, разбирая, почему настройка не применилась: достаточно пройти по приоритету сверху вниз и найти слой, который её перекрыл. Понимание порядка превращает загадочное "не работает" в предсказуемое "перекрыто вот здесь", которое видно в /debug-config.