Как Docker Sandboxes защищают от разрушительных команд AI-агентов
В декабре 2025 года пользователь Reddit под ником u/LovesWorkin описал, как агент Claude Code, получив запрос на очистку старого репозитория, выполнил команду rm -rf tests/ patches/ plan/ ~/. Из‑за символа ~/ оболочка раскрыла его в полный путь домашнего каталога, и рекурсивное удаление стёрло всё содержимое Mac‑компьютера: документы, фотографии, ключи SSH, брелок паролей и даже собственные конфигурации агента. Поскольку современные Mac по умолчанию включают TRIM, освобождённые блоки SSD сразу обнуляются, и восстановление данных становится невозможным.
Почему возникает проблема
Современные AI‑кодинг агенты работают непосредственно в оболочке пользователя, наследуя его права и окружение. Они генерируют команду на основе промпта и сразу передают её в шелл без отдельного этапа подтверждения. Если в сгенерированной строке присутствует конструкция, которая после раскрытия переменных или подстановок указывает на системные каталоги, шелл выполнит её без предупреждений. Флаг --dangerously-skip-permissions, который отключает запрос подтверждения перед каждой командой, делает такие сценарии ещё более опасными, потому что агент может выполнять разрушительные операции в фоновом режиме, пока пользователь занимается другими задачами.
Как работают Docker Sandboxes
Docker Sandboxes меняют модель выполнения: агент запускается внутри лёгкой микровиртуальной машины, которая имеет собственное ядро, файловую систему и сетевой стек. Изнутри песочницы переменная ~ указывает не на домашний каталог хоста, а на смонтированную рабочую директорию проекта. Следовательно, даже если агент сгенерирует команду rm -rf ~/, она удалит только содержимое рабочей области внутри микровиртуальной машины, а файлы хоста останутся нетронутыми. После завершения работы песочницу можно просто уничтожить, а хостовая система не понесёт никакого ущерба.
Практические шаги по использованию sbx
Для начала работы с Docker Sandboxes необходимо установить CLI‑утилиту sbx и выполнить вход в аккаунт Docker. После этого можно запускать агент внутри изолированного окружения, привязанного к текущей директории проекта.
# Установка sbx через Homebrew (macOS)
brew install docker/tap/sbx
# Вход в Docker Hub
sbx login
# Переход в каталог проекта и запуск агента в песочнице
cd ~/my-project
sbx run claude
После выполнения этих команд агент окажется внутри микровиртуальной машины, где его представление о ~/ совпадает с каталогом ~/my-project. Любая destructive операция, направленная на эту переменную, затронет только файлы проекта.
Изолированные монтирования и защита учетных данных
По умолчанию в песочнице блокируются попытки смонтировать каталоги, содержащие чувствительные данные: ~/.aws, ~/.ssh, ~/.docker, ~/.gnupg, ~/.netrc, ~/.npm, ~/.cargo и ~/.config. Если в команде запуска указать попытку примонтировать один из этих путей, sbx откажет в старте песочницы, тем самым предотвращая доступ агента к ключам, токенам и конфигурационным файлам.
Для ситуаций, когда агент должен только читать данные, существует возможность монтировать каталог как read‑only:
sbx run --name docs-review claude /path/to/project /path/to/docs:ro
При таком монтировании любая попытка записи, включая rm -rf, будет отклонена на уровне ядра микровиртуальной машины.
Работа с Git-worktree в песочнице
Для операций, которые могут изменить структуру репозитория (например, очистка веток, удаление файлов), удобно использовать изолированные git‑worktree. Песочница может быть запушена на отдельной ветке, а после завершения работы пользователь просматривает diff относительно основной ветки и решает, принимать ли изменения или уничтожить песочницу.
# Запуск агента на отдельной ветке очистки
sbx run --name cleanup-agent --branch=cleanup/old-files claude .
# Просмотр изменений относительно основной ветки
sbx exec cleanup-agent git diff main
# Если результат неудовлетворителен – удаляем песочницу
sbx rm cleanup-agent
Таким образом, даже если агент выполнит rm -rf ~/ внутри worktree, основная ветка репозитория останется нетронутой, а пользователь сможет быстро откатиться к исходному состоянию.
Выводы
Инцидент с удалением домашнего каталога показывает, насколько важно разграничивать права выполнения AI‑агентов и файловую систему хоста. Docker Sandboxes предоставляют архитектурный барьер: агент работает в изолированном микровиртуальном окружении, где его вид ограничен рабочей областью проекта, а чувствительные каталоги недоступны по умолчанию. Использование sbx позволяет:
- Запускать агент с ограниченным доступом к файлам проекта;
- Блокировать монтирование директорий с учетными данными;
- Делать монтирования только для чтения;
- Выполнять потенциально опасные операции в изолированных git‑worktree;
- Быстро устранять последствия ошибок путём удаления песочницы без риска для хоста.
Применение такой модели существенно снижает вероятность потери данных из‑за ошибочно сгенерированных команд и делает работу с AI‑кодинг агентами более безопасной для разработчиков, администраторов VPS и всех, кто ценит целостность своей системы.