Разрешения и режимы разрешений

Средний

Последняя проверка: 2026-07-14.

Точный синтаксис правил и имена режимов развиваются — сверяйтесь с официальной документацией Claude Code по разрешениям и режимам разрешений.

Сверьтесь с официальным источником.

What you'll learn

• Что означают три вердикта разрешений (allow / ask / deny)
• Как правила разрешений сопоставляются с инструментом плюс шаблоном
• Шесть режимов разрешений и когда использовать каждый из них
• Как режим auto заменяет запросы классификатором безопасности
• Как составить разумный стартовый allowlist, который сокращает запросы без потери безопасности
• Где хранить правила разрешений для проекта и личные

Разрешения решают, что Claude Code может делать, не останавливаясь, чтобы спросить вас. Настройте их хорошо — и получите поток без потери контроля; настройте плохо — и вы либо штампуете подтверждение всему подряд, либо тонете в запросах.

Три вердикта

Каждое потенциальное действие сводится к одному из:

Нажмите Enter или пробел, чтобы перевернуть карточку. Используйте стрелки влево и вправо для перехода между карточками.Показан термин.

1 / 3

Правила обычно сопоставляются с инструментом плюс шаблоном, например allow Bash(npm run test:*) или deny Read(./.env).

Разрешить инструмент + шаблон

Bash(npm run test:*)

Запретить инструмент + шаблон

Read(./.env)

Режимы разрешений

Режим задаёт общую позицию для сессии. Их шесть. Переключайте распространённые из них с помощью Shift+Tab или задайте permissions.defaultMode в настройках.

Режим	Выполняется без запроса	Когда использовать
default (отображается как Manual)	Только чтение	Повседневная работа, чувствительные изменения
acceptEdits	Чтение, правки файлов, распространённые команды файловой системы	Доверенная, хорошо ограниченная сессия редактирования
plan	Только чтение; предлагает, никогда не редактирует	Большие/рискованные задачи — см. Режим планирования
auto	Всё, отфильтрованное классификатором безопасности	Долгие задачи, где настоящий риск — усталость от запросов
dontAsk	Только предварительно одобренные инструменты; всё остальное запрещено	Заблокированные CI и скрипты
bypassPermissions	Всё, без проверок	Только песочницы/контейнеры — никогда на машине с секретами

Режим auto

auto — это золотая середина между запросами на всё подряд и полным отключением безопасности. Вместо того чтобы спрашивать вас, отдельная модель-классификатор проверяет каждое действие перед его выполнением и блокирует всё, что выходит за рамки того, о чём вы просили, затрагивает незнакомую ей инфраструктуру или выглядит продиктованным враждебным содержимым, которое Claude только что прочитал. Явные правила ask по-прежнему останавливаются и спрашивают вас.

Он блокирует такие вещи, как curl | bash, принудительные push, продакшен-деплои и миграции, а также отправку секретов на внешние эндпоинты — при этом пропуская рутинную работу (локальные правки, установку объявленных зависимостей, HTTP-запросы только на чтение, push в вашу собственную ветку). Если он блокирует одно и то же действие несколько раз подряд, режим auto приостанавливается и возвращает запросы вам.

Режим auto — не гарантия безопасности: он сокращает запросы, но не отменяет необходимость проверять чувствительные операции. Доступность зависит от вашего плана, модели и (в Team/Enterprise) от переключателя администратора.

Watch out

• bypassPermissions — место в песочнице. Запуск с полностью отключёнными запросами на вашей реальной машине — это путь к тому, что агент тронет что-то, что не должен. Оставьте это для одноразовых сред — а если вам на самом деле нужно меньше запросов, используйте вместо этого режим auto. См. «Усиление защиты автономных запусков» по адресу /docs/security/hardening-autonomous-runs.

Разумный стартовый allowlist

Цель: заранее разрешить безопасные, повторяющиеся действия; держать разрушительные действия на ask или deny.

Guided walkthrough1 of 3

1. Чтение файлов, запуск ваших команд тестирования/линтинга/сборки, git status/diff.

Храните правила проекта в settings.json (общие), а личные переопределения — в settings.local.json.

Pro tip

• Пусть учится на ваших запросах: подтвердите одну и ту же безопасную команду несколько раз — и вы точно будете знать, что добавить в ваш allowlist, превратив повторяющиеся запросы в одноразовое правило.

Key takeaways

• Три вердикта: allow (без запроса), ask (по умолчанию — приостановиться и подтвердить), deny (никогда).
• Правила сопоставляются с инструментом плюс шаблоном, например Bash(npm run test:*) или Read(./.env).
• Шесть режимов задают позицию сессии: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
• Режим auto пропускает каждое действие через классификатор безопасности вместо того, чтобы спрашивать вас, — именно он лекарство от усталости от запросов, а не bypassPermissions.
• Составьте allowlist: разрешите безопасное и повторяющееся, спрашивайте для среднего риска, запрещайте разрушительное.
• Общие правила идут в settings.json; личные переопределения — в settings.local.json.

Проверь себя

0/5

1. 1Что делает вердикт по умолчанию 'ask' для действия, которое явно не разрешено и не запрещено?
2. 2Какой режим разрешений безопасен ТОЛЬКО в песочницах или контейнерах, но никогда на машине с секретами?
3. 3Вам нужно гораздо меньше запросов разрешений в долгой задаче, но вы всё же хотите подстраховку. Какой режим?
4. 4Где следует хранить общие правила разрешений проекта по сравнению с личными переопределениями?
5. 5Что из перечисленного относится к списку 'deny' в разумном стартовом allowlist?

Дальше

• settings.json: система конфигурации
• Хуки — обеспечивайте правила детерминированно, за пределами allow/deny
• Безопасность и ответственное использование