Есть особый сорт проблем, не похожий на ошибку. Ничего не падает, стектрейса нет, Claude Code работает — просто не так, как вы настроили. Хук не срабатывает. Скилл не появляется в списке. Правило разрешений из проектных настроек будто не действует, и подтверждение всё равно спрашивают.

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

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

Что уже умеем / что добавим

Вы настраивали разрешения, память проекта, скиллы, подагентов, хуки, MCP и плагины. Каждый из этих слоёв вы умеете описывать. Теперь научимся его проверять: разберём claude doctor и /doctor, команду /permissions, набор команд для осмотра сессии и флаг --debug на случай, когда команд оказалось недостаточно.

Что вы узнаете в рамках статьи

• Чем claude doctor из терминала отличается от /doctor внутри сессии
• Что показывает /permissions и как редактировать правила прямо из диалога
• Какие команды показывают загруженные скиллы, хуки, MCP-серверы и источники настроек
• Как флаг -debug помогает поймать проблему, которую не видно в интерфейсе
• Как проверить гипотезу запуском на чистой конфигурации

Ключевые термины

• claude doctor — команда терминала, печатающая диагностику установки и настроек без запуска сессии.
• /doctor — команда внутри сессии: проверка окружения с предложением исправлений, которые применяются после вашего подтверждения.
• /permissions — диалог со всеми действующими правилами разрешений и указанием файла, откуда пришло каждое.
• /status — команда, показывающая активные источники настроек, включая управляемые организацией.
• -debug — флаг запуска, включающий подробный журнал в ~/.claude/debug/<session-id>.txt.
• -safe-mode — запуск сессии с отключёнными пользовательскими настройками для проверки, что причина в них.

Два разных doctor: в терминале и в сессии

Названия почти совпадают, поэтому разницу легко пропустить. А она принципиальная.

claude doctor запускается из обычной оболочки, без слеша и без запуска сессии:

claude doctor

Команда печатает диагностику установки и настроек в режиме «только чтение»: состояние установки, найденные невалидные файлы настроек, строку Search с путём к используемому ripgrep. Она ничего не меняет и ни о чём не спрашивает.

Ключевая особенность — ей не нужна рабочая сессия. Поэтому это ваш инструмент, когда claude вообще не стартует или падает на запуске: сессии нет, слеш-команду набрать негде, а диагностика нужна.

/doctor набирается внутри уже работающей сессии:

/doctor

Это более полная проверка, и главное — она предлагает исправления и применяет их после вашего подтверждения. Кроме состояния установки и невалидных файлов настроек, /doctor находит:

• неиспользуемые расширения;
• дублирующиеся имена подагентов в одном каталоге;
• содержимое CLAUDE.md, закоммиченное в репозиторий, которое Claude и так может вывести из кодовой базы.

Практическое правило простое: если Claude Code запускается — начинайте с /doctor, он даёт больше и умеет чинить. Если не запускается — claude doctor из терминала.

/permissions: какие правила действуют на самом деле

Правила разрешений живут в нескольких файлах сразу, и держать их итоговую сумму в голове невозможно. /permissions показывает её готовой:

/permissions

Диалог перечисляет все правила разрешений и — это самое ценное — файл settings.json, из которого пришло каждое правило. Именно эта колонка обычно и объясняет загадку: правило, которое вы «точно не писали», приехало из проектных или управляемых настроек.

Правила бывают трёх типов: allow разрешает использовать инструмент без подтверждения, ask спрашивает каждый раз, deny запрещает. Порядок вычисления фиксированный: сначала deny, затем ask, затем allow. Первое совпадение в этом порядке определяет исход, и конкретность правила порядок не меняет.

Отсюда следует неочевидное поведение, на котором спотыкаются регулярно. Вы ответили на запрос «Да, и больше не спрашивать» — Claude Code сохранил allow-правило в ваш локальный файл. А вопросы продолжают приходить, потому что в проектных или управляемых настройках есть подходящее ask-правило: ask вычисляется раньше allow и побеждает независимо от того, насколько ваше allow-правило конкретнее.

Диалог не только показывает, но и редактирует: правила можно добавлять и удалять прямо в нём. Причём открыть /permissions можно пока Claude работает — изменение вступит в силу со следующего вызова инструмента в этом же ходе. Если сессии доступен auto-режим, в диалоге появляется отдельная вкладка Auto mode с правилами классификатора.

Набор команд, показывающих загруженное

/doctor и /permissions — не весь арсенал. Начинать осмотр стоит с /context: она показывает всё, что занимает контекстное окно, — системный промпт, инструменты, MCP-инструменты, подагентов с указанием источника, файлы памяти, скиллы. Подробно с ней мы работали в уроке 3.2; здесь она важна как первый шаг: если вашего файла нет в разбивке /context, он просто не загрузился, и дальше надо разбираться с расположением файла, а не с формулировками внутри.

Дальше идут точечные команды:

/status заслуживает отдельного внимания. Когда ваше значение настройки упорно игнорируется, а в своих файлах вы всё перепроверили, именно /status покажет, что поверх лежат управляемые настройки организации — их не перебить ничем.

Когда команд мало: -debug и чистая конфигурация

Бывает, что /hooks показывает хук, а он не срабатывает. Интерфейс тут больше ничего не расскажет — нужен журнал:

claude --debug

Запустите сессию с этим флагом и вызовите нужное действие. Журнал запишет каждое событие, какие матчеры проверялись, а также код возврата и вывод хука. Для MCP есть узкая форма — claude --debug=mcp; она пишет в журнал ~/.claude/debug/<session-id>.txt поток stderr сервера, что незаменимо, когда сервер подключился, но не отдаёт ни одного инструмента.

Второй приём — не искать причину, а сузить область поиска. Запуск с --safe-mode поднимает сессию с отключёнными настройками: без CLAUDE.md, скиллов, плагинов, хуков, MCP-серверов и пользовательских команд. Аутентификация, выбор модели, встроенные инструменты и разрешения работают как обычно.

claude --safe-mode

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

Частые ошибки

• Перечитывать свои файлы вместо проверки загруженного. Ваши файлы показывают намерение, диагностические команды — результат. Начинайте с /context и /permissions, а не с редактора.
• Путать claude doctor и /doctor. Первый — только чтение, без сессии, для случая «не запускается». Второй — полная проверка внутри сессии, предлагающая исправления. Это не синонимы.
• Считать, что более конкретное allow-правило перебьёт ask. Порядок вычисления — deny, ask, allow, и конкретность его не меняет. Ищите ask-правило в /permissions и смотрите, из какого файла оно пришло.
• Не проверять /status при «игнорируемой» настройке. Если организация раскатывает управляемые настройки, ваше значение не применится ни из какого файла, и никакая правка это не исправит.

Наиболее частые вопросы

• Чем /doctor отличается от claude doctor? — claude doctor печатает диагностику установки и настроек без запуска сессии, только чтение. /doctor — полная проверка внутри сессии, которая предлагает исправления и применяет их после подтверждения.
• Что делать, если claude вообще не запускается? — Запустить claude doctor из терминала: ему сессия не нужна, и он покажет проблемы установки и невалидные файлы настроек.
• Как узнать, откуда взялось правило разрешений? — Открыть /permissions: диалог показывает каждое правило вместе с файлом настроек, из которого оно пришло.
• Можно ли открыть /permissions, пока Claude работает? — Да. Добавленное или удалённое правило начнёт действовать со следующего вызова инструмента в этом же ходе.
• Куда пишется журнал -debug? — В файл ~/.claude/debug/<session-id>.txt. Там видно события, проверенные матчеры и коды возврата хуков.

Итоги

Отличная работа. Вы освоили навык, который отличает уверенного пользователя от догадывающегося: смотреть не на свои файлы, а на фактическое состояние сессии. Вы знаете, чем claude doctor отличается от /doctor и когда нужен каждый, читаете /permissions вместе с колонкой источника, помните порядок deny-ask-allow и умеете разворачивать диагностику через --debug и --safe-mode.

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