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

Чтобы включить обход обычных подтверждений в терминале, запустите claude --dangerously-skip-permissions. Это тот же режим, что claude --permission-mode bypassPermissions. Он разрешает обычные вызовы инструментов без остановки перед каждым действием, включая запись в защищённые пути. Но он не даёт процессу дополнительные права операционной системы и не отменяет все проверки Claude Code. Применять его следует в подготовленном изолированном окружении, где ошибка не затронет рабочие данные и общие сервисы. Так описывает режим актуальная документация Claude Code, проверенная 7 октября 2026 года.

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

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

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

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

В интерактивном терминале при первом использовании появляется предупреждение об ответственности. Его принятие сохраняется отдельно от выбранного режима: принять предупреждение не означает сделать bypass постоянным. В запущенной сессии откройте /permissions и проверьте текущий режим. Названия флагов и их назначение приведены в справочнике CLI.

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

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

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

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

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

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

Такой запуск выбирает обычный режим default, который в интерфейсе называется Manual. После этого bypass можно выбрать в интерактивном переключателе. Для немедленного включения нужен один из двух вариантов из предыдущего раздела. Это различие прямо указано в описании режимов.

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

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

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

Таблица описывает текущие режимы, а не гарантирует их доступность в каждом клиенте. В частности, dontAsk — способ работать без новых запросов за счёт отказов, а не разрешение всех действий.

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

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

{
  "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 от всех дочерних процессов. Для запрета доступа на уровне процесса нужна изоляция файловой системы. Синтаксис, области настроек и ограничения файловых правил описаны в документации разрешений. JSON проверен только локально на синтаксис; его принятие конкретной установленной версией клиента не проверялось.

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

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

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-справочником; реальный запуск этого примера не выполнялся.

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

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

Для -p и SDK начальный режим зависит ещё и от получения флагов доступности. Сессии с таким получением обычно начинают с Manual; без него с версии 2.1.285 используется Auto, если позволяют модель и политика. У организаций с условиями HIPAA есть отдельное правило начального Manual. При фиксированном процессе автоматизации выбирайте нужный режим явно и проверяйте условия Auto, а не полагайтесь на старое описание режима по умолчанию.

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

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

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

С версии 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 всегда гарантированно остановит любой код» слишком широкое. Это ограничение описано в документации разрешений.

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

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

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

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

Встроенная песочница Claude Code охватывает Bash, PowerShell, Monitor и их дочерние процессы. Она не охватывает инструменты чтения и записи файлов, веб-инструменты, MCP, hooks, LSP, mods и другие вспомогательные процессы. По умолчанию она выключена. Если поддержка недоступна, запуск может продолжиться без неё, пока не включён failIfUnavailable. Нативная Windows эту песочницу не поддерживает; WSL2 поддерживается. Источник — документация sandboxing.

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

{
  "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 имеет приоритет над проектным разрешением повторной попытки. Управляемый запрет может сделать песочницу обязательной, однако сам по себе не включает её. Все эти условия относятся именно к командной песочнице.

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

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

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

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

Даже внешняя изоляция не прекращает передачу запросов и прочитанных данных настроенному провайдеру модели. При полностью отключённой сети нельзя обещать работающий Claude «из локального кеша». Среда изоляции всего процесса sandbox runtime, описанная в руководстве по изолированным окружениям, находится в исследовательской бета-версии и требует явной конфигурации файлов и сети. Просто успешный старт контейнера не доказывает, что желаемые ограничения применились.

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

Это текущее разделение по интерфейсам Claude Code. Отсутствие Bypass в облаке не исправляется локальным флагом. И наоборот, надпись в Remote Control сама по себе не доказывает, что терминал выполняет действия в Manual.

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

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

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

claude --continue --permission-mode bypassPermissions

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

В -p восстановление обычно использует новые начальные условия -p; для сохранённого Plan есть отдельные версионные условия, в том числе инструмент подтверждения и отсутствие переопределяющих флагов. Подробности приведены в разделе Permission mode on resume. После восстановления проверяйте режим и окружение независимо: возвращённый диалог не возвращает прежние границы файлов и сети.

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

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

Это режим bypassPermissions, в котором обычные вызовы инструментов не требуют подтверждения. Его включают --dangerously-skip-permissions или --permission-mode bypassPermissions. Явные правила ask и отдельные защитные проверки остаются; режим не предоставляет права root. См. описание режима.

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

Проектное permissions.defaultMode: "bypassPermissions" не включает его: CLI начинает с Manual. Для конкретного запуска используйте явный флаг; поведение пользовательских настроек, управляемой политики и IDE проверяйте отдельно в документации режимов.

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

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

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

Да, если вы согласны, что вызовы без нужного предварительного разрешения будут отклоняться. Заранее одобрите проверенные операции, явно выберите режим и учитывайте отказы при оценке результата. dontAsk не гарантирует успешного выполнения задачи и не ограничивает весь процесс на уровне ОС. См. режимы и CLI-флаги.

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

Сам факт запуска Docker этого не гарантирует. Недоверенный текст всё ещё может повлиять на действия модели, а контейнер может иметь читаемые секреты, записываемые монтирования и разрешённые адреса для передачи данных. Внешняя изоляция ограничивает последствия только в рамках реально заданных границ; отправка данных провайдеру модели сохраняется. См. руководство изолированных окружений.