Один и тот же параметр может прийти из нескольких источников, и вся тонкая настройка держится на том, чтобы знать их приоритет. Для обычного скалярного значения он таков: managed (политика организации) перекрывает CLI-аргументы, те - local (личное для этого репозитория), затем project (командное в репозитории) и user (личный default для всех проектов). Верхний слой перекрывает нижние - это и есть precedence, и без его понимания настройка превращается в гадание, почему значение "не то".

Слои различаются не только приоритетом, но и тем, коммитят ли их. managed приходит от администратора и несёт обязательные security- и compliance-правила. user живёт в ~/.claude и не коммитится - это личные defaults и UI. project лежит в .claude/settings.json и .mcp.json, коммитится и задаёт единый workflow команды. local в settings.local.json не коммитится - для машинных путей и экспериментов. Полезно один раз свести это в таблицу, чтобы класть настройку в правильный слой.

Слияние слоёв устроено по типу значения. Скалярное значение из более высокого источника просто заменяет нижнее. Объекты обычно deep-merge, а документированные массивы могут объединяться и дедуплицироваться. Но есть принципиальное исключение - permission allow, ask и deny: правила из разных scopes сохраняются вместе, а не заменяются. Это сделано намеренно, чтобы широкий user-allow не стирал project- или managed-deny; безопасность здесь важнее удобства перекрытия.

Полезно один раз увидеть минимальный settings с $schema, чтобы редактор давал автодополнение и валидацию. Ниже - фрагмент с моделью и permissions. Оговорка: schema может обновляться с задержкой относительно самого свежего CLI, поэтому при расхождении сначала сверяются с официальной страницей settings и changelog, а затем проверяют /doctor. Схема - помощник редактора, а не финальная истина о доступных ключах.