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

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

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

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

Согласно актуальной документации режимов разрешений, Auto mode отправляет действие отдельной модели-классификатору. Она может заблокировать выход за пределы запроса, обращение к неизвестной инфраструктуре, разрушительную операцию или действие, похожее на результат вредоносного контента. Явное правило ask всё ещё вызывает запрос, а permissions.deny срабатывает раньше классификатора во всех режимах.

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

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

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

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

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

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

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

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

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

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

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

Настройте 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 надо сузить под реальные команды и цели по синтаксису правил разрешений. Широкий 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 отвечает на другой: «какие файлы и сетевые адреса доступны уже запущенной команде и её дочерним процессам».

Встроенная песочница работает на 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 политикой.

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

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