Команда Codex CLI /debug-config: диагностика конфигурации

Слеш-команда Codex CLI /debug-config применяется для вывода диагностических сведений об уровнях конфигурации и действующих требованиях политик. Она помогает понять, почему Codex CLI работает именно так: какой параметр был задан, откуда он получен, какое правило имеет приоритет и не ограничивает ли поведение инструмента одна из политик среды.

/debug-config показывает не просто настройки, а логику их применения. Это диагностический инструмент для поиска расхождений между ожидаемым и фактическим поведением Codex CLI.

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

Как использовать /debug-config

Вызов /debug-config выполняется непосредственно во время интерактивной сессии Codex CLI, если установленная версия поддерживает эту слеш-команду. После ввода команды инструмент выводит диагностическую информацию о конфигурации, доступной текущему запуску.

Главная задача команды — ответить на вопрос: «Почему сейчас действует именно это значение или ограничение?»

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

Действие	Что сделать	Что проверить
Открыть диагностику	Ввести /debug-config в интерактивной сессии	Появился ли диагностический блок
Найти источник параметра	Сопоставить значение с файлами, переменными и параметрами запуска	Какой уровень конфигурации оказался действующим
Проверить политику	Изучить сведения об ограничениях и требованиях среды	Не переопределяет ли политика локальную настройку
Сравнить окружения	Запустить команду в двух похожих средах	Где появляется различие

Важно не путать источник значения и итоговое значение. Например, пользователь мог задать параметр в локальном файле, но проектная конфигурация или политика организации могла изменить его действие. В таком случае простое чтение одного файла не объяснит поведение CLI, а /debug-config помогает увидеть картину целиком.

Какие сведения искать в результате

Не следует заранее ожидать конкретных названий полей: они могут зависеть от версии. Вместо этого ищите смысловые категории, связанные с происхождением настроек, приоритетами, применёнными правилами и ограничениями.

Категория сведений	Практический вопрос	Почему важна
Источник конфигурации	Где задан параметр?	Помогает найти файл или окружение, которые нужно изменить
Приоритет	Почему победило именно это значение?	Объясняет переопределение настроек
Политика	Есть ли обязательное ограничение?	Показывает, почему локальная настройка не сработала
Текущее применение	Какие правила действуют сейчас?	Связывает конфигурацию с поведением текущей сессии
Версионный контекст	Не относится ли различие к версии CLI?	Предотвращает ошибочные сравнения разных установок

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

Как подготовиться к проверке

Перед использованием команды стоит записать ожидаемое поведение. Например: «модель должна использовать такой-то режим», «сетевой доступ должен быть запрещён» или «проектная настройка должна переопределять пользовательскую». Чёткая формулировка превращает просмотр вывода из бесцельного чтения в проверку гипотезы.

• Зафиксируйте версию Codex CLI.
• Запишите команду запуска и важные аргументы.
• Отметьте, в каком каталоге находится рабочий проект.
• Проверьте, какие переменные окружения могут влиять на поведение.
• Не публикуйте секреты, токены и приватные пути вместе с диагностическим выводом.

Что собрать до диагностики	Пример	Риск при пропуске
Версию CLI	Версия из команды запуска или справки	Можно сравнить несовместимые форматы вывода
Рабочий каталог	Корень проекта или вложенная папка	Будет выбран другой проектный файл
Способ запуска	Локальный терминал, CI, контейнер	Не учитываются различия окружения
Ожидаемый результат	«Параметр должен быть разрешён»	Сложнее понять, что именно искать

Когда применять /debug-config

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

Диагностика особенно эффективна там, где несколько источников настроек могут спорить между собой.

Типичный случай — перенос проекта с ноутбука разработчика в CI или контейнер. На локальной машине может действовать пользовательская конфигурация, а в автоматизированной среде — проектная или организационная политика. Команда помогает определить, действительно ли проблема связана с параметром, или различие возникло из-за самого окружения.

Ситуация	Почему полезен /debug-config	Первый шаг
Настройка не применяется	Можно проверить источник и приоритет значения	Сравнить ожидаемый и фактический уровень конфигурации
Локально и в CI разное поведение	Помогает выявить различия окружений	Снять диагностику в обеих средах
После обновления изменилось поведение	Позволяет отделить версионное изменение от ошибки	Сравнить версии и конфигурационные контексты
Политика блокирует действие	Показывает наличие обязательного ограничения	Проверить применённые политики
Нужно подготовить отчёт	Даёт техническую основу для описания проблемы	Собрать минимальный безопасный фрагмент вывода

Когда команда не является первым выбором

Если нужно узнать только текущий статус сессии, начинать с /debug-config необязательно. Для этого обычно лучше подходит /status. Аналогично, вопрос о доступности экспериментальных возможностей относится к /experimental, а сообщение о проблеме — к /feedback.

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

Признак проблемы	Вероятное направление	Подходящая команда
Непонятно, какое состояние у сессии	Просмотр текущего состояния	/status
Нужно узнать о тестовой возможности	Экспериментальные функции	/experimental
Настройка переопределяется	Приоритеты и политики	/debug-config
Нужно отправить сведения разработчикам	Обратная связь	/feedback

Диагностика в команде и CI

В командной работе /debug-config удобно применять при сравнении одинаковых сценариев. Два человека могут запускать один и тот же проект, но получать разные результаты из-за пользовательских файлов, переменных окружения или централизованных требований.

Сравнивать нужно не только файлы конфигурации, но и контекст, в котором они загружаются.

В CI следует учитывать, что интерактивные слеш-команды могут быть недоступны в обычном неинтерактивном запуске. В таком случае диагностику проводят в аналогичной интерактивной среде, а в автоматизацию добавляют безопасную проверку релевантных параметров тем способом, который поддерживает конкретная версия CLI.

Среда	Особенность	Что сравнивать
Локальный терминал	Много пользовательских настроек	Профиль, каталог, переменные
CI runner	Ограниченное и очищенное окружение	Секреты, переменные, проектную конфигурацию
Контейнер	Другая файловая система и политика доступа	Монтирования, рабочую папку, права
Корпоративная среда	Возможны обязательные политики	Ограничения и источники их применения

Примеры использования /debug-config

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

Пример 1. Настройка проекта не вступила в силу

Разработчик добавил параметр в проектную конфигурацию, но Codex CLI продолжает работать по-старому. В такой ситуации сначала нужно определить, видит ли CLI проект, загружает ли его настройки и не перекрывает ли их более приоритетный источник.

Шаг 1. Перейти в корень проекта.
cd ~/projects/catalog

Шаг 2. В интерактивной сессии выполнить:
/debug-config

Шаг 3. Сравнить:
- ожидаемое значение из проектного файла;
- фактически применённое значение;
- источник, которому отдан приоритет.

Результат проверки: если проектная настройка обнаружена, но не стала действующей, искать нужно не в синтаксисе файла, а в более приоритетной конфигурации или политике.

Безопасная запись результата для задачи:
Ожидание: проектная настройка должна влиять на текущую сессию.
Наблюдение: значение не совпадает с ожиданием.
Проверено: рабочий каталог, версия CLI, источник действующего правила.
Секреты, токены и содержимое приватных переменных не прикладываются.

Проверка	Вопрос	Возможный вывод
Каталог	Запущена ли сессия в нужном проекте?	Файл проекта может не находиться
Источник	Загружена ли проектная настройка?	Нужно исправить путь или формат
Приоритет	Есть ли более сильное значение?	Нужно изменить верхний уровень

Пример 2. Локальный запуск отличается от CI

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

Локальная сессия:
Каталог: ~/projects/app
/debug-config
Зафиксировать только относящиеся к проблеме источники и ограничения.

CI или контейнер:
Каталог: /workspace/app
/debug-config
Сравнить не весь текст подряд, а:
- версию CLI;
- рабочий каталог;
- применённые уровни конфигурации;
- действующие ограничения.

Минимальная таблица сравнения:
Локально: ожидаемое поведение наблюдается.
CI: действие ограничено.
Гипотеза: в CI действует дополнительное обязательное правило.
Проверка: сравнить источники и политики в двух средах.
Не копировать в отчёт значения секретных переменных.

Различие	Что может его объяснить	Как проверить
Разная версия	Изменился набор команд или порядок правил	Сопоставить версии
Разный каталог	Загружается другой проектный файл	Проверить рабочую директорию
Разные переменные	Окружение задаёт иные значения	Сравнить наличие, не раскрывая секреты
Разные политики	CI работает в более ограниченном режиме	Изучить диагностические ограничения

Пример 3. После обновления изменилось поведение

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

До обновления:
Зафиксировать версию CLI и результат /debug-config.

После обновления:
Запустить ту же сессию в том же каталоге.
Выполнить /debug-config.
Сравнить:
- версию;
- доступные уровни конфигурации;
- применённые требования;
- итоговое поведение.

Цель: отделить изменение конфигурации от изменения самой версии.

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

Пример 4. Нужно понять влияние политики

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

Проверка:
1. Зафиксировать значение, которое задано пользователем.
2. Выполнить /debug-config.
3. Найти сведения о действующих требованиях и ограничениях.
4. Сопоставить их с фактическим поведением.

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

Пример безопасного вопроса администратору:
«В диагностике текущей сессии локальная настройка обнаруживается,
но итоговое поведение ограничено. Подскажите, какая политика имеет
приоритет и предусмотрен ли официальный способ изменить её?»

Такой вопрос содержит технические факты, но не раскрывает секреты.

Наблюдение	Вероятное объяснение	Корректное действие
Локальная настройка отсутствует	Файл не загружен или параметр задан неверно	Проверить путь и формат
Настройка есть, но не действует	Её переопределяет другой уровень	Определить приоритетный источник
Действует обязательное ограничение	Политика сильнее локальной настройки	Обратиться к владельцу политики
Поля отличаются после обновления	Изменился диагностический формат	Свериться с документацией версии

Пример 5. Подготовка технического отчёта

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

Структура отчёта:
Версия CLI: указать безопасно.
Среда: локальная машина, CI или контейнер.
Рабочий каталог: заменить приватные части на [PROJECT].
Команда: /debug-config.
Ожидание: кратко описать.
Факт: кратко описать.
Диагностически важно: источник, приоритет или ограничение.
Удалить токены, ключи, секреты и чувствительные пути.

Пример итогового описания:
В проекте [PROJECT] ожидалось применение проектной настройки.
Текущая сессия использует другое итоговое значение.
/debug-config показывает наличие нескольких уровней
конфигурации и приоритет более высокого источника.
Проблема воспроизводится после запуска из [SAFE_PATH].

Элемент отчёта	Нужен ли	Как обезопасить
Версия CLI	Да	Указать полностью
Ожидаемое поведение	Да	Описать своими словами
Фрагмент диагностики	Да, если релевантен	Удалить секретные значения
Полный вывод окружения	Обычно нет	Не прикладывать без необходимости
Скриншот терминала	По ситуации	Проверить видимые пути и токены

Чем /debug-config отличается от других команд

Служебные слеш-команды могут выглядеть похожими, потому что все они относятся к диагностике или управлению сессией. Однако у них разные задачи: /debug-config исследует приоритеты конфигурации, /status показывает состояние, /experimental связан с экспериментальными функциями, а /feedback предназначен для отправки отчёта или обратной связи.

Не всякая техническая проблема является проблемой конфигурации. Сначала определите тип вопроса, затем выбирайте команду.

Команда	Основное назначение	Когда выбирать	Чего не следует ожидать
/debug-config	Диагностика уровней конфигурации и политик	Нужно понять источник и приоритет настройки	Полного объяснения любой ошибки проекта
/status	Просмотр текущего состояния сессии	Нужно быстро узнать, в каком состоянии находится CLI	Подробного анализа происхождения каждой настройки
/experimental	Просмотр или управление экспериментальными возможностями	Нужно проверить тестовые функции	Диагностики всех приоритетов конфигурации
/feedback	Отправка обратной связи или отчёта	Нужно сообщить о проблеме разработчикам	Автоматического исправления локальной конфигурации

/status: просмотр состояния

Команда /status отвечает на вопрос «что происходит с текущей сессией сейчас». Это более оперативный просмотр состояния, тогда как /debug-config отвечает на вопрос «почему сессия получила именно такие настройки и ограничения».

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

Вопрос	Подходящая команда	Причина
Каково текущее состояние сессии?	/status	Это прямое назначение команды
Почему применилось именно такое значение?	/debug-config	Нужен анализ источников и приоритетов
Доступна ли тестовая функция?	/experimental	Вопрос относится к экспериментальному режиму
Как сообщить о проблеме?	/feedback	Нужен канал обратной связи

/experimental: экспериментальные функции

Команда /experimental связана с функциями, которые могут быть тестовыми, нестабильными или доступными не во всех установках. Она помогает работать с экспериментальными возможностями, но не предназначена для общего расследования приоритетов конфигурации.

Если экспериментальная функция не появляется или ведёт себя не так, как ожидалось, может потребоваться комбинация действий: сначала проверить её состояние через /experimental, затем выяснить ограничения и источники настроек через /debug-config. При этом нельзя предполагать, что наличие функции автоматически означает её разрешённость в текущем проекте или политике.

/feedback: отправка отчёта

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

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

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

Этап	Команда или действие	Цель
Определить состояние	/status	Понять контекст текущей сессии
Проверить экспериментальную возможность	/experimental	Уточнить доступность и режим функции
Исследовать конфигурацию	/debug-config	Найти источник, приоритет или политику
Передать результат	/feedback	Отправить безопасный технический отчёт

Как выбрать правильную команду

Проще всего начать с формулировки вопроса. Если в нём есть слова «почему», «откуда взялось значение», «что переопределяет настройку» или «какая политика ограничивает действие», нужен /debug-config. Если вопрос звучит как «что сейчас происходит», логичнее открыть /status.

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

Формулировка вопроса	Первый выбор	Следующий шаг при необходимости
«Почему параметр не применяется?»	/debug-config	Проверить файл, окружение и политику
«Каково состояние сессии?»	/status	Перейти к конфигурации, если состояние неожиданно
«Доступна ли экспериментальная возможность?»	/experimental	Проверить ограничения через /debug-config
«Как сообщить о воспроизводимой проблеме?»	/feedback	Приложить очищенный диагностический контекст

Таким образом, /debug-config — это инструмент расследования конфигурационных конфликтов. Он особенно полезен, когда Codex CLI получает настройки из нескольких уровней, работает в разных средах или подчиняется обязательным политикам. Используйте его вместе с /status, /experimental и /feedback по назначению, учитывайте различия версий и всегда очищайте диагностические материалы от секретов перед передачей другим людям.