docker • 12 минут

Как Docker Sandboxes защищают от разрушительных команд AI‑агентов: уроки инцидента rm -rf ~/

В декабре 2025 года пользователь Reddit под ником u/LovesWorkin описал, как запрос к Claude Code очистить старый репозиторий привёл к выполнению команды rm -rf tests/ patches/ plan/ ~/. Из‑за завершающего символа ~/ оболочка раскрыла тильду в полный путь к домашнему каталогу, и рекурсивное удаление без подтверждения стёрло всё содержимое диска: документы, фотографии, ключи SSH, связку ключей и даже собственные учётные данные агента. Восстановить данные оказалось невозможно из‑за включённого TRIM на SSD.

Почему такие сценарии повторяются

Современные AI‑кодинг‑агенты работают прямо в оболочке пользователя: они читают запрос, генерируют команду и сразу же исполняют её с теми же привилегиями, что и у разработчика. Между этапом «рассуждения» и этапом «выполнения» нет отдельного слоя подтверждения. По умолчанию многие агенты спрашивают разрешение перед каждой командой, но флаг --dangerously-skip-permissions отключает эту проверку, делая работу более плавной, но одновременно открывая путь для разрушительных действий.

Инцидент с u/LovesWorkin не является изолированным. Ранее в октябре 2025 года в issue #10077 на GitHub описывался аналогичный случай на Ubuntu/WSL2, когда агент начал удалять файлы от корня, получая множество сообщений «Permission denied», но всё же стёр все пользовательские данные. В ноябре того же года issue #12637 показал другой путь: агент создал каталог с именем ~, а позже, пытаясь удалить его, оболочка раскрыла тильду в реальный домашний каталог. Позже, после релиза Claude Cowork, агент удалил 15‑летний архив семейных фотографий, обойдя корзину macOS.

Как Docker Sandboxes меняют модель выполнения

Docker Sandboxes предлагают фундаментально иной подход: вместо запуска агента непосредственно на хосте агент помещается в лёгкий микровиртуальную машину со своим ядром, файловой системой и сетевым стеклом. Изнутри песочницы переменная окружения HOME указывает на смонтированную рабочую директорию проекта, а не на реальный домашний каталог разработчика. Следовательно, любая команда вида rm -rf ~/ влияет только на содержимое песочницы, а хост‑система остаётся нетронутой.

Архитектура песочницы реализована через CLI‑утилиту sbx. Сама песочница — это изолированное окружение; sbx используется для её создания, запуска и управления.

Практическое начало работы с `sbx`

# Установка CLI (на macOS через Homebrew)
brew install docker/tap/sbx
# Авторизация в Docker Hub (необходимо для образа песочницы)
sbx login
# Переход в каталог проекта
cd ~/my-project
# Запуск AI‑агента внутри изолированной песочницы, привязанной к текущей директории
sbx run claude

После выполнения sbx run claude агент получает доступ только к файлам, находящимся в ~/my-project. Если он сгенерирует команду rm -rf tests/ patches/ plan/ ~/, то внутри песочницы будет удалено лишь содержимое этого проекта, а домашний каталог пользователя на хосте останется целым.

Дополнительные механизмы защиты

Блокировка монтирования чувствительных путей. По умолчанию песочница запрещает монтировать директории, содержащие учётные данные: ~/.aws, ~/.ssh, ~/.docker, ~/.gnupg, ~/.netrc, ~/.npm, ~/.cargo, ~/.config. Любая попытка смонтировать их приводит к отказу запуска песочницы.

Только‑чтение монтирования. Для каталогов, из которых агент должен лишь читать данные, используется суффикс :ro. Например:

sbx run --name docs-review claude /path/to/project /path/to/docs:ro

Попытка выполнить rm -rf против такого монтирования завершится ошибкой на уровне ядра.

Изолированные Git‑worktree. Операции, потенциально разрушающие репозиторий, можно выполнять в отдельной рабочей ветке:

sbx run --name cleanup-agent --branch=cleanup/old-files claude .
sbx exec cleanup-agent git diff main
# Если результат нежелателен — удаляем песочницу
sbx rm cleanup-agent

Изменения остаются внутри worktree; основная ветка main не затрагивается до явного слияния.

Одноразовые песочницы. После завершения работы песочницу можно просто удалить:

sbx ls
sbx rm <имя‑песочницы>

Это гарантирует, что даже в случае катастрофической ошибки агент не оставит постоянных следов на хосте.

Выводы

История с rm -rf ~/ демонстрирует, насколько опасна модель, при которой AI‑агент действует с полными правами пользователя без промежуточного барьера. Docker Sandboxes устраняют эту уязвимость, перенося выполнение агента в изолированное окружение, где его вид файловой системы ограничен рабочей директорией проекта. При этом сохраняется привычный workflow: разработчик по‑прежнему может давать естественные языковые запросы, а агент генерирует и исполняет команды, но любые разрушительные действия остаются внутри песочницы и легко откатываются.

Для команд, работающих с AI‑агентами на Linux‑серверах, VPS или локальных машинах, рекомендуется:

Всегда запускать агента через sbx run вместо прямого вызова.
Проверять, что в монтировании не включены пути к секретам.
Для только‑чтения данных использовать суффикс :ro.
При выполнении потенциально опасных операций очистки или рефакторинга изолировать работу в отдельной Git‑ветке.
Регулярно удалять использованные песочницы, поддерживая чистоту окружения.

Следуя этим практикам, вы получаете те же преимущества от AI‑ассистентов, что и раньше, но без риска потерять годы работы, личные данные или производственные серверы из‑за одной неверно сгенерированной команды.