settings.json: конфигурация уровня пользователя / проекта

📚 Навигация по серии: Предыдущая статья 30 Как выбрать функцию: CLAUDE.md vs Skill vs Hook vs MCP vs Subagent научила вас «выбирать подходящую точку расширения под вашу задачу». В этой статье мы копнем глубже — в какой файл записывать переключатели для этих точек расширения и какой уровень имеет приоритет: пользователя или проекта. settings.json — это главный распределительный щит Claude Code, и сегодня мы раз и навсегда разберемся в правилах его подключения.

Здесь кроется досадная ошибка, наступив на которую один раз, вы ее больше не забудете.

Когда я только начал серьезно использовать Claude Code, частой практикой было добавить строку defaultMode: "auto" в .claude/settings.json какого-нибудь проекта, чтобы он автоматически пропускал действия при входе и перестал задавать вопросы. Изменил — ноль реакции. Первой мыслью было, что я неправильно написал имя поля; я трижды проверил его по официальной документации — ни одной ошибки в букве. Затем я заподозрил, что сломан формат JSON, прогнал его через онлайн-валидатор — все абсолютно корректно. Потратив около двадцати минут, я даже начал сомневаться, нет ли бага в этой версии Claude Code.

Только потом я наткнулся на фразу в углу документации: если defaultMode установлен на "auto", эта настройка будет проигнорирована, если она прописана в настройках проекта — это официальное ограничение, чтобы не дать какому-либо репозиторию тайно включить автоматический режим (об этом упоминалось в статье 20). Синтаксис был правильным, файл цел, проблема была исключительно в неверно выбранном «уровне». Стоило перенести настройку в пользовательский ~/.claude/settings.json, как она заработала мгновенно.

Рассказываю я об этой проблеме для того, чтобы вы усвоили одну вещь: в 90% случаев проблемы с settings.json кроются не в том, «как писать», а в том, «на каком уровне писать и какой уровень имеет приоритет над каким». Сегодня мы разберем эти «правила этажей» до мелочей, чтобы в следующий раз при настройке вы точно знали — должна ли эта строка быть в домашнем каталоге или в проекте.

Прочитав эту статью, вы узнаете:

• В одной фразе: что такое settings.json и как именно распределяются обязанности между ним и CLAUDE.md.
• Три уровня (пользовательский / уровень проекта / локальный): где находятся файлы, на кого они влияют и что в них следует помещать.
• Таблицу приоритетов «кто кого перекрывает», а также одно самое неочевидное исключение (массивы объединяются, а не перезаписываются).
• Для чего нужны и на каком уровне размещать настройки, которые вы будете менять чаще всего (model, permissions, env, hooks, statusLine).
• Практическое задание, которое можно выполнить по шагам: написание конфигурации → использование /status для проверки ее работоспособности.

---

01 Сначала разберемся: что такое settings.json и в чем его отличие от CLAUDE.md

Сразу к сути: settings.json — это «главный рубильник поведения» Claude Code; через JSON он управляет разрешениями, переменными окружения, моделью по умолчанию, хуками (Hook) и строкой состояния. Он и CLAUDE.md — это совершенно разные вещи: один определяет «как работать», а другой — «что нужно помнить».

Многие поначалу их путают. Раньше вы писали CLAUDE.md (статья 18), настраивали правила разрешений (статья 20), а в будущем будете настраивать Hook — все это в конечном итоге оседает в файле settings.json, но содержимое, которое он хранит, полностью отличается от CLAUDE.md.

Аналогия: проектный шкаф компании vs электрический щиток у вашего рабочего места. CLAUDE.md подобен «Руководству по проекту» в шкафу — в нем написано «мы используем pnpm, а не npm», «прогоняйте тесты перед коммитом» и тому подобные написанные естественным языком правила для людей (и для Claude), которые считываются как контекст в каждом сеансе. settings.json устроен иначе — это тот самый электрический щиток на стене: внутри находятся конкретные переключатели — разрешен ли этот инструмент, какая модель используется по умолчанию, какой скрипт автоматически запускать после изменения файла. Шкаф содержит «правила, которые ему объяснили», а щиток — «жестко заданное поведение машины».

Официально его позиционирование описано очень четко:

Файл settings.json — это официальный механизм настройки Claude Code через иерархические уровни конфигурации.

Обратите внимание на термины «официальный механизм» и «иерархические уровни» — это две главные темы нашей статьи: это правильная точка входа для настройки Claude Code (вместо временного ввода параметров в командной строке), и эти настройки накладываются в несколько уровней (пользовательский, проектный, локальный).

В реальных сценариях, с которыми вы столкнетесь, settings.json управляет следующими вещами:

• «В этом проекте команды типа rm -rf должны быть заблокированы» — запись в permissions.deny
• «Для этого проекта по умолчанию используйте Sonnet, не тратьте лимит на Opus» — запись в model
• «Каждый раз, когда он изменяет файл, автоматически запускайте форматирование» — запись в hooks
• «Я хочу, чтобы в строке состояния внизу терминала отображалась текущая ветка git» — запись в statusLine

Это не «слова, обращенные к Claude», а реальные переключатели, изменяющие его рабочее поведение. В этом и заключается фундаментальное различие между settings.json и CLAUDE.md.

💡 Вкратце: CLAUDE.md — это «правила на естественном языке, объясненные Claude», а settings.json — это «сборник переключателей, жестко задающих его машинное поведение». Первый управляет тем, что он запоминает, второй — тем, как он работает. Не путайте их.

---

02 Три уровня: домашний каталог, внутри проекта или только на вашем компьютере

Первое, что нужно понять о settings.json — это не доступные поля, а тот факт, что он имеет три уровня. Одно и то же имя файла, помещенное в три разных места, имеет кардинально разную область действия. Ошибка, описанная в начале, произошла именно из-за непонимания уровней.

Аналогия: три места для размещения объявлений. Одно и то же объявление «Не забудьте выключить кондиционер после работы» может быть повешено на главном входе в компанию (видят все проекты), на двери этого конкретного кабинета (видят только люди из этого проекта, и это зафиксировано в правилах кабинета) или на стикере у вашего монитора (видите только вы). Область действия совершенно разная. Три уровня settings.json работают точно так же.

В официальной документации определены три уровня, представленные в таблице ниже (плюс высший уровень Managed, используемый только корпоративными IT-отделами; мы, обычные пользователи, с ним практически не сталкиваемся, поэтому упомянем его в следующем разделе лишь вскользь):

Уровень	Расположение файла	На кого влияет	Входит ли в git	Что следует помещать
Пользовательский (User)	~/.claude/settings.json	На вас, во всех ваших проектах	Нет (в домашнем каталоге)	Личные предпочтения: привычная модель, тема, инструменты для всех проектов
Проектный (Project)	.claude/settings.json	На всех соавторов этого репозитория	Да (фиксируется в git)	Командные правила: разрешения, Hook, общие MCP
Локальный (Local)	.claude/settings.local.json	На вас, только в этом репозитории	Нет (автоматически игнорируется gitignored)	Личные переопределения, экспериментальные настройки с учетными данными

Чтобы сделать выбор между тремя уровнями, достаточно запомнить три фразы:

• «Я хочу это во всех своих проектах» → Пользовательский уровень (~/.claude/settings.json). Например, «Я привык использовать Sonnet по умолчанию» или «Мой скрипт строки состояния». Настройте один раз, и это будет работать в любом открытом проекте.
• «Это нужно всей команде и должно быть привязано к репозиторию» → Проектный уровень (.claude/settings.json). Этот файл отправляется в git, чтобы члены команды получали те же настройки. Это и есть «конфигурация как код».
• «Только для меня, только для этого проекта и не должно попадать в контроль версий» → Локальный уровень (.claude/settings.local.json).

Здесь есть одна очень продуманная деталь, официально заявленная: когда вы создаете .claude/settings.local.json, Claude Code автоматически настраивает git так, чтобы игнорировать этот файл.

Claude Code автоматически настроит git игнорировать .claude/settings.local.json при его создании.

Зачем это сделано? Подумайте сами: локальный уровень предназначен для «личных вещей» — ваших личных экспериментальных конфигураций или данных с учетными данными. Всему этому изначально не место в репозитории версий, где они могут создать проблемы коллегам. Разработчики официально заварили этот люк, чтобы вы случайно не отправили личные настройки через git add .. Это также перекликается с темой безопасности из статьи 21: не дайте чувствительным данным ни малейшего шанса попасть в git.

Как это выглядит на практике: распределение по трем уровням в реальном проекте

Запоминать определения недостаточно. Посмотрите, что лежит на каждом из трех уровней в реальном проекте, и вы сразу все поймете:

• Пользовательский уровень (~/.claude/settings.json): Пользовательский скрипт строки состояния, предпочтения модели по умолчанию. Они не зависят от конкретного проекта и представляют собой личные привычки, которые «всегда с вами».
• Проектный уровень (.claude/settings.json): Набор permissions.deny (запрет curl, запрет чтения .env), хук «автоматический lint перед коммитом». Это ограничительные линии для всей команды, которые должны быть в git, чтобы они были у каждого участника.
• Локальный уровень (.claude/settings.local.json): Несколько команд, временно разрешенных лично для вас (команде не нужно о них знать), экспериментальный хук, который еще не готов к тому, чтобы делиться им.

Чтобы определить, на каком уровне должна находиться настройка, достаточно пройти мысленную цепочку: «Эта настройка нужна только мне → Пользовательский или Локальный уровень; нужна всей команде → Проектный уровень». Затем уточняем: «Универсальная для всех проектов и должна быть со мной → Пользовательский уровень; только для этого проекта и без git → Локальный уровень».

Распространенная ошибка (из-за лени) — сваливать правила доступа, специфичные для проекта, на пользовательский уровень. В результате, при переходе в другой проект, все эти правила переходят вместе с вами, создавая непонятную кучу разрешений там, где они не нужны. Отсюда правило номер один: «Эта настройка должна следовать за мной или за проектом?» — вот главный критерий разделения. То, что следует за проектом, кладите в проект.

💡 Вкратце: Различия в одном предложении — глобальные для всех проектов настройки идут в пользовательский ~/.claude/settings.json, общие для команды — в проектный .claude/settings.json (в git), личные переопределения — в локальный .claude/settings.local.json (автоматически игнорируется git); правило выбора: «следует за мной или следует за проектом».

---

03 Кто кого: приоритеты и одно самое неочевидное исключение

Все три уровня могут содержать одни и те же поля. Возникает вопрос: если пользовательский уровень требует Opus, а проектный уровень — Sonnet, кого слушать? В этом и заключается суть «приоритета (precedence)», и именно это чаще всего путает людей в settings.json.

Сначала приведем официальный порядок приоритетов, от высшего к низшему (высшие перекрывают низшие):

Приоритет	Уровень	Простыми словами
1 (Высший)	Managed (Корпоративное развертывание)	Заблокированные политики компании, которые никто не может изменить
2	Аргументы командной строки (--settings и т.д.)	Временные параметры при запуске, действуют только для текущего сеанса
3	Локальный уровень .claude/settings.local.json	Ваши личные переопределения для этого проекта
4	Проектный уровень .claude/settings.json	Общие настройки проекта для команды
5 (Низший)	Пользовательский уровень ~/.claude/settings.json	Ваши глобальные настройки по умолчанию, работают, когда никто их не перекрывает

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

Сверху вниз на этой схеме — приоритет от высшего к низшему: верхние слои перекрывают нижние (только для одиночных значений). Другими словами, чем «выше» уровень, тем он более «временный и конкретный», а чем «ниже» — тем более «глобальный и базовый». Только когда ни один из верхних уровней не касается определенного поля, в силу вступает базовое значение пользовательского уровня на самом дне.

Запомните это правило одной фразой: чем более «конкретно к текущему моменту», тем выше приоритет; чем более «глобально», тем ниже. Параметры командной строки (только для этого раза) переопределяют локальные (только этот проект, только вы), локальные переопределяют проектные (для всей команды), а проектные переопределяют пользовательские (глобальные). Официальный пример очень нагляден:

Например, если ваши пользовательские настройки разрешают Bash(npm run *), но общие настройки проекта запрещают это, то настройки проекта имеют приоритет, и команда блокируется.

Это означает, что зеленый свет, который вы дали себе в домашнем каталоге, может быть заблокирован настройками проекта, когда вы в него зайдете. Это как раз и подтверждает интригу, оставленную в конце прошлой статьи: одна и та же конфигурация, написанная в домашнем каталоге и в проекте, может иметь совершенно противоположный эффект. Ошибка с defaultMode: "auto" из начала статьи по сути и была вызвана непониманием этой семантики иерархии.

Уровень Managed можно описать одним предложением. Это политики, централизованно внедряемые корпоративным IT-отделом через MDM, реестр или сервер. Они имеют наивысший приоритет и не могут быть переопределены пользователями или проектами. Они нужны компаниям для принудительного обеспечения безопасности (например, «глобальный запрет на curl»). Если вы работаете в одиночку или в небольшой команде, вы с ним вряд ли столкнетесь — достаточно знать, что существует такой «непреодолимый» уровень. Если вы окажетесь в корпоративной среде с жестким контролем, тогда загляните на официальную страницу server-managed-settings.

То самое неочевидное исключение: массивы «объединяются», а не «перезаписываются»

Вышеописанное правило «кто кого» применимо к одиночным значениям (например, model, где вы пишете одно значение, я другое, и побеждает верхний уровень). Но есть тип конфигурации, который работает совершенно иначе, и новички почти всегда на нем спотыкаются — настройки-массивы (например, permissions.allow / deny) «объединяются» (merge) между уровнями, а не перекрываются (override).

Что это значит? Посмотрим официальную цитату:

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

Простым языком: ваши правила доступа не будут «полностью заменены» настройками проекта, правила с обеих сторон будут «сложены вместе» и вступят в силу совместно.

Пример для понимания:

Сценарий	Интуиция (неверная)	Фактически (верно)
Пользовательский уровень: allow: ["Bash(npm run *)"], Проектный уровень: allow: ["Bash(git diff *)"]	Приоритет у проекта выше, поэтому останется только git diff	Работают оба: разрешены и npm run *, и git diff *

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

• Поля с одним значением (например, model, defaultMode): Уровень с высоким приоритетом полностью перекрывает нижний.
• Поля-массивы (например, permissions.allow / deny, а переменные env объединяются аналогичным образом): Уровни складываются и избавляются от дубликатов, никто никого не стирает.

Об этот момент легко споткнуться: вы можете подумать, что, прописав группу deny на уровне проекта, вы отменили более свободные правила allow на пользовательском уровне. А потом обнаружите, что пользовательские правила allow все еще работают — потому что они объединяются, а не заменяются. Поняв это правило, вы больше не будете думать, что «закрыли какую-то лазейку, хотя на самом деле она открыта на другом уровне».

💡 Вкратце: Формула приоритета — «чем конкретнее к текущему моменту, тем выше» (Командная строка > Локальный > Проектный > Пользовательский, Managed на самом верху); но настройки-массивы (особенно правила доступа) объединяются между уровнями с удалением дублей, а не перекрываются — это самый частый неочевидный подводный камень.

---

04 Самые часто используемые настройки: куда их помещать и для чего они нужны

С уровнями и приоритетами разобрались. Теперь рассмотрим поля, которые вы реально будете менять чаще всего. Официальный settings.json поддерживает более сотни ключей, но 90% людей в повседневной жизни сталкиваются лишь с немногими из них. Я выделю их и объясню, «для чего они нужны и на каком уровне их лучше размещать».

Сначала приведу краткий, но полный пример, чтобы вы получили общее представление о том, как это выглядит (это урезанная версия официального примера):

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "claude-sonnet-4-6",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)", "Read(./.env)"]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1"
  }
}

Строку $schema в начале я настоятельно рекомендую добавить. Она указывает на официальную схему JSON, и после ее добавления в редакторах вроде VS Code или Cursor при написании конфигурации появится автодополнение и проверка в реальном времени — если вы ошиблись в имени поля или типе значения, редактор тут же подсветит это красным. Те двадцать минут, что я потратил в самом начале, сверяя названия полей с документацией — если бы я сразу добавил эту строку $schema, редактор бы все подсказал. Официальная формулировка:

Добавление ее в ваш settings.json включает автозавершение и встроенную проверку (инлайн-валидацию) в VS Code, Cursor и любом другом редакторе, поддерживающем валидацию схемы JSON.

Ниже мы подробно разберем эти часто используемые поля:

model: какую модель использовать по умолчанию

model определяет, какая модель запускается по умолчанию на данном уровне. В качестве значения указывается идентификатор модели (например, "claude-sonnet-4-6").

• На какой уровень помещать: Зависит от ваших потребностей. «Мне лично нравится эта модель» → Пользовательский уровень; «В этом проекте все используют Sonnet для экономии» → Проектный уровень.
• Один важный момент: В отличие от большинства других полей, model считывается только один раз при запуске сеанса. Если вы изменили его, вам нужно либо перезапустить сеанс, либо переключить модель «на лету» командой /model. Параметр запуска --model и переменная окружения ANTHROPIC_MODEL могут временно переопределить его (подробнее о моделях см. статью 5).

У этого поля есть очень удобное применение: настройка разных моделей по умолчанию для разных проектов. Например, для проекта с документацией, где задачи несложные, в settings.json проектного уровня жестко задается легкая модель model; а для основного проекта с кодом настройка не задается, сохраняя более мощную модель из пользовательского уровня по умолчанию. Благодаря такому разделению, при входе в проект нужная модель применяется автоматически, и не нужно каждый раз переключать ее вручную с помощью /model — так вы не тратите лимит мощной модели на простые задачи и не жертвуете качеством в сложных. Это отличный пример того, почему «проектный уровень перекрывает пользовательский»: проектный уровень настраивается под конкретный проект, а пользовательский служит резервом для всех остальных.

permissions: разрешать ли использование определенного инструмента / команды

Этому была посвящена отдельная 20-я статья — правила allow (разрешить), ask (спрашивать каждый раз) и deny (запретить жестко), которые позволяют точно контролировать права на уровне инструментов и команд.

• На какой уровень помещать: Линии безопасности, которые должна соблюдать вся команда (например, «запретить curl», «запретить чтение .env») → Проектный уровень, коммитим в git, чтобы они были у всех; если вы лично хотите разрешить еще несколько команд для удобства → Локальный или Пользовательский уровень.
• Помните правило из раздела 03: permissions — это массив, уровни объединяются — не надейтесь, что, прописав deny на одном уровне, вы аннулируете allow на другом.

env: внедрение переменных окружения в сеанс

Пары ключ-значение, записанные в env, применяются как переменные окружения к каждому сеансу и подпроцессам, запущенным Claude Code.

Аналогия: бейдж и экипировка, которые выдают перед входом в цех. Независимо от того, кто сегодня пришел на работу, при входе в этот цех (сеанс) он автоматически получает этот стандартный набор — env и есть этот «входной набор», объявленные здесь переменные будут присутствовать в каждой команде и каждом подпроцессе, запущенном в сеансе.

• Типичное использование: Включение телеметрии (CLAUDE_CODE_ENABLE_TELEMETRY), передача фиксированной переменной для определенного набора инструментов.
• На какой уровень помещать: Окружение, специфичное для проекта (например, адрес службы для этого проекта) → Проектный уровень; то, что вы хотите глобально → Пользовательский уровень.

hooks: автоматический запуск скриптов в заданные моменты

hooks — это точка входа для тех «автоматических действий, вызываемых событиями», которые неоднократно упоминались в прошлой статье и будут детально рассмотрены в статье 33 — они настраиваются именно в settings.json. Например, «после каждого изменения файла автоматически запускать форматирование» или «при каждом запуске сеанса здороваться».

• На какой уровень помещать: Контрольные точки, которые должна проходить вся команда (например, «автоматический lint перед коммитом») → Проектный уровень; ваши личные привычки автоматизации → Пользовательский уровень.
• Как конкретно их писать и какие события можно отслеживать, мы рассмотрим в статье 33. Пока просто знайте, что «их дом — settings.json».

statusLine: пользовательская нижняя строка состояния

В статье 14 мы говорили о «строке состояния» внизу интерфейса. statusLine позволяет настроить, что именно там отображается — например, добавить туда скрипт, чтобы в реальном времени показывать текущую ветку git, текущую модель или использование токенов.

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

• На какой уровень помещать: Строка состояния — это личное визуальное предпочтение, подавляющее большинство размещает ее на пользовательском уровне (~/.claude/settings.json), настраивая один раз для всех проектов.

Я собрал свой опыт «размещения на нужном уровне» для этих часто используемых полей в таблицу, к которой можно обратиться при сомнениях:

Параметр настройки	Для чего нужен	Мой вариант размещения по умолчанию
model	Модель по умолчанию	Личные предпочтения → Пользовательский; Единообразие проекта → Проектный
permissions	Доступ к инструментам / командам	Базовая безопасность → Проектный уровень (в git)
env	Внедрение переменных окружения	Специфика проекта → Проектный; Глобально → Пользовательский
hooks	Автоматические действия по событиям	Контроль команды → Проектный; Личные привычки → Пользовательский
statusLine	Кастомная строка состояния	Визуальные предпочтения → Пользовательский уровень

Частая путаница: не все настройки живут в settings.json

Многие этого не знают, и узнают только наткнувшись на ошибки. У Claude Code есть еще один конфигурационный файл ~/.claude.json (обратите внимание, именно .claude.json в домашнем каталоге, это не то же самое, что ~/.claude/settings.json). В нем хранится другой тип данных: ваш сеанс авторизации (login session), настройки MCP-серверов в пользовательской/локальной области видимости (о том, что настройки MCP хранятся здесь, упоминалось в статье 22), статус доверия (trust status) для каждого проекта и различные кэши.

Главная ловушка заключается в том, что существует небольшое число настроек, которые по правилам разработчиков могут размещаться только в ~/.claude.json. Если вы запишете их в settings.json, это сразу вызовет ошибку валидации схемы. Из официально упомянутых: autoConnectIde (автоматическое подключение внешнего терминала к IDE), teammateDefaultModel (модель по умолчанию для товарищей по команде) и подобные.

Типичный сценарий столкновения с этой проблемой: вы хотите настроить «автоматическое подключение внешнего терминала к VS Code» и по привычке пишете это в settings.json. В результате валидация $schema тут же подсвечивает поле красным, а /status выдает ошибку. И только прочитав документацию, вы узнаете, что дом этого поля — в ~/.claude.json. Поэтому запомните: settings.json управляет «поведенческими переключателями», а ~/.claude.json — «состояниями сеансов / MCP / кэшами» и другими закулисными данными — в подавляющем большинстве случаев вы работаете с первым, но если какое-то поле «ну никак не записывается в settings.json», подумайте, не должно ли оно быть в ~/.claude.json.

💡 Вкратце: Часто используемые поля — это model (модель по умолчанию), permissions (контроль прав), env (переменные окружения), hooks (автоматические действия), statusLine (строка состояния); то, что «нужно всей команде», размещайте на проектном уровне в git, «личные предпочтения» — на пользовательском. Используйте $schema, чтобы редактор помогал находить ошибки; помните, что некоторые поля (например, autoConnectIde) живут в ~/.claude.json, а не в settings.json.

---

05 Где редактировать, когда вступают в силу изменения и как убедиться, что они действительно прочитаны

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

Где редактировать: прямая правка файла или команда /config

Есть два пути:

1. Непосредственно редактировать JSON-файл в редакторе — найдите файл нужного уровня (как описано в разделе 02) и измените его. Как мы советовали и для CLAUDE.md, «редактирование файлов предпочтительнее для большей наглядности», это надежнее, чем вводить команды на ходу.
2. Ввести /config в сеансе — это интерактивный интерфейс настроек от разработчиков, который позволяет просматривать состояние и изменять некоторые часто используемые переключатели (темы, подробный вывод и т.д.).

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

Когда вступают в силу изменения: в основном горячая перезагрузка (hot reload), для двух исключений нужен перезапуск

И это хорошая новость: Claude Code следит за вашими файлами настроек, и изменение большинства ключей вступит в силу прямо в работающем сеансе без перезапуска. Официально заявлено:

Claude Code следит за вашими файлами настроек и перезагружает их при их изменении... Это включает в себя permissions, hooks и credential helpers.

Но есть два исключения, они «считываются только один раз при запуске». Если вы их изменили, нужно перезапустить сеанс (или переключить соответствующей командой на лету), чтобы они применились:

Поле	Как применить после изменения
model	Перезапуск, или переключение в сеансе командой /model
outputStyle (стиль вывода, рассмотрим в следующей статье)	Перезапуск, или /clear для пересоздания

Практический смысл этого правила таков: если вы изменили permissions или hooks, сохраните файл, и они сразу вступят в силу, можете продолжать работу; но если вы изменили model и не видите разницы — не спешите думать, что ошиблись в синтаксисе, для этого требуется перезапуск. Ошибка, описанная в начале, если бы она касалась permissions, то выявилась бы сразу после сохранения; но она совпала с особым случаем «игнорирования на уровне проекта», поэтому поиск проблемы затянулся.

Как убедиться, что они действительно прочитаны: используйте /status и смотрите на «Setting sources»

Это ключевой прием, который лечит сомнения «я не уверен, какую конфигурацию он загрузил». Введите в сеансе команду /status, и там будет строка Setting sources, которая перечисляет, какие уровни настроек фактически загружены в текущем сеансе — например, User settings, Project local settings (конкретные названия ярлыков зависят от фактического интерфейса).

Официальное описание очень прагматично:

Строка Setting sources подтверждает, какие источники читаются... Уровень появляется в списке только в том случае, если этот источник загружает хотя бы один ключ, поэтому пустой список означает, что ни один источник настроек не найден.

Эта фраза содержит много информации, давайте разберем:

• Уровень, который вы редактировали, появился в списке = файл был успешно прочитан.
• Уровень, который вы редактировали, не появился = Claude Code вообще его не нашел / не прочитал (скорее всего, вы указали неверный путь, например, вместо .claude/settings.json написали settings.json).
• Если в файле есть синтаксическая ошибка (поврежденный JSON, недопустимое значение), /status прямо выдаст вам сообщение об ошибке, избавляя от необходимости гадать.

Поэтому теперь, после того как вы настроили settings.json, первым делом введите /status, чтобы убедиться, что этот уровень действительно есть в списке — если бы я знал это раньше, те двадцать минут из начала статьи превратились бы в две.

Настройки не применяются? Используйте эту таблицу для устранения неполадок

Сведем все «подводные камни» из этой статьи в одну таблицу устранения неполадок. Если в следующий раз ваши настройки «не реагируют», не спешите сомневаться в синтаксисе, проверьте себя в этом порядке, и вы почти наверняка найдете причину:

Симптом	❌ В чем не нужно сомневаться в первую очередь	✅ Что нужно проверить в первую очередь
Никакой реакции после изменения	Ошибка в имени поля?	Используйте /status, чтобы проверить, есть ли ваш уровень в Setting sources — если нет, то ошибка в пути
Изменение model не влияет	Конфигурация повреждена?	model требует перезапуска для вступления в силу (или переключения через /model), простого сохранения недостаточно
defaultMode: "auto" не работает	Опечатка?	auto игнорируется на уровне проекта/локальном, его нужно поместить на пользовательский уровень (раздел 03)
Записан deny, но команда выполняется	Неправильно написан deny?	Разрешения объединяются между уровнями, скорее всего, где-то есть allow, который вы не удалили (раздел 03)
Поле никак не сохраняется в settings.json	Ошибка формата JSON?	Возможно, оно должно быть в ~/.claude.json (например, autoConnectIde, раздел 04)

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

💡 Вкратце: Редактируйте файл напрямую или используйте /config (управляет лишь небольшим количеством переключателей); permissions/hooks применяются сразу после сохранения, model/outputStyle требуют перезапуска; после настройки обязательно используйте /status и проверьте строку «Setting sources», чтобы убедиться, что ваш уровень действительно прочитан; если настройки не работают, проверяйте сначала уровни, а не синтаксис.

---

06 Практика: пишем конфигурацию пользовательского и проектного уровня и используем /status для проверки

Теория без практики мертва. Ниже мы вместе с вами напишем двухуровневую конфигурацию, а затем используем /status, чтобы убедиться, что они действительно загружаются — так мы пройдем весь путь «запись в файл → разделение по уровням → проверка». В этом минимальном примере вам не потребуется сложная среда.

Шаг первый: Создаем тестовый проект (в терминале)

mkdir settings-demo && cd settings-demo

Шаг второй: Пишем конфигурацию уровня проекта

В файл settings-demo/.claude/settings.json вставьте следующий код (разрешение команды тестирования, блокировка curl). Первая строка $schema позволит вашему редактору автоматически проверять синтаксис:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)"]
  }
}

Шаг третий: Пишем локальную конфигурацию

Затем в settings-demo/.claude/settings.local.json добавьте персональное разрешение, которое будет принадлежать только вам и не попадет в git:

{
  "permissions": {
    "allow": ["Bash(git status *)"]
  }
}

Ожидание: После создания обоих файлов в этом проекте одновременно появятся настройки «уровня проекта» и «локального уровня». Обратите внимание: как было сказано в разделе 02, settings.local.json будет автоматически проигнорирован git (проверим это на следующем шаге).

Шаг четвертый: Убеждаемся, что локальный уровень действительно проигнорирован git

git init -q && git status --short

Ожидание: В выводе вы увидите .claude/settings.json (проектный уровень, ожидает добавления в систему контроля версий), но не увидите .claude/settings.local.json — он был автоматически проигнорирован. Если вы видите эту разницу, значит, правило из раздела 02 об автоматическом игнорировании локального уровня подтвердилось.

Шаг пятый: Запускаем сеанс, используем /status для проверки загрузки обоих уровней

claude

После входа введите:

/status

Ожидание: В появившейся информации о состоянии найдите строку Setting sources. В ней должны быть указаны Project local settings (и, возможно, User settings, если вы настраивали их ранее; точные названия зависят от интерфейса). Если уровни, которые вы настроили, есть в списке = конфигурация была успешно загружена. Если какой-то уровень не появился, вернитесь к разделу 02 и проверьте правильность путей к файлам.

Шаг шестой: Используем /permissions для перекрестной проверки работы правил

/permissions

Ожидание: Вы должны увидеть только что написанные правила — npm run test * и git status * в списке разрешенных, а curl * — в списке запрещенных. Обратите особое внимание: git status * исходит из локального уровня, а два других — из проектного, но они все действуют одновременно — это живой пример правила из раздела 03, гласящего, что «правила доступа объединяются между уровнями, а не перезаписываются».

Пройдя эти шесть шагов, вы собственноручно проверили ключевые возможности settings.json: написание на разных уровнях, автоматическую изоляцию личных настроек, подтверждение загрузки через /status и проверку объединения правил через /permissions. В будущем настройка любого уровня или поля будет опираться на этот же процесс.

💡 Вкратце: На практике мы тренируем цепочку «конфигурация проектного + локального уровня → git status для проверки игнорирования локального уровня → /status для проверки загрузки обоих уровней → /permissions для проверки объединения правил» — проделав это своими руками, вы сразу поймете, как работают самые запутанные моменты: уровни и объединение массивов.

---

07 Резюме

В этой статье мы подробно разобрали работу «главного распределительного щита» Claude Code — settings.json. Мы прошли путь от понимания того, «что это такое», до «сколько уровней, кто важнее и как проверять после изменения», наводя порядок в конфигурации системы.

Объединим ключевые моменты:

Что вы хотите понять	Ответ	Ключевой момент в одной фразе
Как это связано с CLAUDE.md	Это разные вещи	CLAUDE.md управляет тем, «что помнить», а settings.json — «как работать»
Сколько уровней и где хранить	Три уровня	Пользовательский ~/.claude/, проектный .claude/ (в git), локальный .claude/settings.local.json (авто-gitignore)
Что делать при конфликтах	Чем конкретнее, тем важнее	Командная строка > Локальный > Проектный > Пользовательский, Managed имеет высший приоритет
Самый неочевидный момент	Объединение массивов	Правила доступа и другие массивы объединяются без дубликатов между уровнями, а не перекрываются
Какие поля меняются чаще всего	Пять	model/permissions/env/hooks/statusLine
Как проверить изменения	/status	Проверьте строку «Setting sources», чтобы убедиться, что ваш уровень был прочитан

Теперь вы должны уметь: различать задачи settings.json и CLAUDE.md, понимать, какую конфигурацию помещать на уровень пользователя, а какую на уровень проекта, разбираться в приоритетах «кто кого перекрывает» и неочевидном правиле «массивы объединяются, а не перекрываются», знать о высокочастотных полях model/permissions/env/hooks/statusLine и использовать /status для проверки применения настроек. Этот навык многоуровневой настройки — тот самый ключ, который позволит превратить Claude Code из состояния «установил и работает» в «инструмент, идеально подходящий для вас и рабочего процесса вашей команды».

Те двадцать минут мучений в самом начале можно свести к одной фразе — «не разобрался, на каком уровне писать». Прочитав эту статью, вы сэкономите кучу времени: если конфигурация не вступает в силу, не спешите проверять синтаксис, сначала подумайте, «на тот ли этаж я ее положил», а потом введите /status и посмотрите.

---

Следующая статья — 32 «Стили вывода (Output Styles)». Вы уже видели в settings.json особое поле outputStyle и помните, что это одно из двух исключений, которые «считываются только один раз при запуске и требуют перезапуска для вступления в силу»? В следующей статье мы подробно поговорим о нем: как настроить «стиль общения и системные подсказки» Claude, чтобы переключить его с помощника по умолчанию на формат, который лучше подходит для объяснений, обучения или других сценариев. Подумайте об этом: насколько сильно может измениться стиль ответов одного и того же Claude, если просто сменить ему стиль вывода?

---

Рекомендуемое чтение

• Система памяти (memory): позвольте ему запомнить вас в разных сеансах
• Плагины (Plugins): как упаковать разрозненные настройки в один клик
• Введение в Claude Code