# Claude Code --dangerously-skip-permissions: как включить и что он обходит

> Запуск claude --dangerously-skip-permissions включает bypassPermissions: обычные действия инструментов проходят без подтверждения. Флаг --allow-dangerously-skip-permissions только делает этот режим доступным. Правила ask, отдельные защитные проверки и ограничения среды остаются.

- URL: https://blog.laozhang.ai/ru/posts/claude-code-dangerously-skip-permissions
- Published: 2026-05-07
- Updated: 2026-10-08
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ru/about)
- Topic: Claude Code
- Tags: Claude Code, Разрешения, Автоматизация, Инструменты разработчика, Безопасность

---
**Чтобы включить обход обычных подтверждений в терминале, запустите `claude --dangerously-skip-permissions`.** Это тот же режим, что `claude --permission-mode bypassPermissions`. Он разрешает обычные вызовы инструментов без остановки перед каждым действием, включая запись в защищённые пути. Но он не даёт процессу дополнительные права операционной системы и не отменяет все проверки Claude Code. Применять его следует в подготовленном изолированном окружении, где ошибка не затронет рабочие данные и общие сервисы. Так описывает режим [актуальная документация Claude Code](https://code.claude.com/docs/en/permission-modes), проверенная 7 октября 2026 года.

Если задача — перестать подтверждать каждую правку, полный обход часто избыточен. `acceptEdits` автоматически разрешает изменения файлов и некоторые обычные файловые команды в пределах рабочей области; Auto проверяет действия классификатором; `dontAsk` отклоняет действия, для которых потребовалось бы подтверждение. Эти режимы решают разные задачи, а не представляют собой последовательные степени «разрешить всё».

## Как включить bypassPermissions в терминале

Для уже установленного Claude Code в подготовленной среде достаточно **одного** из двух вариантов:

~~~bash
claude --dangerously-skip-permissions
~~~

~~~bash
claude --permission-mode bypassPermissions
~~~

В интерактивном терминале при первом использовании появляется предупреждение об ответственности. Его принятие сохраняется отдельно от выбранного режима: принять предупреждение не означает сделать bypass постоянным. В запущенной сессии откройте `/permissions` и проверьте текущий режим. Названия флагов и их назначение приведены в [справочнике CLI](https://code.claude.com/docs/en/cli-reference).

Для выполнения одной задачи без интерактивного диалога используется `-p`. Следующий документированный по форме пример предполагает установленный и авторизованный клиент, отдельную копию проекта, рабочие зависимости и внешнюю изоляцию процесса:

~~~bash
claude -p --permission-mode bypassPermissions "Исправь опечатки только в docs/getting-started.md. Не изменяй другие файлы."
~~~

Текст задания ограничивает поручение, но не технические возможности процесса. Поэтому команда подходит только после настройки окружения. В `-p` нет стартового диалога с предупреждением; это не означает, что режим стал безопаснее. Фоновый запуск через `--bg`, напротив, требует предварительно принятого предупреждения. В этой статье команды приведены по документации; реальные сессии Claude и обращения к модели не запускались.

### Почему --allow-dangerously-skip-permissions не включает обход

Флаг с `allow` **добавляет bypass в доступные режимы**, но не выбирает его. Например:

~~~bash
claude --allow-dangerously-skip-permissions --permission-mode default
~~~

Такой запуск выбирает обычный режим `default`, который в интерфейсе называется Manual. После этого bypass можно выбрать в интерактивном переключателе. Для немедленного включения нужен один из двух вариантов из предыдущего раздела. Это различие прямо указано в [описании режимов](https://code.claude.com/docs/en/permission-modes).

Есть важное следствие для `plan`: **в интерактивном терминале, где bypass уже доступен, принудительные запреты Plan на изменения и команды больше не действуют**. Инструкция сначала составить план остаётся, но сама по себе не делает сессию доступной только для чтения. В `-p`, SDK и чате расширения VS Code ограничения Plan сохраняются. Поэтому сочетание `--allow-dangerously-skip-permissions --permission-mode plan` нельзя использовать как универсальную гарантию отсутствия записей.

## Как сделать, чтобы Claude Code реже спрашивал разрешения

![Шесть режимов разрешений Claude Code решают разные задачи; dontAsk допускает отказ, а Plan имеет ограничения по интерфейсу](https://blog.laozhang.ai/posts/ru/claude-code-dangerously-skip-permissions/img/explainer-1.webp)

Начните с вида повторяющегося запроса: правка файла, конкретная команда или любое действие без заранее известного разрешения. От этого зависит настройка.

| Что вам нужно | Что выбрать | Как ведёт себя режим |
| --- | --- | --- |
| Контролировать действия вручную | `default`, в интерфейсе Manual | Применяет правила и запрашивает нужные подтверждения |
| Разрешить обычные правки проекта | `acceptEdits` | Одобряет правки и ряд файловых shell-команд в рабочей области; другие проверки остаются |
| Сначала проанализировать изменения | `plan` | Обычно блокирует изменения и команды; исключение для интерактивного терминала с доступным bypass описано выше |
| Передать оценку действий классификатору | `auto` | Проверяет действия перед выполнением, может блокировать их или переходить к предусмотренному подтверждению |
| Выполнять только то, что уже разрешено, без новых запросов | `dontAsk` | Отклоняет вызов, который потребовал бы подтверждения |
| Выполнять обычные вызовы без подтверждений | `bypassPermissions` | Пропускает обычную проверку разрешения; специальные ограничения остаются |

Таблица описывает [текущие режимы](https://code.claude.com/docs/en/permission-modes), а не гарантирует их доступность в каждом клиенте. В частности, `dontAsk` — способ работать без новых запросов за счёт отказов, а не разрешение всех действий.

### Настройка для правок и одной повторяющейся команды

Если раздражают подтверждения правок и проверки типов, можно выбрать `acceptEdits`, а конкретную команду одобрить отдельно. Пример для проекта, в котором **уже есть проверенный** скрипт `npm run typecheck`:

~~~json
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run typecheck)"],
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}
~~~

Это содержимое раздела настроек, которое нужно объединить с существующим JSON, сохранив остальные поля. Для локальной настройки проекта используется `.claude/settings.local.json`; общие настройки проекта находятся в `.claude/settings.json`. Пример не требует включать bypass. В обычной CLI-сессии с загруженными настройками доверенного проекта ожидаемый результат — правки проходят в рамках `acceptEdits`, а совпавшая команда проверки типов не требует отдельного одобрения, если её не запрещает другое правило. Не добавляйте в `allow` неизвестный скрипт только из-за его названия: скрипт может запускать произвольный код.

Правила `Read` в примере ограничивают соответствующие чтения, но **не образуют полную защиту `.env` от всех дочерних процессов**. Для запрета доступа на уровне процесса нужна изоляция файловой системы. Синтаксис, области настроек и ограничения файловых правил описаны в [документации разрешений](https://code.claude.com/docs/en/permissions). JSON проверен только локально на синтаксис; его принятие конкретной установленной версией клиента не проверялось.

### Автоматизация без полного bypass

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

~~~bash
claude -p --permission-mode dontAsk --tools "Read,Grep,Glob,Bash" --allowedTools "Read,Grep,Glob,Bash(npm run typecheck)" "Прочитай src и запусти npm run typecheck. Не исправляй файлы; сообщи результат проверки."
~~~

Предпосылки те же: установленный авторизованный клиент, подготовленный проект и проверенный скрипт. `--tools` задаёт набор встроенных инструментов, а `--allowedTools` заранее одобряет перечисленные операции. Если агент запросит другую команду, требующую подтверждения, `dontAsk` откажет в её выполнении. Отказ — допустимый результат этого подхода: автоматизация не должна молча расширять полномочия.

При этом `--tools` не ограничивает MCP-инструменты, а Bash способен запустить программу, которая сама читает или изменяет файлы. Поэтому сочетание флагов не заменяет изоляцию. Значения флагов подтверждены [CLI-справочником](https://code.claude.com/docs/en/cli-reference); реальный запуск этого примера не выполнялся.

### Когда подходит Auto и почему он может быть режимом по умолчанию

С версии **2.1.283** встроенный начальный режим Auto предусмотрен для интерактивного терминала и VS Code на разных планах и у разных провайдеров. Однако поддержка модели, минимальные версии для провайдера, серверная доступность и политика организации по-прежнему имеют значение. Утверждение «Auto доступен только на конкретном платном плане» уже не описывает все текущие варианты.

Для `-p` и SDK начальный режим зависит ещё и от получения флагов доступности. Сессии с таким получением обычно начинают с Manual; без него с версии **2.1.285** используется Auto, если позволяют модель и политика. У организаций с условиями HIPAA есть отдельное правило начального Manual. При фиксированном процессе автоматизации выбирайте нужный режим явно и проверяйте [условия Auto](https://code.claude.com/docs/en/permission-modes), а не полагайтесь на старое описание режима по умолчанию.

## Почему bypass продолжает спрашивать или запрещает действие

Обход обычных подтверждений не означает «любой инструмент выполнится». Сначала определите, что именно остановило работу.

| Что вы видите | Возможная причина | Что проверить |
| --- | --- | --- |
| Подтверждение перед конкретной операцией | Явное правило `ask`, политика коннектора или инструмент с обязательным взаимодействием | Правила для этого инструмента и настройки организации |
| Запрос при обращении за пределы рабочей области | Включён `blockReadsOutsideWorkingDirectories` | Рабочие каталоги и применимую защиту чтения |
| Предупреждение при опасном удалении | Отдельная проверка критических `rm`/`rmdir` | Цель операции; не считать её обычным разрешением записи |
| Ошибка при запуске режима | `--restricted`, root/sudo или запрет организации | Флаги запуска, пользователя процесса и управляемые настройки |
| Вопрос в сообщении Claude | Модели не хватает решения о задаче | Ответить по существу или уточнить поручение |

Когда ограничение чтения обеспечивает песочница, доступ может блокироваться без отдельного запроса. Эти исключения перечислены в [описании bypassPermissions](https://code.claude.com/docs/en/permission-modes). Уточняющий вопрос в тексте модели отличается от клиентского окна разрешения: флаг не заставляет модель угадывать недостающие требования.

С версии **2.1.248** `--restricted` несовместим с bypass. На Linux и macOS обычный запуск от root или через sudo также отклоняется; документация отдельно оговаривает распознанные изолированные среды. Практический вариант для контейнера — непривилегированный пользователь, а не отключение проверки root. Bypass не исправляет ошибки входа, отсутствие прав на файлы, сетевые отказы или исчерпанную квоту.

Запись в защищённый путь и удаление критического каталога проверяются по-разному. В терминале отдельные запросы для критических `rm`/`rmdir` в Auto и bypass имеют двухминутный срок; с версии **2.1.281** повторные неотвеченные запросы приводят к отказу. У PowerShell существуют отдельные запреты системных путей и удалений с шаблонами. Из этого нельзя выводить, что Claude блокирует любое опасное удаление.

### Правила deny и hooks: что остаётся, а где есть исключение

Обычные правила проверяются в порядке **`deny` → `ask` → `allow`**, с учётом разных областей настроек. Более узкое `allow` не отменяет совпавший `deny`, а явное `ask` может требовать подтверждения и в bypass. Блокировка через `PreToolUse` также может сохраняться.

Но есть существенное исключение: установленный внутри процесса mod может через `tool.check` переопределять решения `ask`, hooks и классификатора, а при определённых политиках — и часть запретов. Управляемые hooks и запреты Team/Enterprise или managed policy имеют отдельные защиты и исключения. Поэтому утверждение «deny всегда гарантированно остановит любой код» слишком широкое. Это ограничение описано в [документации разрешений](https://code.claude.com/docs/en/permissions).

Правила Bash сопоставляют распознанный текст команды, а не все возможные действия произвольной программы. Запрет одного строкового варианта не перекрывает любой интерпретатор, обёртку или косвенный доступ к файлу. Самодельный регулярный фильтр команды и просьба «не делай опасного» тоже не создают границу операционной системы.

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

![Командный sandbox и отдельно настроенная изоляция всего процесса с проверкой файлов, секретов и сети](https://blog.laozhang.ai/posts/ru/claude-code-dangerously-skip-permissions/img/explainer-2.webp)

Изоляция должна охватывать процесс и доступные ему полномочия. Отдельная ветка или worktree отделяет изменения Git, но не ограничивает чтение домашнего каталога, сеть и учётные данные. У контейнера нужно отдельно проверить монтирования, пользователя, секреты и разрешённые соединения.

### Что защищает встроенная песочница

Встроенная песочница Claude Code охватывает **Bash, PowerShell, Monitor и их дочерние процессы**. Она не охватывает инструменты чтения и записи файлов, веб-инструменты, MCP, hooks, LSP, mods и другие вспомогательные процессы. По умолчанию она выключена. Если поддержка недоступна, запуск может продолжиться без неё, пока не включён `failIfUnavailable`. Нативная Windows эту песочницу не поддерживает; WSL2 поддерживается. Источник — [документация sandboxing](https://code.claude.com/docs/en/sandboxing).

Ниже пример фрагмента настроек для поддерживаемой среды. Он показывает включение песочницы, отказ при её недоступности, запрет повторного запуска команды вне неё и строгий список сетевых адресов:

~~~json
{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "strictAllowlist": true,
      "allowedDomains": ["api.anthropic.com"]
    }
  }
}
~~~

Здесь `api.anthropic.com` — **пример адреса для прямого API-подключения**, а не полный список для всех способов входа и провайдеров. До применения определите необходимые адреса модели и авторизации для своего подключения. Локально проверен синтаксис JSON; запуск песочницы, сетевые блокировки и принятие настроек клиентом не тестировались.

В bypass одного списка `allowedDomains` недостаточно: неизвестные адреса могут автоматически разрешаться, если нет `strictAllowlist` или соответствующего управляемого ограничения. `allowUnsandboxedCommands: false` закрывает повторную попытку вне песочницы, но не превращает исключённые команды в изолированные. С версии **2.1.285** пользовательское `false` имеет приоритет над проектным разрешением повторной попытки. Управляемый запрет может сделать песочницу обязательной, однако сам по себе не включает её. Все эти условия относятся именно к [командной песочнице](https://code.claude.com/docs/en/sandboxing).

### Что нужно для изоляции всей сессии

Для всего процесса нужен внешний контейнер, VM или среда изоляции всего процесса. Проверьте прежде всего следующее:

- В окружение передан только нужный проект. Записываемое монтирование означает, что изменения могут попасть в файлы на хосте.
- Не переданы домашний каталог, рабочие облачные ключи, SSH-ключи и Docker socket. Учётные данные для модели также должны иметь подходящий ограниченный доступ.
- Сеть ограничена необходимыми адресами модели и авторизации; внутренние сервисы, развёртывание и платежи недоступны.
- Известно, где сохраняются настройки и состояние. Постоянный том может сохранять и учётные данные, и историю.
- Результат проверяется до переноса в рабочий проект. Git помогает вернуть версионируемые файлы, но не отменяет утечку данных, внешний запрос или изменение базы.

Официальная Dev Container Feature устанавливает Claude Code, но **не добавляет автоматически межсетевой экран с запретом остальных соединений**. Тег Feature `:1.0` закрепляет установочный компонент, а не версию CLI. Пример Anthropic с `devcontainer.json`, Dockerfile и `init-firewall.sh` нужно адаптировать к своим инструментам и сетевой политике; это не обещание готового безопасного базового образа. Эти различия изложены в [руководстве Dev Container](https://code.claude.com/docs/en/devcontainer).

Даже внешняя изоляция не прекращает передачу запросов и прочитанных данных настроенному провайдеру модели. При полностью отключённой сети нельзя обещать работающий Claude «из локального кеша». Среда изоляции всего процесса sandbox runtime, описанная в [руководстве по изолированным окружениям](https://code.claude.com/docs/en/sandbox-environments), находится в исследовательской бета-версии и требует явной конфигурации файлов и сети. Просто успешный старт контейнера не доказывает, что желаемые ограничения применились.

## Почему режим отличается в VS Code, Desktop и браузере

| Где работает Claude Code | Что нужно учитывать |
| --- | --- |
| Терминал CLI, в том числе терминал JetBrains | Действуют CLI-флаги и соответствующие настройки |
| Чат расширения VS Code | Bypass требует отдельного переключателя расширения. Начальный режим зависит от пользовательской настройки, запомненного режима и политики; проектный JSON его не задаёт |
| Desktop, раздел Code | Есть выбор режима; для Pro/Max — пользовательский переключатель, для Team/Enterprise — политика организации. Cowork имеет собственные условия |
| Веб-сессия в облаке | Доступны Accept edits, Plan и подходящим сессиям Auto; выбрать Bypass нельзя. Проектные настройки начального bypass/dontAsk игнорируются |
| Приложение Remote Control | В приложении нельзя выбрать Auto/Bypass; режим выполнения терминала может отличаться от отображаемого названия |

Это текущее разделение [по интерфейсам Claude Code](https://code.claude.com/docs/en/permission-modes). Отсутствие Bypass в облаке не исправляется локальным флагом. И наоборот, надпись в Remote Control сама по себе не доказывает, что терминал выполняет действия в Manual.

Для локального CLI также важно место настройки: проектное `permissions.defaultMode: "bypassPermissions"` не активирует bypass — стартует Manual. Проектное значение Auto тоже не применяется как начальный режим. Явный флаг запуска и допустимые пользовательские либо управляемые настройки имеют отдельный порядок приоритета. Если режим неожиданно отличается, проверьте интерфейс, источник настройки и фактический переключатель сессии; не повышайте права процесса для исправления этого расхождения.

## Что происходит после --continue или восстановления сессии

**Восстановление сохранённого диалога не гарантирует восстановление bypass.** При восстановлении интерактивного терминального диалога по точному ID, имени или `--continue` сохранённые Bypass и Plan сбрасываются к начальному режиму новой сессии. Bypass нужно явно включить заново. Например, если прежний диалог и текущее изолированное окружение вам известны:

~~~bash
claude --continue --permission-mode bypassPermissions
~~~

Эта форма вновь выбирает bypass; обычный `--continue` сам этого не обещает. Выбор из списка при запуске использует начальный режим новой сессии, а `/resume` внутри уже работающей сессии сохраняет её текущий режим. Подключение к **ещё работающей** фоновой сессии сохраняет её режим — это другая ситуация, чем чтение сохранённого диалога.

В `-p` восстановление обычно использует новые начальные условия `-p`; для сохранённого Plan есть отдельные версионные условия, в том числе инструмент подтверждения и отсутствие переопределяющих флагов. Подробности приведены в [разделе Permission mode on resume](https://code.claude.com/docs/en/sessions#permission-mode-on-resume). После восстановления проверяйте режим и окружение независимо: возвращённый диалог не возвращает прежние границы файлов и сети.

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

### Bypass permissions в Claude Code — что это?

Это режим `bypassPermissions`, в котором обычные вызовы инструментов не требуют подтверждения. Его включают `--dangerously-skip-permissions` или `--permission-mode bypassPermissions`. Явные правила `ask` и отдельные защитные проверки остаются; режим не предоставляет права root. См. [описание режима](https://code.claude.com/docs/en/permission-modes).

### Можно ли сделать bypass постоянным в настройках проекта?

Проектное `permissions.defaultMode: "bypassPermissions"` не включает его: CLI начинает с Manual. Для конкретного запуска используйте явный флаг; поведение пользовательских настроек, управляемой политики и IDE проверяйте отдельно в [документации режимов](https://code.claude.com/docs/en/permission-modes).

### Почему Claude спрашивает, хотя флаг уже указан?

Если это окно разрешения, проверьте `ask`, инструмент с обязательным взаимодействием и специальные защиты удаления или чтения. Если это вопрос в сообщении Claude, ему может не хватать решения о задаче — bypass не отменяет уточняющих вопросов модели. Перечень клиентских исключений есть в [документации bypass](https://code.claude.com/docs/en/permission-modes).

### Достаточно ли dontAsk для CI без подтверждений?

Да, если вы согласны, что вызовы без нужного предварительного разрешения будут отклоняться. Заранее одобрите проверенные операции, явно выберите режим и учитывайте отказы при оценке результата. `dontAsk` не гарантирует успешного выполнения задачи и не ограничивает весь процесс на уровне ОС. См. [режимы](https://code.claude.com/docs/en/permission-modes) и [CLI-флаги](https://code.claude.com/docs/en/cli-reference).

### Docker защищает от prompt injection и утечки файлов?

Сам факт запуска Docker этого не гарантирует. Недоверенный текст всё ещё может повлиять на действия модели, а контейнер может иметь читаемые секреты, записываемые монтирования и разрешённые адреса для передачи данных. Внешняя изоляция ограничивает последствия только в рамках реально заданных границ; отправка данных провайдеру модели сохраняется. См. [руководство изолированных окружений](https://code.claude.com/docs/en/sandbox-environments).

## Источники

Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 2026-10-08.

- [актуальная документация Claude Code](https://code.claude.com/docs/en/permission-modes) (code.claude.com)
- [справочнике CLI](https://code.claude.com/docs/en/cli-reference) (code.claude.com)
- [документации разрешений](https://code.claude.com/docs/en/permissions) (code.claude.com)
- [документация sandboxing](https://code.claude.com/docs/en/sandboxing) (code.claude.com)
- [руководстве Dev Container](https://code.claude.com/docs/en/devcontainer) (code.claude.com)
- [руководстве по изолированным окружениям](https://code.claude.com/docs/en/sandbox-environments) (code.claude.com)
- [разделе Permission mode on resume](https://code.claude.com/docs/en/sessions) (code.claude.com)