Режимы прав

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

Что важно понять сначала

Правила разрешений применяет Claude Code, а не модель. Инструкция в CLAUDE.md «не делай git push» влияет на то, что Claude попытается сделать. Правило deny для Bash(git push *) влияет на то, что Claude Code позволит. Первое — просьба, второе — механизм. Для всего, что нельзя допустить, используйте механизм.

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

Режимы

В настройках режим «спрашивать обо всём» называется default, в интерфейсе — Manual. Остальные режимы отличаются тем, что выполняется без вопроса.

Даже в bypassPermissions не одобряются автоматически: инструменты с явным правилом ask, инструменты, требующие ответа человека, и удаление критичных путей вроде корня или домашней папки.

Про auto стоит сказать отдельно. На планах Pro, Max и Team это стартовый режим для интерактивных сессий: действия проверяет классификатор, а не вы, и он останавливает то, что похоже на выход за рамки задачи или обращение к незнакомой инфраструктуре. Организация может отключить этот режим настройкой disableAutoMode.

Как переключать

По ходу сессии — Shift+Tab. Цикл: default → acceptEdits → plan → снова default. Если сессия стартовала в auto, первое нажатие переводит в default. Режим bypassPermissions появляется в цикле только если сессия запущена с соответствующим флагом; dontAsk в цикле не бывает вовсе. Текущий режим виден в строке статуса.

При запуске — флаг --permission-mode:

claude --permission-mode plan
claude --permission-mode acceptEdits
claude -p "исправь ошибки линтера" --permission-mode dontAsk --allowedTools "Bash(pnpm lint *)" "Edit"

--dangerously-skip-permissions — то же, что --permission-mode bypassPermissions.

По умолчанию — permissions.defaultMode в файле настроек:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Где именно задавать, имеет значение. Значения auto и bypassPermissions из проектных файлов .claude/settings.json и .claude/settings.local.json не действуют — только из пользовательского ~/.claude/settings.json или из управляемых настроек организации. Остальные режимы можно задавать где угодно. Сделать plan стартовым для проекта, где новые люди часто ломают код, — нормальная практика.

Правила: allow, deny, ask

Правила лежат в settings.json в ключе permissions:

{
  "permissions": {
    "allow": [
      "Bash(pnpm run *)",
      "Bash(pnpm test *)",
      "Bash(git commit *)",
      "Read(./docs/**)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Edit(./src/generated/**)"
    ],
    "ask": [
      "Bash(pnpm publish *)"
    ]
  }
}

Приоритет строгий: deny побеждает всё, ask побеждает allow. Широкое deny вроде Bash(aws *) блокирует и то, что разрешено узким allow — исключения из запрета сделать нельзя.

Синтаксис правила — имя инструмента и шаблон в скобках:

• Bash(pnpm run *) — любая команда, начинающаяся с pnpm run. Пробел перед * важен: Bash(ls *) не совпадёт с lsof, а Bash(ls*) совпадёт.
• Bash(npm run build) — только эта команда.
• Звёздочку ставьте после подкоманды: Bash(git log *) разрешает все варианты git log, а Bash(git *) — вообще любой git, включая git push.
• Read(./.env), Edit(./src/generated/**) — файлы. Проверяются только правила Read и Edit; писать Write(...) бесполезно, используйте Edit.
• WebFetch(domain:docs.example.com) — запросы к домену.
• Голое имя инструмента в deny (например, "WebFetch") убирает инструмент из контекста модели целиком.

Claude Code понимает составные команды: правило Bash(pnpm test *) не разрешит pnpm test && rm -rf dist, потому что каждая часть проверяется отдельно. Зато он снимает безобидные обёртки: timeout 30 pnpm test совпадёт с тем же правилом.

Управлять правилами удобнее через /permissions: диалог показывает все правила и файл, из которого каждое пришло. Когда вы в ответ на запрос выбираете «да, и больше не спрашивай», правило сохраняется в .claude/settings.local.json в корне репозитория.

Где лежат настройки и что важнее

Запрет на любом уровне не может быть снят на другом: deny в пользовательских настройках блокирует allow в проектных и наоборот. Команда может закоммитить в .claude/settings.json общий список: разрешить скрипты pnpm, запретить git push и чтение .env. Каждый разработчик добавит своё в локальный файл.

Пример командного файла для веб-проекта агентства:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(pnpm install)",
      "Bash(pnpm run *)",
      "Bash(pnpm test *)",
      "Bash(pnpm lint *)",
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "WebFetch(domain:nextjs.org)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Edit(./src/generated/**)",
      "Edit(./prisma/migrations/**)"
    ]
  }
}

Здесь Claude свободно правит код, ставит зависимости, гоняет тесты и коммитит, но не может отправить ветку, затереть историю, прочитать секреты или руками править миграции и сгенерированный код.

Когда «пропустить все проверки» допустимо

--dangerously-skip-permissions соблазнителен: никаких вопросов. Документация формулирует условие однозначно: только в изолированной среде — контейнере, виртуалке, специальной песочнице, — где Claude Code не может причинить вред, и под пользователем без прав администратора. В этом режиме Claude может писать даже в защищённые пути вроде .git и .claude.

Для сценариев «оставить на ночь» есть лучшие варианты. Режим dontAsk с точным списком allow — Claude делает ровно то, что разрешено, и молча отклоняет остальное. Режим auto — классификатор фильтрует опасное. Комбинация acceptEdits плюс allow для команд сборки и тестов покрывает почти всё, что нужно для миграции или обновления зависимостей.

Если организация хочет запретить обход совсем, есть настройка permissions.disableBypassPermissionsMode со значением "disable". Её ставят в управляемые настройки, где она не переопределяется.

Как хуки дополняют правила

Правила описывают шаблоны команд, но не могут проверить содержимое. «Разрешить rm, кроме удаления папки photos/» шаблоном не записать. Для этого есть хук PreToolUse: он видит полную команду, может её проверить скриптом и заблокировать. Хук срабатывает до проверки прав, в любом режиме, включая bypassPermissions. При этом ослабить правила хук не может: если deny совпал, вызов заблокирован независимо от решения хука. Хуки ужесточают, но не расширяют. Подробно — в следующем уроке.