Гайды

Claude Code настройка: как настроить settings.json

15 октября 2026 · 14 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 15 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.

Claude Code настройка: как настроить settings.json — это выбор уровня файла, правка ключей и проверка, какое значение победило. Настройки живут в JSON-файлах четырёх уровней: пользовательском, проектном, локальном проектном и управляемом. Собственный прогон редакции: скачали топ-10 выдачи DuckDuckGo (ru-RU) по запросу «Claude Code настройка: как настроить settings.json»: текст отдали 9 из 10. Медиана объёма читаемого текста топа — 2922 слова. Метку 2026 года несут 6 из 9 прочитанных страниц.

Где лежат настройки Claude Code: уровни и приоритет файлов

Документация проекта описывает четыре уровня. Пользовательский файл ~/.claude/settings.json действует на вас в каждом проекте на этой машине и хранит личные предпочтения: тема, режим редактора, модель по умолчанию, ваши собственные правила разрешений. Проектный .claude/settings.json охватывает всех, кто работает в папке, которая его содержит; в репозитории git его коммитят, чтобы товарищи по команде его получили. Туда кладут разрешения команды, хуки, плагины и переменные окружения, которые нужны проекту.

Локальный проектный .claude/settings.local.json действует на вас только в этом одном проекте. Claude Code исключает его из git при создании файла; если вы создадите его вручную, добавьте его в .gitignore сами. Назначение — личные переопределения для одного проекта и тестирование перед тем, как вы поделитесь. Четвёртый уровень — управляемый: managed-settings.json и другие управляемые источники, которые развёртывает организация. Вы его не создаёте и не редактируете; он несёт требования политики безопасности и соответствия.

Разница в охвате видна на примере из документации. ~/.claude/settings.json покрывает каждый проект на вашей машине, и ничего на машине вашего товарища или в облачной сессии. acme-app/.claude/settings.json покрывает ваш acme-app/; он охватывает клон товарища и облачную сессию, только если вы зафиксируете файл в системе контроля версий. До этого это файл на вашем диске, как и любой другой. acme-app/.claude/settings.local.json покрывает только ваш acme-app/. Управляемые настройки покрывают каждый проект на каждой машине, на которую организация их развёртывает, или на которую вы входите с учётной записью организации; только управляемые сервером настройки охватывают облачную сессию.

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

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

Команда /config и правка settings.json вручную

Два пути ведут к одному результату. Первый — меню /config: оно меняет параметры и сохраняет их на нужный уровень. Документация описывает поведение так: Claude Code записывает ~/.claude/settings.json при первом изменении опции в меню /config, которую он сохраняет в пользовательские настройки, например темы, и .claude/settings.local.json при первом предоставлении постоянного подтверждения на запрос разрешения, например «Да, и больше не спрашивайте» для команды Bash. Несколько опций /config, включая Show tips, сохраняются в .claude/settings.local.json вместо файла пользователя.

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

Порядок действий при ручной правке:

1. Определите уровень: личная привычка, командное правило или локальный эксперимент.
2. Откройте соответствующий файл. Проектный может уже существовать и быть зафиксированным; если нет, создайте его в .claude/settings.json в папке проекта.
3. Добавьте ключ и значение, соблюдая синтаксис JSON.
4. Сохраните файл и проверьте, какое значение Claude Code использует.
5. Если поведение не изменилось, проверьте более приоритетный уровень и объединение списков.

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

Место локального файла зависит от того, где вы запускаете Claude Code. В подкаталоге репозитория git он читает и записывает .claude/settings.local.json в корне репозитория и применяет подтверждения ко всему репозиторию; в worktree он использует файл в корне основного checkout. Файл остаётся рядом с .claude/settings.json вне репозитория git, когда корень репозитория — это ваш домашний каталог, в Windows или когда корень репозитория либо его запись .git или .claude не принадлежит вашему пользователю.

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

Модель по умолчанию и режим разрешений

Модель задаётся ключом model в settings.json. Справочник параметров описывает полный набор ключей: где находится каждый ключ, его тип и значение по умолчанию, а также готовый к использованию пример и индекс всех ключей. Рядом с моделью живут связанные параметры: advisorModel выбирает, какая модель отвечает, когда Claude использует инструмент советника; fallbackModel задаёт запасную модель; availableModels и deniedModels ограничивают набор. Есть effortLevel и maxEffortLevel, fastMode и fastModePerSessionOptIn, alwaysThinkingEnabled, modelPicker с полями для выбора.

Режим разрешений задаётся ключом permissions.defaultMode. Он задаёт режим, в котором начинаются новые сессии. Справочник параметров перечисляет значения: default без запроса выполняет только чтение, acceptEdits также без запроса правит файлы и выполняет распространённые команды файловой системы, plan читает и планирует, но блокирует редактирование, пока вы не утвердите план. Значения auto и bypassPermissions не вступают в силу из проектных или локальных настроек, поэтому их задают в ~/.claude/settings.json. Обзор на blog.fillikam.com описывает переключение трёх режимов прямо в сессии сочетанием Shift+Tab. Режим по умолчанию — не единственный рычаг: конкретные правила allow, ask и deny уточняют его для отдельных команд и путей.

Порядок выбора модели на практике:

1. Задайте model на пользовательском уровне, если у вас одна привычная модель для всех проектов.
2. Переопределите model в проектном файле, если проект требует другой модели.
3. Добавьте fallbackModel, чтобы при недоступности основной модели работа не останавливалась.
4. Ограничьте availableModels или deniedModels, если нужно сузить выбор.
5. Проверьте, какое значение победило, после сохранения.

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

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

Правила allow, ask и deny для команд и файлов

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

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

Практический порядок настройки разрешений:

1. Начните с deny для того, что не должно происходить никогда: секреты, чужие каталоги, разрушительные команды.
2. Добавьте allow для рутинных операций, которые вы подтверждаете каждый день.
3. Оставьте ask для всего остального — это поведение по умолчанию.
4. Проверьте объединение: правила из проектного и пользовательского файлов складываются.
5. Пересмотрите списки после того, как Claude Code запишет новые подтверждения.

В локальном файле, который Claude Code хранит в корне репозитория, правило разрешений, начинающееся с /, привязывается к основному рабочему каталогу сессии. Абсолютный путь от корня файловой системы обзор на vc.ru записывает с двумя косыми чертами: //tmp/build означает /tmp/build. При переносе конфига между проектами проверяйте такие правила отдельно.

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

Блок env: переменные окружения и сторонний эндпоинт

Блок env в settings.json задаёт переменные окружения для сессий Claude Code. Обзор на vc.ru насчитывает в переменных окружения больше тридцати рычагов и советует задавать их в блоке env внутри settings.json, откуда они применяются к каждой сессии. Обзор на Хабре относит к полезным env.ENABLE_TOOL_SEARCH, env.CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, env.MAX_THINKING_TOKENS, env.CLAUDE_CODE_MAX_OUTPUT_TOKENS. Эти ключи управляют поиском инструментов, порогом автосжатия контекста и лимитами рассуждения и вывода.

Переменные окружения удобны тем, что не требуют правки кода проекта: они применяются к процессу Claude Code. Их можно задать в блоке env файла settings.json или в окружении оболочки. Блок env держит значения вместе с остальным конфигом и переносится вместе с ним.

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

Практический порядок работы с блоком env:

1. Определите, какие значения нужны всем сессиям, а какие — одному проекту.
2. Общие значения положите в пользовательский файл, проектные — в проектный.
3. Секреты держите вне репозитория: локальный файл или окружение оболочки.
4. Проверьте, что значение применилось, до того как полагаться на него.
5. При смене поставщика API пересмотрите ограничивающий ключ.

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

CLAUDE.md и settings.json: что куда класть

Два файла решают разные задачи. settings.json хранит параметры: модель, права, переменные окружения, хуки. CLAUDE.md хранит память проекта — инструкции, которые Claude Code читает каждый раз. Обзор на insidepc.tech прямо разводит назначение: settings.json и CLAUDE.md — разное. Обзор на blog.fillikam.com называет CLAUDE.md памятью проекта, которую он читает каждый раз.

Практическое разделение простое. В settings.json идёт то, что должно применяться механически: разрешения, модель, переменные окружения. В CLAUDE.md идёт то, что описывает контекст: соглашения проекта, структура каталогов, команды сборки, стиль кода. Правило разрешения в settings.json исполняется движком; инструкция в CLAUDE.md читается моделью как часть контекста.

Порядок выбора места для новой настройки:

1. Спросите, должно ли правило исполняться движком механически. Если да — settings.json.
2. Спросите, описывает ли текст контекст и ожидания. Если да — CLAUDE.md.
3. Проверьте уровень: личное, командное, локальное.
4. Убедитесь, что не дублируете одно и то же в двух файлах.
5. Пересмотрите CLAUDE.md, когда меняются соглашения проекта.

Хуки живут в settings.json и запускают действия до и после инструментов. Обзор на blog.fillikam.com описывает хуки как автодействия до и после инструментов. Справочник параметров относит хуки и автоматизацию к отдельной группе ключей, включая ограничение URL-адресов для HTTP-хуков.

Частые вопросы

Где Claude Code хранит настройки?

Настройки живут в JSON-файлах четырёх уровней. Пользовательский ~/.claude/settings.json действует на вас в каждом проекте на этой машине. Проектный .claude/settings.json охватывает всех, кто работает в папке, которая его содержит. Локальный .claude/settings.local.json действует на вас только в этом одном проекте. Управляемый managed-settings.json развёртывает организация, и вы его не редактируете.

Какой файл настроек главнее при конфликте?

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

Как поменять модель по умолчанию?

Задайте ключ model в settings.json на нужном уровне. Пользовательский файл подойдёт, если у вас одна привычная модель для всех проектов; проектный — если проект требует другой. Рядом доступны fallbackModel для запасной модели и availableModels с deniedModels для ограничения набора. Сверьте имя ключа со справочником параметров на дату публикации.

Что делают правила allow, ask и deny?

Три списка задают три исхода для команд и файлов. allow пропускает действие без вопроса, ask спрашивает, deny блокирует. Когда вы выбираете «Да, и больше не спрашивайте» для команды Bash, Claude Code сохраняет подтверждение как правило allow. Паттерн защиты секретов строится на deny: запретите чтение файлов с ключами, чтобы модель не могла их прочитать.

Можно ли подключить сторонний эндпоинт через блок env?

Блок env задаёт переменные окружения для сессий Claude Code, и через них указывают другой адрес API. Точный набор переменных для конкретного шлюза сверяйте со справкой вендора на дату публикации: имена переменных и требования к совместимости меняются. Управляемые настройки организации могут ограничить, какие поставщики API может использовать машина, и тогда личная смена эндпоинта не сработает.

Промпт, чтобы получить разбор своего settings.json по уровням и приоритету:

Разбери мой файл настроек Claude Code. Вот его содержимое:

[вставьте ваш settings.json]

Сделай следующее:
1. Определи, на каком уровне лежит файл: пользовательский, проектный, локальный проектный или управляемый.
2. Перечисли ключи верхнего уровня и объясни, что каждый задаёт.
3. Отметь ключи, которые переопределяются более приоритетным уровнем, и назови этот уровень.
4. Отметь списки правил разрешений и объясни, как они объединяются с другими уровнями.
5. Предложи, что перенести в CLAUDE.md, а что оставить в settings.json.
6. Укажи ключи, которых нет в справочнике параметров на дату публикации.

Отвечай по-русски, кратко, списком. Не выдумывай имена ключей: если ключа нет в справочнике, скажи об этом прямо.

Что менять под себя: [вставьте ваш settings.json] — содержимое вашего файла. Если разбираете несколько уровней сразу, добавьте их отдельными блоками и подпишите путь каждого.

Вариации той же задачи:

1. Промпт, чтобы составить проектный settings.json с нуля: опишите стек проекта и попросите набор разрешений, модель и переменные окружения.
2. Промпт, чтобы проверить правила deny на полноту: перечислите чувствительные пути и попросите закрыть их.
3. Промпт, чтобы развести settings.json и CLAUDE.md: дайте текущее содержимое обоих и попросите перераспределить.
4. Промпт, чтобы объяснить конфликт уровней: вставьте два файла и попросите показать, какое значение победит.
5. Промпт, чтобы собрать блок env: перечислите нужные переменные и попросите оформить их как JSON-блок.

Если вы настраиваете соседние инструменты, посмотрите материал про GitHub Copilot MCP: как подключить сервер и про то, как отключить GitHub Copilot. Для работы с текстом внутри Claude пригодится разбор как перевести текст с Claude, а для браузерных сценариев — как подключить Playwright MCP к Claude.