Режимы доступа и разрешения Claude Code: как не дать агенту снести полсистемы

Коротко (TL;DR)

Claude Code — агент, который умеет сам править файлы и запускать команды в терминале. Логичный вопрос: как решать, что ему можно без спроса, а что нет? Ответ — режимы доступа. Их несколько, и путаница между ними приводит к двум крайностям: либо вы устаёте подтверждать каждый шаг, либо в порыве «пусть работает сам» снимаете все проверки и однажды теряете данные.

Коротко расклад по режимам, между которыми переключаются клавишей Shift+Tab: Manual (default) — спрашивает перед каждой правкой и командой; acceptEdits (auto-accept) — сам принимает правки файлов; plan — только читает и планирует, ничего не меняет; auto — отдельный классификатор пропускает безопасное и блокирует опасное; bypassPermissions, он же «YOLO» через флаг --dangerously-skip-permissions — не спрашивает вообще ничего.

И отдельно стоит sandbox — это не режим, а слой изоляции: он ограничивает, что запущенная команда может достать на диске и в сети. Его можно комбинировать с любым режимом.

Эта статья для тех, кто уже освоил базовый метод работы с Claude Code и хочет настроить доступ осознанно. Ниже — что делает каждый режим, чем реально опасен YOLO (с задокументированным инцидентом), и матрица «какой режим под какой сценарий».

Как переключать режимы: Shift+Tab и статус-бар

Основной способ сменить режим прямо в сессии — клавиша Shift+Tab. Она циклически перебирает режимы: default (Manual) → acceptEdits → plan, а если вы включили дополнительные режимы, они встраиваются в цикл после plan (bypassPermissions, затем auto). Текущий режим всегда виден в статус-баре внизу — например, ⏵⏵ accept edits on для acceptEdits. Плюс plan mode можно включить командой /plan или запуском claude --permission-mode plan.

Создатель ИИ-агента Hermes Nous Research ведёт переговоры о раунде при оценке $1,5 млрд

Инженер Anthropic заставил Claude спроектировать стойку под кластер материнок Framework

Что показало и чего не показало новое исследование интерпретируемости Anthropic

Слэш-команды Claude Code: полная шпаргалка и разбор /effort, /config, /resume и /compact

Метод работы с Claude Code: как водить агента, чтобы получать хороший результат

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

Manual (default): спрашивает перед каждым действием

Режим по умолчанию — самый безопасный. По состоянию на июль 2026 в интерфейсе он называется Manual (значение в конфиге — default). Без подтверждения проходят только операции чтения; любая правка файла или запуск bash-команды требуют вашего явного «да».

Это правильная точка старта, особенно если вы только осваиваете инструмент или работаете с боевым проектом. Минус очевиден и известен как «усталость от подтверждений» (approval fatigue): на большой задаче вы жмёте «разрешить» десятки раз. Именно эта усталость толкает людей к опасным режимам — и на неё же Anthropic отвечает более умными режимами, о которых ниже.

acceptEdits (auto-accept): сам принимает правки

Режим acceptEdits — то, что в интерфейсе называют «auto-accept edits». Включается тем же Shift+Tab, статус-бар показывает ⏵⏵ accept edits on. Он автоматически одобряет правки файлов — и это ускоряет работу, когда вы уже доверяете направлению.

Тонкость, которую упускают почти все гайды: acceptEdits авто-одобряет не только правки файлов, но и фиксированный набор безопасных файловых команд — mkdir, touch, rm, rmdir, mv, cp, sed — но только в пределах рабочей директории. Все прочие bash-команды по-прежнему потребуют подтверждения. То есть это «доверяю правкам в проекте», а не «делай что угодно».

plan mode: только смотрит, ничего не меняет

Режим планирования — зеркальная противоположность. В нём Claude физически не может редактировать файлы: доступны только чтение и безопасное read-only исследование. Он изучает код, отвечает на вопросы и предлагает план — но не трогает ничего, пока вы не одобрите.

Когда план готов, Claude предлагает варианты продолжения: одобрить и перейти в авто-режим, одобрить с автопринятием правок, одобрить с ручным подтверждением каждого шага или доработать план. Это ключевой инструмент для незнакомого кода и рискованных изменений — именно с plan mode начинается правильный рабочий цикл Explore → Plan → Code.

auto mode: классификатор вместо ваших подтверждений

auto — самый свежий и, пожалуй, самый интересный режим (на июль 2026 — research preview). Вместо того чтобы спрашивать вас, он подключает отдельную модель-классификатор, которая проверяет каждое действие перед выполнением и блокирует потенциально опасные категории: curl | bash, продакшн-деплои и миграции, массовое удаление в облачных хранилищах, terraform/pulumi destroy и подобное. Явно заданные ask-правила при этом всё равно вызывают запрос.

У режима есть встроенный предохранитель: если классификатор блокирует действие 3 раза подряд или 20 раз за сессию, auto приостанавливается и возвращаются обычные подтверждения. В неинтерактивном режиме (-p) повторные блокировки вместо этого прерывают выполнение — подтвердить-то некому.

Позиционируется auto именно как «средний путь» между изматывающим Manual и безрассудным YOLO: намного меньше промптов, но без полного отключения проверок. Честная оговорка: research preview официально «не гарантирует безопасность» — это снижение трения, а не замена изоляции для по-настоящему недоверенных задач.

YOLO: —dangerously-skip-permissions и чем он реально опасен

«YOLO-режим» — разговорное название флага --dangerously-skip-permissions, технически идентичного режиму bypassPermissions. Он пропускает вообще все запросы разрешений: остаются только явные ask-правила и защитный предохранитель на rm -rf / и rm -rf ~. Соблазн понятен — ноль подтверждений, агент летит. Цена ошибки — тоже реальна.

Официальная документация формулирует прямо: bypassPermissions «не даёт никакой защиты от prompt injection или непреднамеренных действий», и использовать его следует исключительно в изолированных контейнерах или виртуальных машинах. Есть и нюанс версий: начиная с v2.1.126 в этом режиме перестала действовать защита «защищённых путей» (.git, .claude и др.) — раньше запись в них требовала подтверждения даже в bypass. То есть в YOLO агент может незаметно переписать собственный конфиг, git-хуки или CI-скрипты.

И это не теория. В декабре 2025 задокументирован реальный случай: в YOLO-режиме Claude выполнил команду вида rm -rf tests/ patches/ plan/ ~/, где хвостовое ~/ развернулось в весь домашний каталог пользователя. Были удалены файлы рабочего стола, данные приложений и содержимое связки ключей. Случай активно обсуждался на Hacker News. Без sandbox или контейнера ничего не остановило выполнение — в этом вся суть предупреждения про необратимость.

На Linux и macOS Claude Code вообще отказывается стартовать в bypassPermissions от имени root или через sudo — из соображений безопасности. Проверка снимается только внутри распознанного sandbox.

Sandbox: это не режим, а отдельный слой изоляции

Здесь главная концептуальная ошибка новичков: sandbox путают с ещё одним «режимом». Это не так. Permission mode решает, нужно ли спросить перед запуском. Sandbox решает, что уже запущенная команда физически достанет на диске и в сети. Это два независимых слоя, и их можно комбинировать — вплоть до sandbox поверх bypassPermissions.

Технически встроенный sandboxed Bash tool изолирует Bash-команды и их дочерние процессы: на macOS через Seatbelt (ничего ставить не нужно), на Linux и WSL2 — через пакеты bubblewrap и socat. Нативный Windows не поддерживается — там нужен WSL2. По официальному анонсу Anthropic от 20 октября 2025, sandbox безопасно сокращает число permission-промптов на 84% за счёт связки файловой изоляции (доступ только к определённым директориям) и сетевой (подключение только к одобренным серверам).

Две честные оговорки, о которых стоит знать:

• Sandbox покрывает только Bash. Встроенные инструменты Read/Edit/WebFetch, MCP-серверы и хуки работают напрямую на хосте и sandbox им не защищён. Если нужна полная изоляция — оборачивайте весь процесс в контейнер, VM или sandbox-runtime.
• Сеть по умолчанию не инспектирует TLS. Прокси решает только по имени хоста, поэтому широкий разрешённый домен (например, github.com) теоретически обходим техникой domain fronting для эксфильтрации данных. Ответственность за узость allowlist — на вас.

Три слоя защиты: как это собирается вместе

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

deny— и ask-правила действуют всегда, даже в bypassPermissions — поэтому запрет на git push или git push --force продолжит защищать вас в любом режиме. Управление командами и настройкой правил — тема статьи про слэш-команды Claude Code (/permissions, /config).

Правила разрешений на практике

Правила задаются в settings.json тремя списками. allow — что разрешено без вопроса, ask — что всегда требует подтверждения, deny — что запрещено вообще. Именно deny — ваша страховочная сетка даже в самых свободных режимах. Минимальный разумный набор для автономной работы выглядит так: разрешить чтение и тесты, но жёстко запретить необратимые операции.

Например, deny-правило на git push, git push --force и rm -rf не даст агенту случайно отправить полусырой код в удалённый репозиторий или снести директорию, даже если вы работаете в acceptEdits или bypassPermissions. Это дешёвая защита, которая срабатывает раньше, чем режим доступа успевает «пропустить» команду. Практика сообщества сходится на одном: перед автономным прогоном всегда делайте git-коммит-чекпойнт и держите deny-список актуальным — тогда любой сбой откатывается одним git reset, а не восстановлением из бэкапов.

Отдельно стоит помнить про рабочие директории: acceptEdits авто-одобряет файловые операции только внутри рабочей папки и явно добавленных additionalDirectories. Всё за их пределами — за пределами вашего проекта — всё равно требует подтверждения, и это правильно: агент не должен незаметно трогать соседние репозитории или системные файлы.

Сводная таблица режимов

Как выбрать режим под задачу

Практическое дерево решений, которое стоит держать в голове:

• Соло-разработка на своей машине → acceptEdits или auto. Быстро, но с сеткой безопасности.
• Ревью чужого или непроверенного кода → plan + sandbox. Сначала понять, что происходит, и ограничить, что команда достанет.
• CI или пайплайн без человека → dontAsk с явными allow-правилами: всё, что не разрешено, автоматически отклоняется.
• Полностью автономный прогон агента без присмотра → bypassPermissions, но только внутри контейнера, VM или sandbox-runtime, с deny-правилами на опасные git-операции и git-коммитом-чекпойнтом перед стартом.

Слабые места и подводные камни режимов

Честный список рисков, которые стоит держать в голове:

• YOLO с v2.1.126 снимает защиту даже с .git/.claude — агент может переписать конфиги и хуки. Митигация: deny-правила на git push/--force, отдельный некорневой пользователь, обязательный контейнер.
• Реальная потеря данных возможна — задокументированный кейс с rm -rf ~/ тому доказательство. Держите git-чекпойнт и не запускайте YOLO вне изоляции.
• Sandbox защищает не всё — MCP, хуки и не-Bash инструменты остаются вне его; ложное чувство полной изоляции опасно.
• Сеть sandbox не инспектирует TLS — сужайте allowlist доменов вручную.
• auto mode — research preview и «не гарантирует безопасность»: не замена контейнеру для недоверенных задач.
• Поведение зависит от версии. Имена и пороги (Manual с v2.1.200, protected paths с v2.1.126) меняются — сверяйтесь с актуальной документацией на дату работы.

FAQ

Как быстро переключить режим прямо в сессии? Клавишей Shift+Tab — она циклически перебирает Manual → acceptEdits → plan (и включённые auto/bypassPermissions). Текущий режим виден в статус-баре внизу. Plan mode ещё включается командой /plan.

Что такое YOLO-режим и когда его вообще можно включать? YOLO — это флаг --dangerously-skip-permissions (режим bypassPermissions), снимающий почти все проверки. Официально его допустимо использовать только в изолированном контейнере, VM или sandbox без выхода в интернет. На обычной рабочей машине это прямой риск потери данных.

Sandbox — это отдельный режим доступа? Нет. Sandbox — независимый слой изоляции: он ограничивает, что запущенная Bash-команда достанет на диске и в сети, и комбинируется с любым режимом доступа. Режим решает «спросить ли перед запуском», sandbox — «что команда сможет после запуска».

Чем auto mode отличается от YOLO? Auto проверяет каждое действие отдельным классификатором и блокирует опасное, тогда как YOLO разрешает всё без разбора. Auto — «средний путь» с сеткой безопасности, но он в статусе research preview и не гарантирует безопасность для недоверенных задач.

Защищает ли sandbox от prompt injection полностью? Нет. Sandbox снижает урон от Bash-команд, но не покрывает MCP-серверы, хуки и не-Bash инструменты, а сеть по умолчанию не инспектирует TLS. Для действительно недоверенных задач нужны контейнер или VM плюс узкий сетевой allowlist.