# Auto mode или bypassPermissions в Claude Code: где проходит граница доверия

> Сравните Auto mode и bypassPermissions по способу проверки действий, оставшимся ограничениям, изоляции и поведению запуска без присмотра.

- Source: https://www.aifreeapi.com/ru/posts/claude-code-auto-mode-vs-bypass-permissions
- Language: ru
- Published: 2026-08-20
- Updated: 2026-08-20
- Publisher: AI Free API (https://www.aifreeapi.com)

Если запросы разрешений мешают работе, первым выбором должен быть **Auto mode с явными правилами deny и ask**, а не `bypassPermissions`. Автоматический режим убирает большинство остановок, но перед выполнением действие оценивает отдельный классификатор. Режим обхода убирает обычную проверку — поэтому его безопасная область начинается только там, где контейнер или виртуальная машина уже ограничили возможный ущерб.

Одинаково тихий терминал скрывает разные модели ответственности. В Auto mode решение передано другому проверяющему. В `bypassPermissions` обычного проверяющего нет.

## Что именно происходит до вызова инструмента

Согласно актуальной [документации режимов разрешений](https://code.claude.com/docs/ru/permission-modes), Auto mode отправляет действие отдельной модели-классификатору. Она может заблокировать выход за пределы запроса, обращение к неизвестной инфраструктуре, разрушительную операцию или действие, похожее на результат вредоносного контента. Явное правило ask всё ещё вызывает запрос, а `permissions.deny` срабатывает раньше классификатора во всех режимах.

`bypassPermissions` отключает обычные запросы и проверки безопасности, поэтому вызовы инструментов выполняются сразу, в том числе запись в защищённые пути. Два запуска равнозначны:

```bash
claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions
```

Но слово «обход» не означает, что исчезает каждый внутренний инвариант. Особая обработка остаётся у явных ask-правил, connector-инструментов с обязательным подтверждением организации, инструментов с пользовательским взаимодействием, удаления критических путей через `rm`/`rmdir` и части межсессионных сообщений. Deny-правила также продолжают действовать. Эти исключения уточняют контракт, но не делают режим защитным: Anthropic прямо указывает, что он не защищает от prompt injection и непреднамеренных действий.

| Практический вопрос | Auto mode | `bypassPermissions` |
|---|---|---|
| Кто проверяет обычное действие | Отдельный классификатор | Никто в обычном permission flow |
| Запросы подтверждения | Обычно исчезают; ask остаётся | Обычно исчезают; остаются отдельные продуктовые исключения |
| Жёсткий deny | Действует | Действует |
| Контекстная защита | Есть, но не гарантирует безопасность | Нет обычной защиты от инъекций и ошибочных действий |
| Подходящая среда | Доверенное направление работы с дополнительными слоями защиты | Изолированный контейнер/VM/dev container без интернета |
| Изоляция ОС | Не предоставляется режимом | Не предоставляется режимом |

## Выбирайте по радиусу ущерба

Длительность задачи сама по себе ничего не говорит о допустимых правах. Пять минут с production credentials опаснее ночного локального теста. Перед выбором режима зафиксируйте четыре границы:

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

Для повседневной работы в собственном репозитории Auto mode обычно даёт разумный баланс. Вы доверяете направлению задачи, но сохраняете контекстный фильтр и проверяете итоговый diff, тесты и артефакты.

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

Для CI с фиксированным набором команд уместен `dontAsk`: выполняются только заранее разрешённые инструменты, остальные отклоняются. Такой контракт проще аудировать, чем контекстные решения классификатора.

`bypassPermissions` допустим только тогда, когда внешняя изоляция является настоящей границей. Среда должна быть одноразовой, без интернета и host credentials, работать не от root и монтировать только рабочую копию с каталогом результатов. На Linux и macOS Claude Code вне распознанной песочницы не запускает bypass под `root` или `sudo`, но эта проверка не заменяет контейнер.

Если задача — сохранить процесс после закрытия терминала, пережить сон компьютера или восстановиться после остановки, режим разрешений решает только часть проблемы. Отдельное руководство о [длительных задачах Claude Code](/ru/posts/claude-code-long-running-tasks) разбирает жизненный цикл, состояние и доказательство завершения.

## Настройте Auto mode и проверьте результат слияния

Для одного сеанса укажите режим явно:

```bash
claude --permission-mode auto
```

Личный стартовый режим для терминала задаётся в `~/.claude/settings.json`:

```json
{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(git push --force *)",
      "Bash(terraform destroy *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(terraform apply *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}
```

Текущий терминальный контракт игнорирует `defaultMode: "auto"` из `.claude/settings.json` и `.claude/settings.local.json` внутри репозитория. Это не позволяет клонированному проекту незаметно включить для себя Auto mode. У VS Code и других поверхностей свои правила стартового режима, поэтому всегда проверяйте фактический интерфейс.

Примеры deny и ask надо сузить под реальные команды и цели по [синтаксису правил разрешений](https://code.claude.com/docs/ru/permissions). Широкий allow-шаблон способен пропустить опасный аргумент ещё до классификатора. Для действий, которые нельзя разрешать независимо от контекста, используйте managed `permissions.deny`.

Контекст Auto mode может описывать доверенные репозитории, внутренние домены, хранилища и чувствительные цели. После изменений не угадывайте, какой файл победил по precedence, а выведите эффективную конфигурацию:

```bash
claude auto-mode config
```

Там должны быть ожидаемые environment, allow, soft/hard deny и организационные ограничения. Команды `claude auto-mode defaults` и `claude auto-mode critique` помогают увидеть встроенные правила и проверить неоднозначные пользовательские формулировки.

## Режим разрешений не ограничивает операционную систему

Auto mode отвечает на вопрос «кто разрешает действие». [Bash sandbox](https://code.claude.com/docs/ru/sandboxing) отвечает на другой: «какие файлы и сетевые адреса доступны уже запущенной команде и её дочерним процессам».

![Режим разрешений, Bash sandbox и внешний контейнер ограничивают разные уровни риска](https://www.aifreeapi.com/posts/ru/claude-code-auto-mode-vs-bypass-permissions/img/isolation-layers.webp)

Встроенная песочница работает на macOS, Linux и WSL2; для native Windows требуется WSL2. Практичная конфигурация должна закрываться при ошибке:

- запись только в репозиторий и временный каталог сеанса;
- сеть только к необходимым доменам;
- запрет или маскирование SSH, cloud credentials и высокопривилегированных токенов;
- `allowUnsandboxedCommands: false`, чтобы нарушение не привело к повтору на хосте;
- `failIfUnavailable: true`, если отсутствие песочницы должно остановить работу.

Песочница охватывает Bash и дочерние процессы, но не все инструменты Claude Code. Для bypass финальной границей всё равно должен быть внешний контейнер или VM. Режим решает, кто подтвердил действие; изоляция решает, что подтверждённое действие способно повредить.

## Перед запуском без присмотра соберите доказательства

Доступность Auto mode и стартовый режим зависят от версии, плана, модели, provider, feature flags, политики организации и интерфейса. После запуска проверьте:

1. текущий режим в строке состояния; в CLI `Shift+Tab` показывает доступный цикл;
2. `/permissions` с effective allow, ask, deny и недавними отказами;
3. `claude auto-mode config` с итоговым контекстом классификатора;
4. `/sandbox` с файловой, сетевой и unsandboxed-retry политикой.

![Различия между интерактивным и неинтерактивным запуском после отказа классификатора](https://www.aifreeapi.com/posts/ru/claude-code-auto-mode-vs-bypass-permissions/img/denial-runtime.webp)

После повторных блокировок интерактивный Auto-сеанс может вернуться к человеческим запросам. В неинтерактивном `-p` без permission prompt tool запрещённое действие не выполняется, но Claude может продолжить другие шаги. Поэтому активный процесс не доказывает успех: заранее задайте наблюдаемое условие завершения и артефакт ошибки.

Auto mode подходит, когда вы доверяете направлению, но хотите оставить проверяющего. `dontAsk` — когда нужен фиксированный allowlist. Manual и Plan — когда необходима человеческая оценка. `bypassPermissions` имеет смысл только после того, как хост, интернет, секреты и долговечное состояние уже вынесены за пределы процесса.