Как объясняла глава 1, Claude Code проходит ворота разрешений при каждом вызове инструмента. Если представлять это как одну ручку, то, как только станет шумно, вы выкрутите её в самое свободное положение. На деле их три, и у каждой своя работа: как часто вас спрашивают, разрешения по каждому инструменту и изоляция на уровне ОС. Затянув одно, можно позволить себе ослабить другое, так что «безопасно или быстро» — не выбор из двух.

Делегирование — не «всё или ничего»

Отправная точка не в названии режима, а в вопросе «в этой работе где именно заканчивается обратимость?». Ответ дают три вещи.

  • Можно ли отменить — правка, которую откатит git, стоит немного. Безвозвратное удаление, force push, разрушенная база данных не отменяются
  • Насколько далеко достаёт — остаётся внутри рабочего каталога или дотягивается до боевой среды, общей ветки, чужого окружения?
  • Затрагивает ли секреты — утечка происходит, когда одновременно выполняются возможность их прочитать и возможность отправить их наружу

Утомляют как раз те операции, что безопасны по всем трём осям (тесты, форматирование, локальные правки), а опасные почти не встречаются. Ослабив всё разом, вы открываете и опасную сторону. Каркас такой: ослаблять по частоте, затягивать по природе операции.

Режимы разрешений: что меняется на самом деле

Самая крупная ручка — режим разрешений, он задаёт общую частоту запросов. Перебирается по Shift+Tab (разбор — в статье Режимы разрешений в Claude Code).

Manual (default)

Чтение проходит автоматически, правки и выполнение команд подтверждаются каждый раз. Для незнакомого репозитория. Стартовый режим на Enterprise, с API-ключами и в похожих случаях.

Accept edits (acceptEdits)

Автоматически согласует правки внутри рабочей папки и частые файловые команды вроде mkdir и rm. Всё за её пределами, защищённые пути и прочие команды по-прежнему требуют подтверждения.

Plan (plan)

Изучает, но исходники не правит. Вы согласуете план, и он переходит к исполнению.

Auto (auto)

Отдельная оценивающая модель смотрит на каждую операцию до её выполнения и останавливает только опасные. Стартовый режим в терминале и VS Code на любом тарифе начиная с v2.1.283 (раньше — только Pro, Max и Team). Есть условия использования.

Bypass permissions (bypassPermissions)

Пропускает почти все запросы и проверки безопасности. Только для изолированных окружений. Доступен, только если включён при запуске — специальным флагом или в пользовательских либо управляемых настройках.

Есть ещё dontAsk, задаваемый только в настройках и CLI: он выполняет только чтение и то, что разрешают ваши правила allow, а всё, что потребовало бы запроса, отклоняет.

Следите и за защищёнными путями. Запись в .git, .claude и в конфигурацию оболочки не согласуется автоматически ни в одном режиме, кроме Bypass permissions (в Auto её проверяет оценивающая модель; единственное исключение — Plan в терминальной сессии, запущенной с доступным обходом). Стартовый режим можно прописать в defaultMode в настройках, но auto и bypassPermissions в настройках проекта не действуют: черта проведена так, чтобы репозиторий не мог сам сократить запросы. Эти два значения прописывают в пользовательских или управляемых настройках.

Автоматический режим — не «ускоренный default»

Запросы почти исчезают, но ничто не остаётся без присмотра: оценивающая модель останавливает операции, выходящие за рамки вашей просьбы, операции с незнакомой инфраструктурой и операции, к которым подтолкнуло прочитанное содержимое. Легко проходят работа с файлами внутри рабочей папки и HTTP только на чтение. Останавливаются отправка конфиденциальных данных наружу, деплой в боевую среду и разрушительные операции git.

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

Почему в режиме обхода вас всё равно спрашивают

Вы передали --dangerously-skip-permissions, который должен был отключить подтверждения, а Claude всё равно спрашивает «можно это выполнить?» Ничего не сломалось. У разрешений два независимых слоя, и обход снимает только один из них (почему Claude просит разрешение даже в режиме обхода).

Слой 1: интерфейс разрешений на инструменты (снимается)

«Можно отредактировать этот файл?» — интерактивное окно, появляющееся прямо перед вызовом инструмента. Его показывает сама программа Claude Code.

Слой 2: собственное суждение Claude о безопасности (не снимается)

«Это изменит боевую базу данных, продолжать?» — проверка, приходящая текстом в разговоре. Она следует из принципов поведения модели, поэтому никакой флаг её не останавливает.

Отличают их по тому, интерфейс это или текст ответа. Слой 2 срабатывает примерно по тем же трём осям: необратимо, широко достаёт, высок риск для безопасности. На безвозвратном удалении, force push или миграции против боевой базы Claude останавливается даже при полностью открытых разрешениях.

Это устройство, а не дефект. Обход выдаёт ключ к использованию инструментов, а не ключ, отключающий суждение Claude. Слой 2 нельзя свести к нулю.

Частоту снизить можно. Пишите в CLAUDE.md только те предпосылки, которые вы можете утверждать как факт, и формулируйте просьбы конкретно: «удали файлы .log в /tmp/» вызывает меньше запросов, чем «наведи здесь порядок». Но обход — не ответ на «запросы надоели» (риски режима обхода и как пользоваться им безопасно).

Правила в settings.json: не отвечать на один и тот же запрос дважды

Если режим — это общая частота, то правила разрешений — исключения по каждому инструменту и каждой команде. Вы пишете в settings.json allow (без запроса) / ask (запрос каждый раз) / deny (запрещено) и делитесь этим файлом (настройка правил разрешений (allow/ask/deny)).

Разбор идёт в порядке deny → ask → allow, и побеждает первое совпадение; большая конкретность порядка не меняет: широкий deny на Bash(aws *) побеждает конкретный allow на Bash(aws s3 ls). Deny не может нести исключений. «Я разрешил, а меня всё равно спрашивают» — обычно просто другой ask, совпавший раньше. Поскольку ask вынуждает запрос даже в автоматическом режиме, именно туда относят операции, которые нельзя отменить.

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

У места хранения тоже есть иерархия. От сильного к слабому: управляемые настройки (перекрыть нельзя) → CLI → settings.local.json → settings.json → ~/.claude/settings.json. Но deny на любом уровне всегда побеждает allow на любом другом. В указателях пробел плюс * означает границу слова (Bash(ls *) совпадает с ls -la, но не с lsof).

От чего правила вас не защищают

Правило смотрит только на текст команды, которая вот-вот выполнится, и любой путь, выходящий за пределы этого текста, проходит мимо него.

  • Косвенный доступ остановить нельзя — deny на Read(.env) работает против встроенных файловых инструментов и против cat, но не работает против скрипта, который открывает файл
  • Запускатели окружений прячут своё содержимое — devbox run * и docker exec выполняют свои аргументы дословно, поэтому allow на Bash(devbox run *) разрешает и devbox run rm -rf .
  • Ограничивать URL через аргумент ненадёжно — перестановка или подстановка переменной проскакивает. Прочнее запретить curl и wget целиком и перечислить разрешённые направления через WebFetch(domain:)

Фраза «не читай .env» в CLAUDE.md правилом не является. CLAUDE.md меняет то, что Claude будет пытаться делать, но не меняет того, что ему позволено. Это меняют правила, режимы и хук PreToolUse из главы 6 (deny и ask разбираются независимо от того, что вернул хук).

Песочница: что она способна огородить, а что нет

Пути, до которых правила не дотягиваются, закрывает песочница: вместо вопроса «что подтверждать?» она заранее огораживает «докуда вообще можно дотянуться». Обеспечивает это ОС (ядро), а не Claude, поэтому граница не сдвигается, даже когда уже разрешённая команда делает больше, чем следует из её названия (полное руководство по песочнице Claude Code).

1. Изоляция файловой системы

Писать можно в рабочий каталог и временную папку, и больше никуда (исходная настройка). ~/.bashrc и системные области переписать нельзя.

2. Изоляция сети

Исходное состояние — запрет по умолчанию, нулевой список направлений. Подключение к новому домену вызывает запрос, а после записи в allowedDomains спрашивать перестают.

Эти две всегда идут вместе: если взять только одну, прочитанный секрет уйдёт наружу. Согласовывать можно двумя способами. Режим автоматического разрешения выполняет Bash внутри песочницы без запросов, а обычный режим разрешений изолирует и при этом всё равно пропускает запросы. Даже при автоматическом разрешении deny всегда в приоритете, rm, нацеленный на важный путь, подтверждается, и ask, заданный по содержимому, тоже вынуждает запрос.

Учтите, что «автоматических» тут два. Режим автоматического разрешения у песочницы означает «пропускаем, потому что граница ОС удерживает», а Auto (автоматический режим, auto) в системе разрешений — «пропускаем, потому что оценивающая модель проверила».

Сначала выясните, чего она не защищает

Песочница — не полная изоляция. Оставить это неясным и держать автоматическое разрешение включённым постоянно — самое опасное состояние из возможных.

  • Она покрывает только Bash и его дочерние процессы — встроенные Read, Edit и Write, MCP-серверы и хуки остаются снаружи (их контролируют правилами разрешений). Чтобы обернуть процесс целиком, используют @anthropic-ai/sandbox-runtime
  • Умолчание для чтения широкое — огораживается в основном запись, а ~/.ssh и ~/.aws/credentials в исходном виде доступны для чтения. Закрывайте их через denyRead
  • Излишне широкое разрешение и становится дырой — трафик оценивается по имени хоста, а зашифрованное содержимое по умолчанию не проверяется. Разрешив широкий домен, вы оставляете лазейку для утечки
  • Зависит от окружения — на macOS ничего дополнительно не нужно. Для Linux и WSL2 требуются bubblewrap и socat, а нативная Windows не поддерживается

Песочница — не стена, выстроенная против атакующего, а страховочная привязь, которая на порядок сокращает происшествия и неуправляемое поведение. Anthropic сообщала, что внутри компании безопасно сократила число запросов на разрешение на 84 %, но это отчёт о меньшем числе запросов, а не гарантия непробиваемости.

Происшествия случаются примерно в четырёх формах

Разложим механику заново, со стороны происшествий. Настройки выбирайте по тому, работают ли они против этих четырёх.

1. Разрушительные команды

rm вычищает путь, которого никто не ожидал; git push --force стирает чужую работу. Общее у них — невозможность отменить. Работают правила deny и ask плюс изоляция файловой системы. Надёжный ход — сложить операции, которые нельзя отменить, в ask.

2. Утечка секретов

Происшествием это становится, только когда может прочитать и может отправить выстраиваются вместе. Противодействие тоже из двух частей: не давать читать (deny на Read(.env), denyRead) и не давать отправлять (deny на curl и wget, узкий список разрешённых доменов). Одной из двух частей не хватит.

3. Дотягивание до другой ветки или другого окружения

То, что задумывалось как локальная правка одного файла, вырастает в push в общую ветку или деплой в боевую среду — эскалация операции. В обычном режиме на каждом шаге стоит запрос, но, открыв всё, вы сглаживаете эти ступени. Отправить push и деплой в ask — дешёвая страховка.

4. Указания, подложенные через прочитанные файлы

В README, задаче, веб-странице или PDF, которые читает Claude, могут быть подложены указания, адресованные Claude (внедрение в запрос, prompt injection). Даже если «отправь это на такой-то адрес» написано белым по белому, со стороны Claude это текст, входящий через ту же дверь, что и ваша просьба, а данные и указания сами по себе неразличимы.

Не работают здесь режим обхода (подложенный текст доходит до выполнения нетронутым) и запрет, записанный в CLAUDE.md (он не меняет того, что позволено). Работают граница на уровне ОС — нельзя записать туда, куда записать нельзя, и нельзя дотянуться туда, куда дотянуться нельзя — вместе с правилами deny. Подложенный текст невидим, поэтому не рассчитывайте его заметить: недоверенные материалы читайте с разрешениями, суженными только на эту сессию.

Что можно отдать и что нужно остановить

Приложите три оси, и черта ляжет так.

Можно отдать (кладём в allow)

Тесты, проверка типов, линтеры, сборка / правки внутри рабочего каталога / чтение и поиск / локальные коммиты

Нужно остановить (ask или deny)

Push и force push в общие ветки / деплой и миграции в боевой среде / чтение файлов с секретами / команды, отправляющие данные наружу / запись за пределы рабочего каталога

  • Выберите один повседневный режим. acceptEdits для однообразного редактирования, default для работы с чувствительным. Пропишите его в defaultMode
  • Ответили на один и тот же запрос трижды — переносите в allow. И наоборот: операция, при виде которой вы хоть раз подумали «рискованно», закрепляется в ask
  • Всё, что вы запретили в разговоре, считайте тем, что исчезнет.
  • Ослабляя одно, всегда затягивайте другое. Единственное состояние, которого нельзя создавать, — ни запросов, ни границы

Когда обход допустим. Внутри контейнера, виртуальной машины или раннера CI, который не жалко выбросить, если сломается, где примонтирован только рабочий каталог, а .env и SSH-ключи хоста туда не попадают. «Запросы мешают» — не причина. После работы обязательно прочитайте диф.

Всё, о чём шла речь здесь, сокращает происшествия; ничто из этого их не устраняет. И суждение слоя 2, и вердикты автоматического режима, и граница песочницы имеют формы, которые сквозь них проходят. Лучше всего работает сохранять состояние, из которого можно откатиться.

Итоги

  • Разрешения — это три слоя: режимы, правила и песочница. Оси — можно ли отменить, насколько далеко достаёт, затрагивает ли секреты, а правило — ослаблять по частоте, затягивать по природе операции
  • У разрешений два слоя. Обход снимает только интерфейс слоя 1, а проверка, приходящая текстом разговора, работает как задумано
  • Правила разбираются в порядке deny → ask → allow, побеждает первое совпадение; конкретность порядка не меняет
  • Правила смотрят только на строки. Этот зазор закрывает песочница, но она покрывает только Bash и его дочерние процессы, а умолчание для чтения широкое
  • Происшествия принимают четыре формы: разрушительные команды, утечка секретов, дотягивание до другого окружения и подложенные указания

Когда объём делегируемого определён, остаётся растить всё это под своё окружение. Переходите к главе 6 «Как его расширять».