settings.json - основной файл настроек, и полный индекс всех ключей вынесен в отдельный справочник в конце книги. Здесь важнее другое - увидеть несколько цельных профилей, потому что настройки работают не по одному ключу, а как согласованный набор. Профиль отвечает на вопрос "как мы хотим, чтобы вёл себя Claude в этом контексте", и собирается из permissions, sandbox и служебных ключей в одно объяснимое поведение, а не в россыпь скопированных строк.

Базовый командный профиль задаёт разумный рабочий баланс. Режим по умолчанию - default; в allow - именно семейства команд проверки (lint, test, typecheck); в ask - push и выход из sandbox; в deny - чтение .env и секретов. Рядом включённый sandbox со strict-режимом и узким сетевым allowlist, плюс служебные cleanupPeriodDays и respectGitignore. Полезно один раз увидеть такой профиль целиком - он читается как явное описание рабочих границ команды.

Оговорка к любому профилю обязательна: команды и домены в примерах - только форма, а не готовый allowlist. Их заменяют реальным toolchain проекта; копировать чужой allowlist механически опасно, потому что он разрешает именно те команды и хосты, что были нужны другому проекту, а не вашему. Профиль - это шаблон структуры, который вы наполняете своими значениями, осознавая, что именно каждая строка открывает.

Для автоматизации нужен более строгий профиль. Locked-down-профиль ставит режим dontAsk, разрешает только чтение и узкий набор команд (npm ci, lint, test) и явно запрещает Edit, Write, WebFetch и WebSearch, оставляя sandbox строгим. Это профиль для закрытого неинтерактивного прогона, где агент не должен ни менять файлы, ни ходить в сеть. Разово поведение уточняют флагами: --settings передаёт путь или JSON-override, --setting-sources ограничивает, какие категории источников вообще загрузятся.

Понимать, что применяется на лету, важно для безопасной правки. Claude Code следит за user-, project-, local- и managed-настройками; изменения permissions, hooks и credential-хелперов обычно вступают в текущей сессии и вызывают hook ConfigChange. Но уже запущенный процесс не получает новую политику ретроактивно - проверяют следующее действие, а не надеются, что правка догонит идущую операцию. Это ровно та же логика, что и с кэшем контекста.

Проверяют настройки набором команд, а не на глаз. /config открывает пользовательские настройки интерфейса, /status показывает итоговый provider, модель и источники, /doctor диагностирует конфигурацию, /permissions - итоговые правила, /sandbox - состояние и overrides песочницы. Полезно один раз собрать эти команды рядом: любую правку settings проверяют именно ими - через фактический эффект и негативный тест (что deny действительно запрещает), а не через уверенность, что "написано правильно".