Практическая инструкция / Docker Sandbox
Docker Sandbox: короткая настройка
Docker Sandbox запускает агента внутри компьютера в изолированной microVM. Агент видит папку проекта. Доступ к интернету и дополнительным файлам можно ограничить явно заданными правилами. Подключённая папка остаётся настоящей папкой компьютера, поэтому доступ к файлам и секреты нужно настраивать отдельно.
Официальная документация Docker Sandbox ↗Требования
HypervisorPlatform), не полный Hyper-V.Установка
macOS
Проверьте Homebrew командой brew --version. Если команда не найдена, установите Homebrew с официального сайта ↗:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew --version brew trust docker/tap brew install docker/tap/sbx
sbx login
Windows
Требуется именно Windows Hypervisor Platform, а не полный Hyper-V. Откройте PowerShell от имени администратора и проверьте состояние:
(Get-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform).State
Если результат не Enabled, включите компонент. Перезагрузите компьютер только если Windows попросит, затем продолжите:
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All winget install -h Docker.sbx
sbx login
Запуск в проекте
Сначала перейдите в папку проекта. На macOS путь можно перетащить из Finder в терминал.
cd <путь_к_папке_проекта>
sbx run claude и sbx run codex создают или открывают Sandbox для текущей папки. Официальная документация заявляет повторное использование той же пары «агент + абсолютный путь к рабочей папке»; для однозначного поведения используйте имя.
sbx run claude sbx run codex
Команда создаёт my-box при отсутствии и сразу подключает её.
sbx run claude --name my-box .
Вернитесь к именованной песочнице по имени.
sbx run --name my-box
sbx ls показывает список созданных песочниц.
sbx ls
Только для Git-репозитория: отдельный клон создаётся внутри Sandbox, репозиторий на компьютере доступен только для чтения, изменения остаются внутри до fetch/push. Для Codex замените в команде claude на codex.
sbx run --clone --name feature claude .
sbx stop только останавливает песочницу, а sbx rm удаляет её. Запускайте одну нужную команду; вариант --force нужен при активном подключении по SSH/SFTP или в неинтерактивном скрипте.
sbx stop my-box
sbx rm my-box
sbx rm --force my-box
Удаляется внутреннее состояние песочницы; подключённая напрямую папка проекта остаётся на компьютере.
Ограничения: URL, файлы и .env
Дайте ИИ-агенту официальную документацию Docker Sandboxes ↗, затем передайте готовую инструкцию ниже. Она сначала просит аудит только для чтения, а изменения — только после явного подтверждения.
.env и исходные секреты напрямую.Инструкция для ИИ-агента
Помоги безопасно настроить Docker Sandbox для проекта <ПУТЬ_К_ПРОЕКТУ> и песочницы <ИМЯ_SANDBOX>. Сначала прочитай официальную документацию Docker Sandboxes: https://docs.docker.com/ai/sandboxes/ и документацию для установленной версии sbx. Затем выполни аудит только для чтения. Выбери команды по ОС: macOS/Linux: command -v sbx PowerShell: Get-Command sbx sbx version sbx ls --json sbx policy ls --wide sbx policy inspect <policy-or-rule> После sbx policy ls --wide подставь фактический ID или имя policy/rule вместо <policy-or-rule>. sbx secret ls sbx mcp ls sbx skills ls Проверь рабочую папку, подключения, разрешённые домены, сопоставления секретов, MCP и общие навыки. Если CLI возвращает ошибку авторизации (auth error) — остановись, не выполняй login/reset/repair автоматически и сообщи, что это блокер. Не читай, не печатай и не записывай в логи значения .env, Keychain, токенов, API-ключей, OAuth и заголовков Authorization. Показывай только имена переменных и сопоставлений, хосты, пути, имена песочниц, идентификаторы/области правил, имена MCP и навыков. Сначала покажи таблицу фактического состояния, затем план. До любых изменений запроси моё явное подтверждение. Отдельно предупреди, если действие меняет глобальную сетевую политику/секреты, удаляет, сбрасывает или останавливает песочницу, меняет подключения, импортирует навыки/MCP или переносит .env. После подтверждения настрой минимально необходимые права: 1. URL: разреши только домены, необходимые агенту и проекту. Помни, что сетевая политика глобальная. Оставь один контрольный запрещённый домен и проверь разрешение/запрет. Проверь MCP-инструменты: серверный MCP может обходить прямые сетевые ограничения; отключай ненужные только после подтверждения. 2. Файлы: оставь чтение и запись только для папки проекта; дополнительные каталоги подключай только для чтения, если запись не нужна. Не расширяй доступ ко всему home/Downloads. 3. .env/секреты: не оставляй исходные API-ключи доступными внутри рабочей папки. Сначала предложи безопасный план: вынести исходный секрет в файл на хосте с правами 600 и настроить документированное сопоставление секрета для конкретной песочницы (sbx secret set или экспериментальный sbx secret set-custom) для конкретного хоста и окружения. Не передавай исходный ключ через argv и не раскрывай его. Если предлагаешь симлинк из проекта во внешний файл секрета, явно скажи, что это рабочий, но не официальный механизм Docker. 4. Навыки/MCP: используй только подтверждённый разрешённый список, без автоматического импорта. После изменений выполни проверку только для чтения: песочница/рабочая папка, разрешение/запрет каждого нужного хоста и контрольного запрещённого хоста, имена/области сопоставлений секретов без значений, отсутствие исходных секретов в доступных переменных окружения/файлах/логах, подключения, MCP и навыки. Покажи итог и все расхождения.