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

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

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

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

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

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

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

Спрашивать разрешение (default)

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

Принимать правки (acceptEdits)

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

Режим планирования (plan)

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

Автоматический режим (auto)

Отдельная оценивающая модель смотрит на каждую операцию до её выполнения и останавливает только опасные. Есть условия использования.

Обход разрешений (bypassPermissions)

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

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

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

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

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

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

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

Вы передали --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, заданный по содержимому, тоже вынуждает запрос.

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

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

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

  • Она покрывает только 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 «Как его расширять».