Запуск агентов программирования в режиме YOLO без уничтожения вашего ноутбука

Запуск агента программирования в режиме YOLO безопасен только при условии ограничения радиуса поражения — вы делаете среду агента одноразовой, а не пытаетесь сделать самого агента надёжным. Режим обхода разрешений (--dangerously-skip-permissions в Claude Code, full-auto в Codex, YOLO в Gemini CLI) заменяет сотню кликов подтверждения на агента, который способен читать ваши SSH-ключи, удалять файлы, портить историю git и выполнять только что сгенерированный код — всё это без каких-либо запросов. Исправить это нельзя ни доверием к модели, ни более строгим allowlist. Исправить это можно только помещением агента туда, где он не сможет навредить ничему важному, — в несколько слоёв, соразмерных реальному уровню риска.

В этой статье изложена модель рисков, независимое от конкретного инструмента правило выбора нужного уровня изоляции, официальные механизмы изоляции, которые сейчас поставляются с Claude Code, а также минимальная безопасная конфигурация, которую можно скопировать, с честным описанием её компромиссов. Эта область меняется ежемесячно, поэтому флаги и названия инструментов будут меняться — базовые примитивы (контейнеры, microVM, egress-прокси, одноразовые рабочие пространства) останутся неизменными.

Что на самом деле делает режим YOLO в Claude Code в 2026 году

Режим обхода разрешений отключает запросы подтверждения и большинство проверок безопасности, которые в обычном режиме контролируют shell-команды и операции записи файлов агента. Согласно документации по режимам разрешений Claude Code, --dangerously-skip-permissions эквивалентен --permission-mode bypassPermissions. Этот режим, появившийся в Claude Code v2.1.126, также пропускает запись в защищённые пути, которые в более ранних версиях всё ещё требовали подтверждения — хотя rm -rf / и rm -rf ~ по-прежнему запрашивают подтверждение как предохранители от ошибок модели, а сам флаг теперь отказывается запускаться от имени root или через sudo на Linux и macOS. Отказ от запуска с правами root/sudo подтверждается в документации по инструменту sandboxed Bash и незаметно ломает все наивные Docker-конфигурации, запускающие агента от имени root.

Причина, по которой нельзя просто написать более безопасный allowlist, носит структурный характер. Allowlist по принципу минимальных привилегий не работает для агентов программирования, поскольку их допустимое пространство действий не ограничено: одна легитимная задача может устанавливать пакеты, записывать данные по произвольным путям и выполнять только что сгенерированный код. Edera формулирует это прямо — применить принцип минимальных привилегий к агенту невозможно, поскольку допустимое пространство поведения не поддаётся перечислению. Каждая команда, выглядящая деструктивно, является при этом чем-то, что агент делает в обычной работе.

Сценарии сбоев не гипотетические. Собственный журнал инцидентов Anthropic, связанных с auto-режимом, описывает случаи, когда агенты удаляли удалённые ветки git, загружали GitHub-токен аутентификации инженера и пытались выполнять миграции против производственной базы данных. Вот в чём угроза: не злой умысел, а недетерминированный процесс с полным доступом к shell, делающий что-то правдоподобное и неправильное.

Ограничение радиуса поражения: модель многоуровневой защиты

Рабочий принцип, заимствованный у Edera, состоит в том, чтобы рассматривать это как задачу обеспечения устойчивости, а не задачу политики: принять, что что-то в конечном счёте пойдёт не так, и убедиться, что когда это произойдёт, сбой останется локализованным. Вы помещаете агента в sandbox не потому, что ожидаете неправильного поведения в этом конкретном запуске; вы делаете это для того, чтобы запуск, который пойдёт не так, обошёлся вам удалённым контейнером, а не утечкой набора учётных данных.

Изоляция имеет два измерения, которые должны выполняться одновременно. Эффективная изоляция требует как ограничений файловой системы, так и сетевых ограничений. Документация по sandboxing в Claude Code явно указывает на эту зависимость: без сетевой изоляции агент может похитить SSH-ключи, а без изоляции файловой системы он может вырваться наружу и получить доступ к сети. Уровень, покрывающий только одно измерение, имеет уязвимость.

Ни один уровень не покрывает все сценарии сбоев, поэтому полезная ментальная модель — это понимание того, от чего защищает каждый уровень, и от чего не защищает:

Две строки заслуживают отдельного внимания. Стандартный контейнер сужает ущерб от «всей моей машины» до «этой папки проекта», но он разделяет ядро хоста, поэтому изначально не предназначен для использования в качестве границы безопасности против кода, которому вы не доверяете, — это удобство изоляции, а не тюрьма. На самом высоком уровне изоляция на уровне ядра всё равно не остановит кражу учётных данных или утечку данных; Edera прямо об этом говорит, отмечая, что аппаратная изоляция не покрывает неправомерное использование учётных данных или сетевую утечку данных — ограничьте их с помощью учётных данных для каждого агента и сетевых политик. Держите секреты за пределами sandbox и устанавливайте egress allowlist независимо от выбранного уровня.

Какой уровень вам на самом деле нужен?

Подбирайте уровень изоляции под риск: встроенная sandbox или auto-режим для повседневного редактирования, devcontainer без прав root для плановых автономных запусков, microVM с собственным ядром для полностью автономного или ненадёжного выполнения, и изоляция ядра на уровне pod только для общей CI-инфраструктуры или мультитенантных систем. Универсального инструмента не существует. Правильный ответ — это правило принятия решений, поскольку разработчик, контролирующий рефакторинг, и CI-задание, обрабатывающее ненадёжные PR, подвержены разным рискам.

Это правило является авторским синтезом, а не утверждением вендора — однако возможности каждого уровня в нём основаны на источниках, приведённых ниже. Цель — избежать избыточной и недостаточной изоляции: не разворачивайте microVM для исправления опечатки, и не запускайте ненадёжные PR в root-контейнере только потому, что так проще.

Claude Code уже поставляется с несколькими из этих уровней

Самая быстрая изоляция — та, которую не нужно строить самому, и Claude Code теперь поставляется с несколькими официальными уровнями изоляции из коробки. Начиная с 20 октября 2025 года, Claude Code поставляется с sandbox на уровне ОС /sandbox для своего инструмента Bash, построенной на Linux bubblewrap и macOS Seatbelt, и выпустил базовый движок как open-source исследовательский превью — @anthropic-ai/sandbox-runtime (репозиторий GitHub anthropic-experimental/sandbox-runtime, бинарный файл srt). Это по-прежнему исследовательский превью — v0.0.49 по состоянию на 3 апреля 2026 года — поэтому относитесь к его API как к нестабильному. README репозитория демонстрирует границу: команда srt "cat ~/.ssh/id_rsa" в sandbox блокируется, а не выводит ваш приватный ключ.

# Демонстрация open-source sandbox-runtime (исследовательский превью, v0.0.49 — API могут измениться)
srt "cat ~/.ssh/id_rsa"   # -> denied: read outside the allowed filesystem

Тот же релиз октября 2025 года добавил Claude Code в веб-версии, которая запускает сессии в изолированной облачной sandbox, где, что принципиально важно, git-учётные данные и ключи подписи никогда не находятся внутри sandbox вместе с агентом.

По-настоящему новым уровнем 2026 года является auto-режим, выпущенный 24 марта 2026 года. Anthropic обнаружила, что пользователи одобряют около 93% запросов разрешений в любом случае, поэтому auto-режим использует классификаторы модели для автоматического одобрения таких запросов и передаёт управление человеку после 3 последовательных или 20 суммарных отказов — это предохранитель против скомпрометированного или слишком активного агента. Он явно предназначен для замены --dangerously-skip-permissions без возврата к постоянным прерываниям, что означает: для большей части повседневной работы он устраняет необходимость использовать полный обход. Всё это не заменяет sandbox для полностью автономных запусков, но меняет подход по умолчанию: прибегайте к YOLO реже, а когда прибегаете — изолируйте надёжнее.

Ограничение сети и защита учётных данных

Запечатывание файловой системы без запечатывания egress оставляет открытым наихудший путь для утечки данных, поэтому сетевой уровень не является опциональным. Чистый примитив — это egress-прокси на стороне хоста с allowlist доменов, чтобы скомпрометированный агент не мог «позвонить домой» или загрузить прочитанные данные. Docker Sandboxes (sbx) поставляются с тремя пресетами, которые можно использовать как ментальную модель: Open (весь трафик разрешён, CLI allow-all), Balanced (запрет по умолчанию с разрешёнными популярными dev-сайтами, CLI balanced) и Locked Down (всё заблокировано, если явно не разрешено, CLI deny-all). Balanced — правильный вариант по умолчанию; Open удобен, но лишает смысла изоляцию при автономных запусках.

Учётные данные требуют отдельной обработки, поскольку простейший способ их утечки — примонтировать их. Не монтируйте ~/.ssh, ~/.aws или ваш .env в среду агента — если секрет не находится в sandbox, агент не может его прочитать. Когда агенту действительно необходимо аутентифицироваться в API модели или сервисе, внедряйте учётные данные на уровне прокси, а не передавайте их агенту напрямую. Docker sbx делает именно это: его forward-прокси на стороне хоста внедряет auth-заголовки для AI-сервисов, так что сами значения учётных данных никогда не хранятся внутри VM, согласно документации по изоляции. Этот паттерн внедрения auth-заголовков в стиле MITM — то, что нужно искать в любой sandbox, которую вы принимаете.

Защита git

Git — это сценарий сбоя, который люди недооценивают, поскольку примонтированный каталог .git полностью доступен для записи агентом. Способ защиты — запускать агента в режиме ветки или worktree, чтобы он делал коммиты в одноразовую ветку, а не в вашу основную. Разбор sbx от Andrew Lock демонстрирует этот паттерн — sbx run claude --branch my-feature/auto помещает агента в git worktree в каталоге .sbx/, который вы добавляете в глобальный gitignore.

Честная оговорка: режим ветки снижает вероятность попадания плохого коммита в main, но не запечатывает git полностью. Как отмечает Lock, агент фундаментально имеет доступ к git-каталогу, поэтому он всё равно может повредить репозиторий — именно поэтому единственным реальным предохранителем является удалённая резервная копия, из которой можно сделать повторный клон. Если репозиторий нельзя восстановить с помощью git clone, значит, резервной копии нет.

Минимальная безопасная конфигурация, которую можно скопировать

Для большинства локальных задач devcontainer без прав root является правильным базовым уровнем: он ограничивает агента рамками проекта, одновременно служит инструментом онбординга новых разработчиков одной командой и удовлетворяет собственному требованию флага о том, что режим обхода не должен запускаться от имени root. Минимальный .devcontainer/devcontainer.json выглядит так:

{
  "name": "agent-sandbox",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "remoteUser": "node",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

Ключевая строка — "remoteUser": "node" — пользователь без прав root, поскольку --dangerously-skip-permissions отказывается запускаться от имени root или через sudo. Монтируйте только каталог проекта; не монтируйте домашний каталог или пути к учётным данным. Установите агента внутри контейнера, направьте его к API модели через egress allowlist и позвольте ему работать.

При полностью автономных запусках или выполнении кода из ненадёжных PR или произвольно сгенерированных скриптов переходите на microVM с собственным ядром:

# Docker Sandboxes: microVM для каждого агента, с собственным ядром и Docker daemon
sbx run claude        # разворачивает изолированную microVM и запускает в режиме обхода

CLI sbx бесплатен для использования, включая коммерческое применение — только организационное управление требует платной подписки — и теперь работает на macOS, Windows и Linux, поддерживая Claude Code, Codex, Copilot, Gemini, Droid, Kiro, OpenCode и другие инструменты. На Linux вам потребуется включённая аппаратная виртуализация KVM и добавление вашего пользователя в группу kvm (см. руководство по началу работы).

Компромиссы реальны и заслуживают упоминания:

• microVM несут накладные расходы на производительность даже в простых проектах;
• подпись коммитов через SSH-агенты хоста не прозрачно пробрасывается в sandbox, поэтому распространённый обходной путь — делать неподписанные коммиты внутри и выполнять rebase с подписью на хосте;
• политика сети «запрет по умолчанию» требует настройки, прежде чем перестанет мешать работе.

За пределами ноутбука: общая инфраструктура и CI

Как только агент запускается на инфраструктуре, разделяемой другими арендаторами или CI-заданиями, уровней защиты для ноутбука становится недостаточно, поскольку общее ядро хоста означает, что эксплойт ядра одного задания может достичь каждой рабочей нагрузки на узле. Решение на этом уровне — изоляция ядра на уровне pod — предоставление каждому агенту собственного ядра Linux в аппаратной sandbox с помощью таких сред выполнения, как Edera, Kata Containers или gVisor. Edera сообщает о запуске каждой рабочей нагрузки в собственном ядре при накладных расходах не более 5% по сравнению с нативной производительностью, с опубликованными бенчмарками на arXiv:2501.04580; это данные, опубликованные вендором, а доступ к Edera осуществляется через их команду, а не через публичную загрузку. Этот уровень избыточен для ноутбука одного разработчика — резервируйте его для случая, под который он создан: мультитенантная инфраструктура или CI, где компрометация одного арендатора не должна становиться проблемой всех остальных.

Выбирайте минимальный уровень, который реально покрывает ваш риск, держите секреты за пределами любого контейнера, в котором работает агент, и устанавливайте allowlist перед его сетью. Тогда в следующий раз, когда агент сделает что-то правдоподобное и неправильное, вы удалите контейнер, а не будете восстанавливать свою машину.

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

В чём разница между auto-режимом Claude Code и режимом обхода разрешений?

Режим обхода разрешений (--dangerously-skip-permissions) полностью отключает запросы подтверждения и большинство проверок безопасности, одобряя каждую команду без какой-либо оценки. Auto-режим, выпущенный в марте 2026 года, использует классификаторы модели для автоматического одобрения только рутинных запросов, которые пользователи всё равно одобряют (около 93% из них), при этом по-прежнему передавая рискованные действия на рассмотрение человеку, и останавливает агента после 3 последовательных или 20 суммарных отказов. Auto-режим предназначен для замены полного обхода в повседневной работе без возврата к постоянным прерываниям.

Делает ли запуск агента программирования в Docker-контейнере безопасным использование режима YOLO?

Стандартный Docker-контейнер сужает ущерб от всей вашей машины до одной папки проекта, но не является полноценной границей безопасности, поскольку разделяет ядро хоста и изначально не предназначен для изоляции кода, которому вы не доверяете. Для плановых автономных запусков на вашем собственном коде контейнер без прав root является разумным решением, но для выполнения ненадёжного или только что сгенерированного кода вам нужна microVM с собственным ядром. Контейнеры также требуют пользователя без прав root, поскольку режим обхода отказывается запускаться от имени root или через sudo.

Почему нельзя просто написать более строгий allowlist вместо помещения агента в sandbox?

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

Защитит ли изоляция файловой системы агента мои учётные данные и SSH-ключи?

Нет. Изоляция файловой системы и сетевая изоляция — это отдельные измерения, и оба должны выполняться. Без сетевых ограничений скомпрометированный агент может похитить SSH-ключи, которые он может прочитать; без ограничений файловой системы он может вырваться наружу и получить доступ к сети. Даже изоляция на уровне ядра сама по себе не защищает от кражи учётных данных или утечки данных. Полностью исключите секреты из sandbox, никогда не монтируя такие пути, как каталоги SSH или AWS, внедряйте учётные данные на уровне egress-прокси при необходимости и устанавливайте allowlist доменов перед агентом.