Разрешения Claude Code: правила allow, deny и ask — как это работает
Покадровый разбор того, как Claude Code спрашивает разрешение: три варианта в промпте, allow-правила, сохраняемые в settings.local.json, порядок оценки с приоритетом deny, режимы разрешений и рецепты, которые снижают число вопросов при кодинге и в CI — все пробелы видеоряда закрыты официальной документацией.
Разрешения Claude Code за 60 секунд
- Claude Code спрашивает перед Bash, Edit, WebFetch и Write; Read, Glob, Grep и LS выполняются без вопросов.
- "Yes, and don't ask again" сохраняет правило вроде Bash(git add:*) в .claude/settings.local.json — вашу личную, исключённую из git книжицу правил этого репозитория.
- Правила оцениваются в порядке deny → ask → allow: deny из любого файла настроек побеждает, и никакое allow-правило не вырежет из него исключение.
- Режимы масштабируют доверие: acceptEdits (alt+m) для работы с правками, plan для read-only разведки, bypassPermissions для CI через --permission-mode — а значения defaultMode auto и bypassPermissions работают только из пользовательских или управляемых настроек.
Claude Code Tutorial #4 - Tools & Permissions
Канал:The Net Ninja4:55
Permission Modes Head to Head
Канал:ttywood6:20
Permissions — Claude Code documentation
Документация:code.claude.com
Settings files — Claude Code documentation
Документация:code.claude.com
Все статичные кадры взяты из записи Net Ninja — чистый захват экрана без камеры и оверлеев. Выпуск ttywood, сравнивающий режимы разрешений в лоб, послужил перекрёстной проверкой для разделов о режимах и рецептах, но не дал ни одного кадра — в его кадрах вшитые подписи. Синтаксис правил, порядок оценки, поведение режимов и приоритет файлов настроек сверены с двумя официальными страницами документации.
Видео © The Net Ninja и ttywood, даны только ссылки. Документация © Anthropic. Скриншоты приведены в гайде в целях комментария.
Настраиваем разрешения Claude Code шаг за шагом
О чём Claude Code спрашивает, прежде чем действовать
- 1
Смотрите, какие инструменты вызывают запрос разрешения
Claude Code сам выбирает инструменты — Read чтобы открыть файл, Edit чтобы изменить, Bash для команд шелла. В документации по настройкам у каждого есть колонка Permission Required: Bash, Edit, WebFetch и Write останавливаются и спрашивают, а Read, Glob, Grep и LS просто выполняются. Имена инструментов вы не вводите; суть в том, чтобы заранее знать, какие действия остановятся и будут ждать вас.
В документации настроек Claude Code каждый встроенный инструмент помечен вердиктом Permission Required.Смотреть на 1:05 - 2
Попросите правку и посмотрите, как он сперва читает
В видео запрос нарочно крошечный: добавить в src/app/globals.css переменную --highlight пастельно-жёлтого цвета. Claude Code сначала читает файл — Read никогда не требует разрешения — и останавливается лишь перед изменением. Это разделение — вся модель разрешений в миниатюре: смотреть бесплатно, трогать — после спроса.
Запрос переменной подсветки, набранный во вводе Claude Code в VS Code.Смотреть на 1:45 - 3
Прочитайте три варианта, прежде чем ответить
Каждый запрос на правку предлагает три ответа. 1. Yes одобряет эту единственную правку. 2. Yes, and don't ask again this session одобряет остальные правки сессии (в показанной сборке alt+m). 3. No, and tell Claude what to do differently (esc) отклоняет изменение и позволяет направить процесс. Третий вариант — не провал, а способ скорректировать курс до того, как код уедет.
Запрос на правку globals.css со всеми тремя вариантами разрешений на виду.Смотреть на 2:17
Говорим «да» один раз: сохраняем allow-правило
- 4
Один промпт на правку, а не на задачу
Одобрение не переносится на следующее изменение. В демо на три отдельные правки одного файла понадобилось три нажатия Yes, а следующее изменение снова спросило. Схема «подтверждай каждый раз» работает, но плохо масштабируется дальше двухстрочной задачи — именно для этого существуют allow-правила и режимы.
Вторая правка globals.css снова вызывает промпт сразу после одобрения первой.Смотреть на 2:32 - 5
Bash-команды спрашивают отдельно
У команд шелла свой шлюз. Когда в демо просят Claude сделать коммит, Bash(git add src/app/globals.css) висит в состоянии Waiting до вашего ответа. Да для одной команды — не да для следующей: последующий git commit спросит сам за себя.
Команда git add ждёт одобрения, выше прокручивается вывод уже выполненного git.Смотреть на 3:16 - 6
Пусть «don't ask again» напишет правило за вас
Выбор Yes, and don't ask again для команд git add делает две вещи разом: разблокирует текущую команду и сохраняет правило. Создаётся файл .claude/settings.local.json в корне репозитория с объектом permissions и массивом allow — здесь "Bash(git add:*)" — плюс пустые массивы deny и ask. Теперь каждый будущий git add в этом проекте идёт без вопросов.
settings.local.json создан в .claude, allow-правило Bash(git add:*) сохранено.Смотреть на 3:40 - 7
Правьте правила вручную, когда диалог не может
Массив allow — обычный JSON, правила можно добавлять самому. Для одиночной команды — точная строка: Bash(npm run test); для всего, что начинается одинаково, — хвостовой :*: Bash(npm run test:*). Документация подтверждает: :* — shorthand для хвостового вайлдкарда. Держите файл личным: Claude Code сам добавляет settings.local.json в git-excludes, и видео говорит то же — файл для вашего рабочего процесса, а не для репозитория.
Сохранённое правило выделено в permissions.allow во время ручной правки файла.Смотреть на 4:22
Крутим делегирование режимами
- 8
На серию правок переключайтесь в accept edits
alt+m (в актуальных сборках режимы циклирует shift+tab) меняет бейдж сессии на accept edits on. Правки файлов теперь ложатся без промптов, и документация добавляет: обычные команды файловой системы — mkdir, touch, mv, cp — тоже принимаются автоматически. Милость действует в рамках сессии: начнёте новую — вернётесь к промпту на каждую правку, пока не включите снова.
Бейдж accept edits on, пока разрешённые git-команды завершают коммит.Смотреть на 4:35 - 9
Знайте всю лестницу режимов, прежде чем лезть
Режимы задают позу сессии по умолчанию. default спрашивает при первом использовании каждого инструмента; plan — read-only разведка, не правящая ни строчки; acceptEdits автоматически принимает правки файлов; dontAsk авто-отклоняет всё, что иначе спросило бы; auto одобряет вызовы инструментов с фоновой проверкой безопасности; bypassPermissions пропускает промпты, кроме малого набора действий, который не может авто-одобрить ни один режим. Выбирайте на сессию через --permission-mode или закрепляйте через permissions.defaultMode.
- 10
Положите defaultMode в правильный файл
Документация по настройкам прямолинейна: значения defaultMode auto и bypassPermissions не действуют из проектных или локальных настроек — кладите в пользовательские (~/.claude/settings.json) или управляемые, либо передавайте --permission-mode на одну сессию. Приоритет: managed settings → CLI --settings → .claude/settings.local.json → .claude/settings.json → пользовательские, и deny на любом уровне бьёт любое allow ниже.
Рецепты под копирку для реальных проектов
- 11
Рецепт: разрешить тесты, запретить разрушения
В командном .claude/settings.json разрешите тестовый цикл правилом "Bash(npm run test:*)" и огородите опасное через "Bash(rm -rf *)" и "Read(./.env)", чтобы секреты никогда не читались. Веб-исследования закрываются так же: "WebFetch(domain:example.com)" для одного домена, "WebFetch(domain:*.example.com)" на весь поддомен. Поскольку deny оценивается первым, никакое allow-правило не вырежет из него исключение.
- 12
Рецепт: безопасно убрать промпты в CI
Невзаимодействующим запускам нужна осознанная поза, а не случайная: передайте --permission-mode bypassPermissions в CI-джобе или задайте defaultMode в пользовательских или управляемых настройках — проектный файл этого права не имеет. Чтобы сделать ограждение постоянным, установите permissions.disableBypassPermissionsMode в "disable" в managed settings и аудитуйте машины через /permissions — она перечисляет каждое активное правило и файл, откуда оно пришло.
deny → ask → allow: как правила оцениваются на самом деле
Документация по разрешениям формулирует жёстко: правила оцениваются по порядку — deny, затем ask, затем allow — первый матч решает исход, и никакая специфичность правила порядок не меняет. Allow-правило не вырежет исключение из deny-правила, каким бы точным ни было.
Deny глобален и поверх файлов. Если пользовательские настройки разрешают команду, а проектные запрещают, побеждает deny: deny-правила из любого скоупа оцениваются раньше allow — а deny в managed settings не отменит даже флаг командной строки. Запрет «голого» имени инструмента вроде "Bash" идёт ещё дальше: по документации, инструмент целиком удаляется из контекста Claude.
Практический вывод: правила безопасности — запрет rm, запрет чтения .env, запрет force-push — кладите в проектный .claude/settings.json, который путешествует вместе с репозиторием, а allow-списки считайте удобствами поверх. Allow-списки между скоупами сливаются, а не перекрывают друг друга, так что личный settings.local.json может добавлять послабления, не ослабляя ничьих запретов.
Три рецепта, которые стоит украсть
Каждый рецепт называет файл, куда его класть. Общая константа для всех: deny побеждает везде и всегда.
Тесты — свободно, rm и .env — под замком
В .claude/settings.json: "permissions.allow": ["Bash(npm run test:*)"] (под свой стек замените на "Bash(npx vitest:*)" или "Bash(uv run pytest:*)"), "permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]. Тесты и их колбэки идут без присмотра; разрушительные удаления и чтение секретов блокируются ещё до того, как оценка дойдёт до allow-списка.
Прибейте исследования к доверенным доменам
Для работы с обилием документации: "WebFetch(domain:developer.mozilla.org)" и "WebFetch(domain:claude.com)" в allow, или "WebFetch(domain:*.example.com)" на весь поддомен. Запрет «голого» инструмента "WebFetch" выключает чтение веба целиком — полезно для воспроизводимых запусков, живущих только на локальном контексте.
CI без головы, но не без тормозов
Пусть CI-джоба передаёт --permission-mode bypassPermissions, или задайте "permissions.defaultMode": "bypassPermissions" в пользовательских или управляемых настройках — проектные и локальные этого дать не могут. Чтобы запретить режим в принципе, "permissions.disableBypassPermissionsMode": "disable" в managed settings закрывает путь каждому репозиторию и каждому флагу. И даже тогда bypassPermissions по-прежнему блокирует короткий список действий, который не может авто-одобрить ни один режим.
Правило не работает? Проверьте эти четыре вещи
Большинство сообщений «моё allow-правило игнорируют» сводится к тому, в какой файл правило упало и какой файл побеждает.
- 1Правило верное, файл неверный. Сессионные одобрения падают в .claude/settings.local.json; командные правила — в .claude/settings.json; общемашиинные — в ~/.claude/settings.json. Запустите /permissions — она перечислит каждое активное правило и файл настроек, откуда оно пришло.
- 2Файл уровнем выше запрещает. Значения перекрывают вниз, но deny любого уровня оценивается раньше allow, поэтому пользовательское allow не спасёт от проектного deny — а managed settings сильнее всего, включая флаги командной строки.
- 3Allow-правило ждёт доверия. deny и ask применяются сразу, а allow из закоммиченного проектного файла заработает лишь после того, как вы доверите папку workspace — намеренный шлюз для склонированных репозиториев.
- 4Режим попал в неправильный файл. Значения defaultMode auto и bypassPermissions игнорируются в проектных и локальных настройках (в документации отмечено: это изменение появилось в v2.1.257 — до него bypassPermissions работал из любого файла). Перенесите их в пользовательские или управляемые настройки либо используйте --permission-mode для одной сессии.