Claude Code --dangerously-skip-permissions: что делает флаг и когда не использовать

Claude Code --dangerously-skip-permissions не стоит воспринимать как обычный флаг для экономии кликов. В текущей модели разрешений он соответствует --permission-mode bypassPermissions: Claude Code продолжает выполнять действия без обычного слоя подтверждений. Это касается правок файлов, запуска команд, сетевых запросов и других шагов с побочными эффектами. Практическое правило на 7 мая 2026 года простое: не включайте полный обход на обычной рабочей машине, в репозитории с реальными секретами или там, где терминал может деплоить, удалять данные, менять инфраструктуру или трогать биллинг.

Сначала нужно понять, какую проблему вы решаете. Если устали подтверждать предсказуемые правки, начните с acceptEdits. Если работа длинная, повторяемая и подходит под ограничения аккаунта, версии, модели и поверхности, проверьте Auto mode. Если репозиторий незнакомый, задача расплывчатая или цена ошибки велика, оставайтесь в обычном режиме или используйте plan. Полный bypass имеет смысл только там, где среда одноразовая: нет производственных ключей, нет доступа к внутренней сети, нет полномочий деплоя и весь результат можно увидеть в diff.

Быстрый выбор:

• Незнакомый код или неясный радиус влияния: default или plan.
• Много рутинных правок, но команды должны проверяться: acceptEdits.
• Долгая низкорисковая работа внутри репозитория: Auto mode, если он доступен.
• Есть секреты, прод, база данных, облачные права или деплой: не обходить подтверждения.
• Среда изолирована, одноразовая и не имеет настоящих полномочий: только тогда обсуждать bypassPermissions.

Быстрый ответ: что именно отключает этот флаг

В актуальной документации Claude Code по режимам разрешений флаг --dangerously-skip-permissions описывается как эквивалент --permission-mode bypassPermissions. Он не делает модель умнее и не повышает качество решений. Он меняет контрольную поверхность: действия, которые раньше останавливались перед пользователем, начинают проходить без этой остановки.

Обычный запрос подтверждения появляется там, где есть что проверить: путь записи, shell-команда, сетевой вызов, изменение конфигурации, установка зависимости, запуск скрипта. Это раздражает, но это также дешевый человеческий контроль. Именно там вы замечаете вопросы вроде: почему сессия смотрит в .env, почему команда идет в сеть, почему задача документации внезапно запускает деплой, почему правится сгенерированный файл.

Поэтому выбор режима должен идти перед синтаксисом:

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

Лестница режимов: поднимайтесь только на нужную ступень

Лучше думать не в терминах "включить или выключить вопросы", а в терминах лестницы риска. На нижней ступени обычный режим: Claude Code спрашивает перед действиями с последствиями. Для незнакомого кода, миграций, конфигурации, зависимостей, безопасности и диагностики это не бюрократия, а способ увидеть намерение перед тем, как оно станет изменением.

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

acceptEdits часто решает настоящую боль. Вы разрешаете Claude Code вносить ожидаемые правки в файлы, но не отдаете без проверки команды, сетевые действия и потенциально дорогие инструменты. Для документации, тестов, типизации, локальных рефакторингов и чистки очевидных ошибок это обычно лучше, чем полный bypass.

Auto mode занимает середину. Он создан для случаев, где пользователи часто подтверждали однотипные действия, но полный обход был слишком открыт. Его нельзя описывать как вечное свойство всех установок Claude Code: доступность зависит от версии, плана, модели, provider и поверхности. Проверяйте текущий список режимов в собственной среде.

dontAsk и bypassPermissions требуют замедлиться. Это не знак экспертности, а более широкий договор доверия. Чем меньше вопросов задает инструмент, тем больше работы должна делать среда: изоляция файловой системы, сеть, отсутствие секретов, запрет деплоя, понятный откат.

Красные линии: где bypass не должен использоваться

Полный обход не подходит для задач, которые могут повредить общий контур, раскрыть секрет, изменить деньги или создать необратимое состояние. Дело не в том, что Claude Code особенный риск. Любой агент с shell, файловой системой и сетью может дорого ошибиться, если неверно понял инструкцию, прочитал вредный файл, запустил не тот скрипт или получил слишком широкие права.

Не используйте bypass для таких категорий:

• production deploy, rollback, restart сервиса, promotion релиза;
• миграции баз данных, destructive query, массовое изменение данных;
• Terraform, IAM, облачные ресурсы, права репозитория, биллинг;
• поиск токенов, ротация секретов, отладка .env, credential cleanup;
• запуск скачанного кода, неизвестные install scripts, curl | bash, бинарники без проверки;
• force push, прямой push в защищенную ветку, массовое удаление;
• любая среда, где доступны реальные ключи, cloud CLI, SSH или браузерная сессия администратора.

Официальные блокировки Auto mode отражают тот же принцип: скачанный код, production-действия, миграции, exfiltration, массовое удаление в облаке, IAM, репозиторные права, shared infrastructure, irreversible destruction и прямой push в main требуют контроля. Даже если конкретная версия оставляет аварийный circuit breaker, нельзя проектировать безопасность вокруг последнего стоп-крана.

Практичная командная политика должна быть явной. Обход не запускается на основной ветке, не запускается при грязном diff без снимка состояния, не запускается при наличии переменных с ключами, не запускается там, где package scripts содержат deploy, release, migrate или publish. Это лучше, чем надеяться, что все вспомнят устное предупреждение.

Чек-лист изоляции перед обходом подтверждений

Документация Claude Code по sandboxing подчеркивает две оси: файловая система и сеть. Новый branch не является sandbox. Docker тоже не является sandbox, если в него примонтирован домашний каталог, доступны реальные секреты, есть исходящий доступ во внутренние сервисы или установлены cloud CLI с авторизованными профилями.

Минимальный чек-лист должен быть проверяемым:

Подготовка может выглядеть просто:

bash
git status --short
git worktree add ../tmp-claude-bypass-work -b claude-bypass-test
cd ../tmp-claude-bypass-work

Перед скоростью уберите полномочия:

bash
env | grep -E 'TOKEN|KEY|SECRET|AWS|GCP|AZURE|ANTHROPIC|OPENAI'
ls -la | grep -E '\.env|credentials|secrets'
git diff --stat

Если проверка показывает реальные ключи или широкий доступ, сессию нельзя просто "аккуратно" запускать. Нужно сузить среду до состояния, где неверная команда может испортить только временную копию. Полный bypass оправдан не доверием к модели, а дешевизной ошибки.

Поверхности: CLI, IDE, Remote Control, облако и CI различаются

Локальный CLI легче всего проверять: там видны флаги запуска, список режимов и команда /permissions. IDE, Remote Control, cloud sessions и non-interactive runs добавляют собственные ограничения. Если опция не видна в одной поверхности, это не означает, что основной CLI-контракт изменился.

Remote Control нужен для удаленного надзора: одобрить, отклонить, изменить направление. Это противоположность невидимого автоматического выполнения. Auto mode нужен для части длинных задач, где меньше подтверждений допустимо, но классификатор и ограничения остаются. Полный bypass остается локальным решением для одноразовой среды.

Команды после проверки границ

После выбора режима синтаксис короткий:

bash
claude --permission-mode bypassPermissions

Рыночный alias выглядит так:

bash
claude --dangerously-skip-permissions

Первый вариант лучше для новых runbook, потому что совпадает с языком permission modes. Второй нужен для воспроизведения старых scripts, issues или инструкций коллег. Внутри команды их нужно явно связать, чтобы никто не думал, будто это разные уровни безопасности.

Проверьте версию и доступные флаги:

bash
claude --version
claude --help

Внутри сессии проверьте режим:

text
/permissions

Если режим менялся во время работы, оставьте это в заметке, commit message или review context. Опаснее всего невидимый переход: reviewer видит diff, но не знает, в какой момент сессия перестала задавать вопросы.

Версионные детали тоже нужно датировать. Проверенные 7 мая 2026 года docs описывали изменения вокруг protected paths в v2.1.126 и отдельные circuit-breaker prompt для root/home deletion. Не превращайте это в постоянную гарантию. Правильный ответ: не давать сессии опасную файловую область с самого начала.

Troubleshooting: почему режим не появляется или все еще спрашивает

Начинайте с поверхности. Cloud sessions и Remote Control не обязаны вести себя как локальный CLI. IDE может скрывать или ограничивать advanced controls. Non-interactive scripts могут запускаться с другим config и shell environment.

Потом проверьте версию, план, модель и provider. Особенно это важно для Auto mode: он часто воспринимается как "почти bypass", но на деле имеет отдельные условия доступности. Если Auto не виден, это может быть eligibility issue, а не поломка permission modes.

Третья проверка: не путайте circuit breaker с обычными permission prompts. Если крайнее удаление все еще остановлено, это не делает полный bypass безопасным. Это лишь последний аварийный барьер. Среда должна быть такой, чтобы сессия не доходила до опасной зоны.

Четвертая проверка: managed settings. Организация может включать allowlists, denylists, dev containers, audit policy и другие правила. Если они сужают поведение, не надо обходить их повышением режима. Надо согласовать рабочий процесс с политикой.

Если Claude Code продолжает выбирать опасные действия, снижайте режим. plan заново фиксирует объем, acceptEdits решает усталость от правок, Auto mode может подойти для повторяемой работы. Полный bypass не должен быть способом спорить с осторожным инструментом.

Часто задаваемые вопросы

Это то же самое, что bypassPermissions?

Да. Текущие permission-mode docs связывают --dangerously-skip-permissions с --permission-mode bypassPermissions. Запишите это в командных инструкциях, чтобы старый флаг не выглядел как отдельный скрытый режим.

Docker делает это безопасным?

Только если контейнер действительно изолирован. Host mounts, доступная сеть, реальные credentials, cloud CLIs и production endpoints делают контейнер обычной опасной средой.

Если мне надо меньше подтверждений, что выбрать?

Чаще всего acceptEdits или Auto mode. Первый убирает лишние паузы для правок, второй подходит части длинных низкорисковых задач. Оба уже, чем полный bypass.

Защищает ли bypass от prompt injection?

Нет. В документации прямо указано, что bypassPermissions не защищает от prompt injection или unintended actions. Если внешние файлы, зависимости или README могут влиять на сессию, обзорный зазор только увеличивается.

Можно ли включить его в CI?

Не как общий дефолт. CI часто имеет secrets, deploy permissions, package publishing и shared infrastructure. Для unattended work лучше narrow scripts, dry run, explicit approvals и sandbox без права публиковать или удалять.

Самое надежное правило?

Используйте самый слабый режим, который решает реальную боль. Правки ускоряйте acceptEdits, длинные подходящие задачи проверяйте через Auto, полный bypass оставляйте только для одноразовой изоляции без ценных полномочий.