Docker Sandboxes для запуска ИИ-агентов для программирования

Docker Sandboxes запускает агента для программирования (Claude Code, Codex, Copilot или Cursor) внутри локальной микро-ВМ. У микро-ВМ собственное ядро и собственный Docker Engine. С хостом она разделяет только каталог проекта, а локальный запуск бесплатен.

Если вы хоть раз за день подтверждали сотню запросов на ls и npm test, вам знакомо желание включить флаг пропуска разрешений. И, скорее всего, знакомо и беспокойство о том, что агент может натворить на вашем ноутбуке, когда этот флаг включён.

В статье разберём, что именно изолирует песочница, как настроить её от установки до первой сессии, как забрать результаты работы агента, чем она отличается от альтернатив и сколько стоит. Инструмент ещё не достиг версии 1.0 и быстро меняется.

Чем опасна полная автономия на вашем ноутбуке

Агент в режиме полной автономии выполняет shell-команды, устанавливает пакеты и редактирует файлы, ни о чём не спрашивая, и делает всё это от имени вашей учётной записи. Значит, ему доступны домашний каталог, SSH-ключи, облачные учётные данные и локальные сервисы. Один неудачный rm -rf или git reset --hard может уничтожить незакоммиченную работу.

Обычная защита — запросы на подтверждение, но они лишают агента смысла. Длинные задачи останавливаются на каждой команде, и после двадцатого запроса большинство людей подтверждают не читая. Лучше не доверять агенту больше, а перенести его туда, где он не сможет нанести серьёзного вреда. Общие доводы в пользу изоляции агентов приведены в статье о безопасном запуске агентов в режиме YOLO. Здесь же речь пойдёт о конкретном инструменте.

Почему Docker Sandboxes использует микро-ВМ, а не контейнер

Обычный Docker-контейнер использует ядро хоста. Любой процесс с доступом к Docker-сокету может запустить привилегированный контейнер, который смонтирует вашу файловую систему. В документации Docker о поверхности атаки демона прямо сказано, что демон работает от root и управлять им должны только доверенные пользователи. Агентам часто нужен Docker, поэтому очевидное решение — смонтировать /var/run/docker.sock — фактически отдаёт им всю машину.

Согласно документации Docker об уровнях изоляции, каждая песочница — это микро-ВМ с собственным ядром Linux и собственным Docker Engine. Агент может выполнять docker build и docker run внутри песочницы без привилегированной настройки, которой требует Docker-in-Docker, а демон хоста вообще не задействуется.

Настройка Docker Sandbox от начала до конца

Установите CLI sbx, войдите в Docker, передайте агенту учётные данные для доступа к модели и запустите sbx run из каталога проекта. В официальном руководстве отмечается, что на хосте не нужны ни Docker Desktop, ни Docker Engine.

Установите инструмент командой для вашей ОС:

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Ubuntu: add Docker's apt repo, install, then grant KVM access
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

В Linux нужен KVM, а ваш пользователь должен входить в группу kvm. Docker тестирует и поддерживает sbx на Ubuntu. Для других дистрибутивов релизные файлы есть в репозитории sbx-releases, но Docker не гарантирует их работоспособность. Требования к платформам смотрите на странице установки.

Затем запустите сессию Claude Code:

sbx login
sbx secret set anthropic        # skip if you use a Claude subscription
cd ~/my-project
sbx run --name my-project claude

• API-ключ: sbx secret set anthropic сохраняет ключ на хосте. Прокси песочницы добавляет его в API-запросы агента, так что сам агент никогда не видит ключ в открытом виде. Для Codex используйте sbx secret set openai. Если ключ уже экспортирован в вашей оболочке, sbx secret import --dry-run покажет ключи, которые видит sbx, а sbx secret import сохранит их после подтверждения каждого.
• Подписка: секрет не нужен. В случае Claude введите /login после запуска Claude Code в песочнице. В случае Codex sbx сначала выполняет вход в OpenAI на хосте и только потом создаёт песочницу.

При первом запуске sbx попросит выбрать сетевую политику по умолчанию. После этого агент стартует в режиме полной автономии: Claude Code не будет запрашивать разрешения, и никакие флаги передавать не нужно. Для другого агента замените claude на codex, copilot, cursor или gemini.

Папка проекта — единственная часть вашей машины, в которую агент может писать, и удалить он может в ней что угодно. Перед началом сделайте коммит или push.

Как забрать результаты работы агента?

В режиме по умолчанию правки агента в Docker Sandbox сразу появляются в рабочем дереве на хосте. Просматривайте их как обычно:

git diff

В старых руководствах, включая пример репозитория из quickstart от Docker, упоминается флаг --branch, который переводил агента в worktree на стороне хоста в каталоге .sbx/. Этот флаг удалили в sbx v0.31.0 в пользу режима клонирования. Теперь при его использовании выводится ошибка с предложением использовать --clone.

Режим клонирования не пускает агента в ваше рабочее дерево. Как описано в документации по работе с Git, sbx создаёт приватный Git-клон внутри песочницы, и агент работает с этой копией. На хосте ничего не меняется, пока вы не сделаете fetch ветки агента или пока агент не выполнит push в удалённый репозиторий. Режим клонирования выбирается только при создании песочницы, поэтому передайте --clone при первом запуске. Переключить существующую песочницу позже нельзя.

Практические вопросы

Какую сетевую политику выбрать?

Docker Sandboxes предлагает три локальные сетевые политики:

• Open разрешает весь трафик.
• Balanced по умолчанию запрещает трафик, но разрешает распространённые сервисы для разработки.
• Locked Down блокирует всё, что явно не разрешено.

Для большинства задач во фронтенде подойдёт Balanced. Эта политика охватывает реестры пакетов, хостинги кода и API провайдеров ИИ. Если агенту нужен сайт, которого нет в списке, например сайт с документацией, выполните sbx policy check network <domain>, чтобы проверить, заблокирован ли он, а затем разрешите его командой sbx policy allow network <domain>. Список правил выводит sbx policy ls, удалить правило можно командой sbx policy rm. Встроенные наборы агентов также могут добавлять собственные разрешающие правила для каждой песочницы — даже при политике Locked Down.

Сохраняется ли состояние?

Да. Инструменты, которые устанавливает агент, и любые изменения в ОС остаются в песочнице, пока вы её не удалите. Команда sbx rm my-project стирает окружение и все секреты, привязанные к этой песочнице. Глобальные секреты и папка проекта не затрагиваются.

Как переподключиться?

Чтобы переподключиться к существующей Docker Sandbox, выполните sbx run --name my-project. Повторно указывать имя агента не нужно — оно берётся из существующей песочницы. Запуск sbx без аргументов открывает интерактивную панель.

Docker Sandboxes в сравнении с контейнерами, devcontainers и удалёнными ВМ

Каждая альтернатива жертвует хотя бы одним из трёх свойств: изоляцией ядра, безопасным доступом к Docker или встроенной политикой исходящего трафика.

Если на самом деле вам нужно контролировать, какие инструменты может вызывать агент, а не изолировать его окружение, обратитесь к статье Docker MCP для ИИ-агентов.

Ограничения и стоимость Docker Sandboxes

Локальные песочницы бесплатны. Согласно примечаниям к выпуску v0.45.0, облачные песочницы находятся в экспериментальном статусе и требуют активной подписки Docker Agentic Platform. Инференс моделей вы оплачиваете своим ключом или подпиской. Для sbx login нужна учётная запись Docker. Продукт молодой, поэтому цены и флаги могут меняться.

• Каталог проекта полностью доступен для записи, поэтому незакоммиченная работа не защищена.
• Всё, что агент отправляет через push или на разрешённый домен, покидает песочницу.
• Ресурсы задаются флагами --memory и --cpus. Локально по умолчанию выделяется половина оперативной памяти хоста, но не более 32 ГиБ. Задокументированные значения по умолчанию (2 CPU и 4 ГиБ) относятся к облачным песочницам.
• Подпись коммитов по SSH работает через проброс SSH-агента, который включён по умолчанию, если на хосте задана переменная SSH_AUTH_SOCK. При этом Git внутри песочницы всё равно нужно настроить на подпись проброшенным ключом.
• Эндрю Лок (Andrew Lock) в апреле 2026 года сообщил, что запуск в песочнице сильно замедлял работу даже с простыми проектами.

Заключение

Docker Sandboxes даёт агенту для программирования собственное ядро, собственный Docker Engine и сеть под управлением политик, а единственная часть вашей машины, к которой он может прикоснуться, — папка проекта. Чтобы начать, закоммитьте свою работу, установите sbx, выберите Balanced и выполните sbx run --name my-project claude на репозитории, потерю которого вы можете себе позволить. Переходите на режим клонирования, когда захотите, чтобы изменения агента не попадали в ваше рабочее дерево до проверки.

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

Как открыть dev-сервер, который агент запустил внутри Docker Sandbox?

Опубликуйте его порт с помощью sbx ports. Команда sbx ports my-project --publish 3000:8080 сопоставляет порт 3000 на хосте с портом 8080 в песочнице, а --publish 8080 без указания порта хоста выбирает эфемерный порт. Пока вы этого не сделаете, браузер не сможет обратиться к сервисам внутри песочницы. Кроме того, dev-сервер должен слушать адрес 0.0.0.0, а не 127.0.0.1, поэтому многим фреймворкам нужен флаг --host 0.0.0.0.

Может ли агент читать другие каталоги, не имея права их изменять?

Да. Укажите дополнительные пути после основного рабочего пространства и добавьте к каждому суффикс :ro, чтобы сделать его доступным только для чтения, например sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro. Агент стартует в первом пути. Каждое рабочее пространство доступно внутри песочницы по тому же абсолютному пути, что и на хосте. Дополнительные рабочие пространства монтируются напрямую с хоста, даже если основное использует режим клонирования.

Как забрать коммиты из песочницы в режиме клонирования?

Выполните fetch из удалённого Git-репозитория, который sbx добавляет в ваш репозиторий на хосте под именем sandbox- плюс имя песочницы. Затем сравнивайте или сливайте изменения так же, как с любым другим удалённым репозиторием. Git-сервер для клона находится внутри песочницы, поэтому git fetch не сработает, пока песочница остановлена. sbx rm также удаляет этот удалённый репозиторий, поэтому перед удалением песочницы сделайте fetch или push всего, что хотите сохранить.