Вы указали флаг --dangerously-skip-permissions в Claude Code, но Claude всё равно присылает сообщение в чат: «Можно выполнить эту операцию?» Знакомо?

Первый порыв — решить, что «bypass не работает», — но дело не в этом. Система разрешений Claude Code состоит из двух независимых уровней, а режим bypass управляет только одним из них.

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

1. Что такое «bypass» в первую очередь?

В программировании «bypass» означает пропуск обычного потока подтверждения или согласования для немедленного продолжения. Представьте кнопку «купить сейчас» в интернет-магазине, которая пропускает экран проверки — это и есть bypass потока подтверждения.

В режиме Manual (значение в настройках default) Claude Code перед любым редактированием файла или выполнением команды shell показывает диалог подтверждения. Однако начиная с Claude Code v2.1.283 сессии в терминале и VS Code на любых планах и у любых провайдеров по умолчанию запускаются в режиме Auto, где большинство действий вместо вас проверяет классификатор (в более ранних версиях — только на планах Pro, Max и Team; если администратор отключил режим auto или модель его не поддерживает, сессия начинается в Manual).

# Режим Manual: подтверждение перед каждым действием
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / No

Режим обхода разрешений пропускает (обходит) этот поток подтверждения.

# Режим bypass: почти без диалогов подтверждения
$ claude --dangerously-skip-permissions
# or
$ claude --permission-mode bypassPermissions

Обратите внимание: флаг содержит слово dangerously. Anthropic позиционирует этот режим как предназначенный исключительно для контейнеров или изолированных сред — для повседневной локальной разработки он не рекомендуется. Подробный разбор рисков режима bypass см. в статье Режим bypass Claude Code: риски и безопасное использование.

Если диалоги подтверждения всё равно появляются часто, сначала проверьте, действительно ли вы работаете в режиме bypass. Пока он активен, в строке состояния терминала отображается ⏵⏵ bypass permissions on. Если этой надписи нет, обычно причин две.

  • Вы указали его в настройках проекта: значение bypassPermissions в defaultMode в файлах .claude/settings.json или .claude/settings.local.json не действует, и сессия запускается в режиме Manual (начиная с v2.1.257). Укажите его в пользовательских настройках (~/.claude/settings.json) или в управляемых настройках либо передайте флаг при запуске
  • Вы пытались переключиться посреди сессии: bypass можно выбрать только в сессии, где он был включён при запуске. В сессии, запущенной без него, Shift+Tab до bypass никогда не доходит

Кроме того, при первом запуске интерактивной сессии в режиме bypass Claude Code один раз показывает предупреждение с просьбой принять ответственность за действия, выполняемые без проверки разрешений (согласие сохраняется в пользовательских настройках).

2. Настоящая причина: система разрешений из 2 уровней

Ответ на вопрос «почему подтверждение появляется даже при включённом bypass» состоит в том, что система разрешений Claude Code построена на двух независимых уровнях.

Система разрешений Claude Code: архитектура 2 уровней

Обойти можно только «Уровень 1» (и даже в нём остаются отдельные подтверждения)

Уровень 1: UI разрешений Почти обходится
Tool Permission System
• «Можно изменить этот файл?»
• «Можно выполнить эту команду?»
• «Можно перейти по этому URL?»
• Интерактивный диалог подтверждения
Уровень 2: ИИ-оценка безопасности Не обходится
Claude's Own Safety Judgment
• Подтверждает перед необратимыми операциями
• Продакшн / необратимые действия / конфиденц. данные
• Отправляет как текст в чате Claude
• Встроено в принципы поведения модели

--dangerously-skip-permissions отключает почти весь Уровень 1 (остаются правила ask, удаление критических путей и ещё немногое). Уровень 2 обойти нельзя.

Смешение этих двух уровней — корневая причина заблуждения «bypass не работает». Рассмотрим каждый подробнее.

3. Уровень 1: UI разрешений инструментов (управляется bypass)

Первый уровень — это диалог подтверждения, который появляется перед выполнением инструмента: интерактивный UI, возникающий когда Claude Code собирается отредактировать файл или выполнить команду shell.

ИнструментПример диалога подтверждения
Редактирование файла«Можно изменить index.js?»
Выполнение Bash«Можно выполнить npm install?»
Веб-доступ«Можно обратиться к https://...?»

Именно этот уровень отключает режим bypass. С --dangerously-skip-permissions такие диалоги почти не появляются, и Claude может выполнять инструменты свободно. Даже запись в защищённые пути, такие как .git и .claude, в режиме bypass проходит без подтверждения. В этом смысле режим bypass работает корректно.

Подтверждения, которые появляются даже в режиме bypass (исключения Уровня 1)

Ключевое слово здесь — «почти». В официальной документации сказано, что Claude Code не одобряет автоматически следующее ни в одном режиме, включая bypass (источник: официальная страница Claude Code «Choose a permission mode», по состоянию на 22 сентября 2026 года).

  • Действия, подпадающие под правило ask: всё, что вы указали в permissions.ask в настройках (например, Bash(git push *)), каждый раз требует подтверждения, даже в режиме bypass
  • Инструменты, которым нужен ваш ответ: AskUserQuestion, с помощью которого Claude задаёт вам вопрос с вариантами ответа; MCP-инструменты, помеченные как требующие участия пользователя; и инструменты коннекторов, для которых ваша организация задала ask
  • rm и rmdir, нацеленные на критические пути: удаление корня файловой системы и каталогов первого уровня (например, /usr), домашнего каталога, рабочего каталога и его родительских каталогов. Документация называет это предохранителем (circuit breaker) на случай ошибки модели, и одобрить такое удаление не может ни правило allow, ни хук. Однако в Desktop-приложении и VS Code начиная с v2.1.309 такие команды сразу отклоняются без запроса подтверждения, а в ответе возвращаются подсказки, как переписать команду (чтобы не останавливать сессии, в которых никого нет; официальная история изменений)
  • Прочее: защитные механизмы обмена сообщениями между сессиями и команды Bash, читающие файлы за пределами рабочих каталогов, пока включён permissions.blockReadsOutsideWorkingDirectories

Правила тоже важны. Правила deny действуют и в режиме bypass и блокируют подходящие действия. Правила allow, наоборот, в режиме bypass ничего не значат (всё и так проходит). В неинтерактивных запусках с -p эти немногие подтверждения не ждут ответа, а отклоняются.

Примечание: существует 6 режимов разрешений

У Claude Code шесть режимов разрешений: Manual (default), Accept edits (acceptEdits), Plan (plan), Auto (auto) и Bypass permissions (bypassPermissions), а также dontAsk, который никогда не появляется в цикле Shift+Tab и автоматически отклоняет всё, что потребовало бы подтверждения (для CI). Bypass (bypassPermissions) — наименее ограничительный. Подробности о каждом режиме см. в статье о режимах разрешений.

4. Уровень 2: суждение ИИ о безопасности (bypass не управляет)

Второй уровень — это автономное суждение Claude о безопасности. Он полностью отделён от UI подтверждения инструментов.

Когда Claude определяет, что операция может иметь серьёзные последствия, он отправляет сообщение-подтверждение в чат в виде обычного текста. Это не механизм выполнения инструментов — это разговорное поведение Claude как ИИ.

--dangerously-skip-permissions пропускает диалоги UI Уровня 1, но никак не влияет на суждение ИИ Уровня 2 — потому что Уровень 2 является поведенческим принципом, встроенным в саму модель Claude.

Распространённое заблуждение

«Я включил режим bypass, но Claude остановился → bypass не работает»
→ Точнее, различайте по тому, как именно Claude остановился. Если Claude спросил текстом в чате — «UI Уровня 1 отключён, но суждение ИИ Уровня 2 запрашивает подтверждение». Если в терминале появился диалог с запросом разрешения — это одно из подтверждений Уровня 1, которые bypass сохраняет, например правило ask или удаление критического пути. В обоих случаях bypass работает нормально (если не подходит ни то ни другое, а подтверждения продолжаются, возможно, сессия вообще запущена не в режиме bypass).

При этом Уровень 2 — не гарантия безопасности. Спросит Claude или нет, решается в моменте, и он вовсе не обязательно остановится перед опасным действием. Официальная документация также предупреждает, что режим bypass не даёт никакой защиты от prompt injection и непреднамеренных действий. То, что не должно выполниться ни при каких условиях, блокируйте правилом deny.

5. Операции, при которых Claude спрашивает самостоятельно

По типу операции: какой уровень выполняет подтверждение?

Слой 1 (UI разрешений) vs Слой 2 (оценка ИИ)

Обычный риск (только Слой 1)
Обычное редактирование файловУровень 1 ✓
Запуск юнит-тестовУровень 1 ✓
→ Можно отключить через bypass
Уровень 1, который bypass сохраняет
rm -rf для корня, домашнего или рабочего каталогаУровень 1 !
Действия под правилом askУровень 1 !
Вопросы от Claude (AskUserQuestion)Уровень 1 !
→ Диалог появляется даже при bypass
Высокий риск (Уровень 2: суждение Claude)
Миграция продакшн БДУровень 2 !
git push --force (main)Уровень 2 !
Утечка .env и конфиденц. данныхУровень 2 !
→ Даже при bypass Claude может спросить сам
Уровень 1: отключается через bypass Исключения Уровня 1: подтверждение даже при bypass Уровень 2: Claude может спросить сам

Внутренние критерии Claude «стоит ли подтвердить это» делятся на три основные категории.

① Необратимость

Операции, которые нельзя отменить, заставляют Claude быть осторожнее. Безвозвратное удаление файлов, git push --force и DROP TABLE — наглядные примеры. Поскольку исправить ошибку сложно, Claude делает паузу и спрашивает.

② Радиус воздействия

Действия, затрагивающие производственные среды, большое количество файлов или других пользователей, вызывают более частые проверки. Изменение одного локального файла почти никогда не вызывает вопросов; изменение схемы production-базы данных почти всегда вызывает.

③ Риск безопасности

Операции, отправляющие файлы .env, токены аутентификации или API-ключи во внешние системы, помечаются Claude как высокий риск безопасности, и он уточнит перед выполнением.

Некоторые удаления, однако, вообще не отданы на суждение Claude: rm и rmdir, нацеленные на критические пути — корень, домашний каталог или сам рабочий каталог, — останавливаются самим Claude Code (Уровень 1), даже в режиме bypass (CLI выводит запрос подтверждения, а Desktop-приложение и VS Code с версии v2.1.309 сразу отклоняют их). Это одно из немногих подтверждений, которые bypass не убирает.

Эти суждения встроены в модель ИИ Claude и не могут быть полностью отключены через конфигурацию. Подробнее о том, как ИИ-агенты проектируются для безопасной работы, см. в статье Что такое ИИ-агент?.

6. Зачем два уровня? Философия проектирования

Зачем два уровня? — Философия проектирования

Разбираем на аналогии со строителем

Аналогия: строитель
🔑 Передать запасной ключ
= Выдать права на инструменты
❓ Строитель решает сам
Несущая стена? Нужно уточнить?
Ключ (разрешение) ≠ остановка суждения строителя
В Claude Code
--dangerously-skip-permissions
Режим bypass
= Выдать права на инструменты
🤖 ИИ-суждение Claude
→ Уточняет: необратимое, продакшн, конфиденц.
Разрешение ≠ остановка ИИ-суждения
Режим bypass даёт «разрешение использовать инструменты», но не останавливает «суждение Claude»

Вот аналогия, которая делает двухуровневое проектирование интуитивно понятным.

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

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

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

Claude работает так же. Режим bypass даёт Claude «ключ для использования инструментов», но не останавливает суждение ИИ Claude. На самом деле пауза Claude перед высокорисковыми операциями — это намеренная функция безопасности, а не неисправность.

7. Практические способы сократить количество подтверждений

В CI/CD-пайплайнах и других сценариях автоматизации может потребоваться, чтобы Claude выполнял задачи без остановок. Вот наиболее эффективные подходы.

Подход 1: использовать CLAUDE.md для предоставления контекста

Создайте файл CLAUDE.md в корне проекта, поясняя среду и ограничения. Когда Claude понимает, что «это безопасная изолированная среда», частота подтверждений значительно снижается.

# About This Environment

This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe

Please proceed without asking for extra confirmation.

Подход 2: давать небольшие конкретные инструкции

Расплывчатые инструкции усиливают неопределённость Claude и провоцируют больше подтверждений.

Тип инструкцииПримерЧастота подтверждений
Расплывчатая«Приведи этот проект в порядок»Высокая
Конкретная«Удали неиспользуемые импорты в src/»Низкая
Расплывчатая«Задеплой»Высокая
Конкретная«Запусти npm run deploy:staging в staging-среде»Низкая

Подход 3: сначала попробовать режим auto

Прежде чем переходить к полному режиму bypass, попробуйте режим auto. Он запускает классификатор безопасности в фоне, автоматически одобряя большинство операций, а также подталкивает Claude продолжать работу, не останавливаясь на уточняющие вопросы (Claude всё же спросит, если на вопрос рассчитан ваш промпт или skill). Если единственная причина использования bypass — «устал от подтверждений», режима auto может быть достаточно. Действия под правилом ask в режиме auto всё равно требуют подтверждения.

Важная оговорка

Никакая конфигурация не может снизить суждение Claude о безопасности до абсолютного нуля. Это сделано намеренно — это не баг и не ограничение. Для высокорисковых операций запрос подтверждения от Claude является правильным поведением. Воспринимайте это как часть дизайна. И на Уровне 1 остаются подтверждения, которые bypass не убирает, — например, правила ask и удаление критических путей.

8. Итоги

ПунктПодробности
Что такое bypassПропуск почти всех диалогов подтверждения перед инструментом (Уровень 1)
Что bypass отключаетUI разрешений инструментов («Можно выполнить эту команду?»), включая подтверждения записи в защищённые пути вроде .git и .claude
Что bypass НЕ отключаетСуждение ИИ Claude о безопасности (подтверждение, отправленное как текст в чате) и исключения Уровня 1 (правила ask, rm/rmdir для критических путей, AskUserQuestion)
Правила в режиме bypassdeny по-прежнему блокирует; allow не действует
Критерии подтверждения ClaudeНеобратимость, радиус воздействия, риск безопасности
Как сократить подтвержденияКонтекст в CLAUDE.md / конкретные инструкции / режим auto
Зачем два уровняРазрешение инструмента и суждение ИИ — принципиально разные понятия

Когда Claude запрашивает подтверждение даже в режиме bypass, это не значит, что bypass перестал работать — два независимых системы просто выполняют свою работу. Понимание этого различия помогает точно предсказывать поведение Claude Code и использовать его эффективнее.

Чтобы разобраться в различиях между продуктами Claude, см. Claude.ai против Claude Code: в чём разница?.

FAQ

Можно ли получить ноль подтверждений с режимом bypass?

Вы можете отключить почти все диалоги UI выполнения инструментов (Уровень 1), но подтверждения для действий под правилом ask, для rm или rmdir на критических путях и для вопросов через AskUserQuestion остаются. Полностью исключить подтверждения суждения ИИ о безопасности Уровня 2 тоже невозможно. Это намеренная функция безопасности. Тем не менее тщательная документация окружения в CLAUDE.md и конкретные инструкции могут значительно снизить частоту вопросов от Claude.

Запрос подтверждения от Claude — это баг?

Нет. Режим bypass пропускает UI разрешений инструментов, но не суждение ИИ Claude. Пауза Claude перед необратимыми операциями, производственными средами или конфиденциальными данными — это намеренное поведение безопасности, а не неисправность. Это не «bypass не работает», это «две системы работают независимо». Если вместо текста в чате появился диалог с запросом разрешения, это одно из подтверждений Уровня 1, которые bypass сохраняет, например правило ask или удаление критического пути.

Как предотвратить остановки Claude в CI/CD-пайплайнах?

Хорошо работают три вещи: ① явно укажите в CLAUDE.md или системном промпте, что «это полностью изолированная CI/CD-среда и все операции выполняются безопасно», ② давайте небольшие конкретные инструкции по задаче (расплывчатые инструкции вызывают больше подтверждений), ③ сочетайте режим bypass с изоляцией Docker-контейнера. Для ③ запускайте Claude Code не от root: в Linux и macOS режим bypass отказывается стартовать от root или через sudo. С -p немногие подтверждения, которые bypass сохраняет, не ждут ответа, а отклоняются. Если нужно, чтобы выполнялись только заранее разрешённые действия, официальная документация для CI предлагает также --permission-mode dontAsk вместе с --allowedTools. Имейте в виду, что даже при всех этих мерах Claude всё равно может иногда останавливаться.

Можно ли визуально отличить диалог инструмента от подтверждения Claude?

Да. Диалоги разрешений инструментов Уровня 1 появляются в терминале Claude Code как интерактивный UI, где показана команда или правка и варианты вроде Yes и No. Подтверждения суждения ИИ Уровня 2 появляются как обычный текст разговора от Claude (например, «Это изменит production-БД — всё в порядке?»). Путаницу вызывает AskUserQuestion, с помощью которого Claude задаёт вопрос с вариантами ответа: вопрос исходит от Claude, но выглядит как диалог и ждёт вашего ответа даже в режиме bypass, потому что Уровень 1 никогда не одобряет его автоматически. Форматы отображения разные, поэтому их легко различить, когда освоитесь.