Claude удалил разработчику 700 ГБ - тестируя защиту от удаления

Разработчик попросил Claude навести порядок во временных папках, где ИИ-агенты оставляют мусор. Модель написала скрипт-чистильщик с защитой от случайного удаления и решила проверить эту защиту на живых путях - прогнала через неё домашнюю директорию. Защита не выдержала, сработал rm -rf, 700 гигабайт исчезли. Разбираю, как такой баг возможен и что поставить между агентом и твоим диском.

История случилась 26 августа и за выходные разошлась по техноизданиям. Ниже - механика бага, сюжет с подменой модели и список защит, которые работают независимо от того, насколько умный у тебя агент.

Что случилось

26 августа разработчик Себастьен Гийемо выложил короткий пост: «Плохие новости: Fable снёс всю мою dev-машину. Claude решил протестировать песочницу, которую сам строил, запустив rm -rf по моей домашней директории. Песочница не сработала. Всё пропало». Пост собрал больше пяти тысяч лайков, через два дня Tom's Hardware разобрал историю по шагам.

Задача была мирная. Гийемо раздражало, что ИИ-агенты после работы оставляют временные файлы в /tmp. Он попросил Claude - топовую модель Fable - написать скрипт, который изолирует каждого агента в собственной папке и чистит её после завершения. Главная сложность: не трогать файлы тех агентов, которые ещё работают. Ту самую «песочницу» из поста.

По данным Tom's Hardware, итог - около 700 гигабайт удалённых данных и примерно неделя работы. Гийемо успел прервать выполнение, но поздно: по логам сессии между первым опасным присвоением и массовым удалением прошло меньше трёх минут. Соль в том, что /tmp, ради которого всё затевалось, уцелел.

Как защита сама всё удалила

Чтобы доказать, что чистильщик не тронет чужие файлы, агент написал самотест: скормить скрипту заведомо опасные пути - $HOME, /etc - и убедиться, что тот их отвергнет. Идея разумная, так проверяют любые предохранители. Подвела реализация.

Упрощённо баг выглядел так:

CANARY="$SELFTEST_CANARY_DIR"               # значение присвоили
[[ "$CANARY" =~ ^/tmp/[^/]+$ ]] || _pin_die # и только потом проверили

Значение из переменной окружения попало в рабочую переменную до проверки на безопасность. Проверка проваливается - скрипт вызывает _pin_die и завершается. А на завершение повешена уборка: EXIT-трап выполняет rm -rf по той самой переменной. Tom's Hardware называет причиной «коллизию переменных»: одно и то же имя использовалось и как цель теста, и в функции очистки после него.

Путь, который должен был просто остановить скрипт, сам выполнил удаление непроверенного значения. В разборе аварии, который агент написал после случившегося, есть фраза: «Путь отказа сам выполнил удаление. Барьер превратился в спусковой крючок».

Дифф «как было / как надо»: красным - присвоение опасного пути до проверки и rm -rf в пути отказа, бирюзовым - проверка пути до присвоения

При чём тут понижение модели

Дальше в истории появляется поворот. По версии Tom's Hardware, перед финальным прогоном Fable устроила проверку собственного кода копией себя. После этого система безопасности Anthropic сочла задачу рискованной и дважды понизила модель: сначала до Opus 5, затем до Opus 4.8. Финальный тест выполнял уже Opus 4.8.

Издание предполагает, что Fable, которая сильнее в коде, заметила бы противоречие с переменными и не запустила бы тест. Но это гипотеза, а не установленный факт: прямых доказательств, что замена модели стала причиной аварии, нет. Официального комментария Anthropic по инциденту тоже не было. Что подтверждается независимо - так это сам феномен понижения. Летом 2026 пользователи массово жаловались, что Claude на темах про rm, права доступа и скрипты безопасности автоматически уезжает с Fable на более слабую Opus 4.8. Один писал, что понижение случилось даже в теоретическом обсуждении модели прав доступа - без единой команды в консоли.

Для практики отсюда следует неудобный вывод: ты не всегда знаешь, какая модель реально выполняет твою команду. Обвязка вокруг модели может молча подменить исполнителя - я разбирал, как такое устроено, в статье почему один и тот же ИИ в разных программах работает по-разному.

Почему агент решился на rm -rf по живым путям

Самый неудобный вопрос истории. Модель получила задачу «сделай защиту от удаления» и логично решила: защиту надо проверить. Проверка предохранителя - это подать ему опасный вход и убедиться, что он откажет. В этой цепочке нет шага «прогони опасный тест на одноразовой копии данных». Такой шаг добавляет человек, который боится за свои файлы. У агента страха за твои файлы нет, есть задача.

Это не первый случай. В декабре 2025 пользователь запустил Claude CLI с флагом --dangerously-skip-permissions, и агент снёс ему домашнюю директорию на Mac - история тогда собрала на Hacker News тред на двести с лишним комментариев. Инструменты с тех пор поменялись, паттерн тот же: чем больше свободы у агента на файловой системе, тем дороже обходится его ошибка.

Что спасло данные

Полного бэкапа у Гийемо не было. Спасли три скучные вещи: git, nix и логи сессий. Проекты жили в репозиториях, окружение было описано декларативно - то есть не «хранится где-то», а «собирается заново по описанию», - а переписку с агентами сохранили логи. Из этого удалось вернуть большую часть потерянного.

Отдельно про nix, потому что это не очевидный слой защиты. Если твой рабочий стенд описан декларативно - пакеты, конфиги, версии инструментов - то сами файлы окружения перестают быть уникальными. Их можно удалить, и они пересоберутся из описания за один запуск. Agent снёс файлы, но не смог снести рецепт их сборки.

Дерево после инцидента: папки домашней директории пусты, уцелел только /tmp - ради которого всё и затевалось

Как защититься: пять барьеров

Что реально работает - по официальной документации Claude Code и опыту тех, кто гоняет агентов каждый день.

1. Песочница для Bash. Claude Code умеет выполнять команды в изоляции: на macOS это Seatbelt, на Linux - bubblewrap; запись разрешена только в рабочую директорию и временную папку сессии. Важная деталь: если песочница не смогла подняться, команда по умолчанию выполняется без неё. Жёсткий режим включается настройкой sandbox.failIfUnavailable - с ней агент не получит «голую» консоль в случае сбоя изоляции.

2. Отдельная среда для опасных задач. Документация Anthropic прямо советует запускать скрипты агента в виртуальных машинах; для обычного кода хватает devcontainer или Docker-контейнера. Правило простое: чем разрушительнее задача, тем глубже изоляция.

3. Права доступа вместо доверия. Разрешения строятся списками allow/deny/ask: чтение - можно, запись в проект - спроси, удаление вне песочницы - никогда. У deny-правил приоритет выше, чем у allow, поэтому самый простой страховочный слой - запретительная запись для rm по абсолютным путям и для системных каталогов. Режим bypassPermissions существует, но в доках предупреждение написано прямым текстом: включай только в изолированной среде, которую не жалко потерять.

4. Снапшоты и бэкапы. Time Machine на Mac, снапшоты файловой системы, облачная копия - что угодно, что превращает rm -rf из катастрофы в неприятность. У Гийемо этого слоя не было, и именно он стоил недели работы.

5. Гигиена самих скриптов. Значение проверяется до того, как попадает в переменную, которую скормят rm -rf. А тест защит от удаления - только на одноразовых папках с мусорными данными, никогда на живых путях.

Что это значит

Агенты уже не советуют - они исполняют. У совета радиус поражения нулевой, у команды rm -rf в твоей домашней папке - весь диск, до которого дотянулись права. Виноват тут не «тупой ИИ»: модель честно решала полученную задачу, а после аварии честно написала разбор своих же ошибок. Урок в другом: защита от ИИ-агента строится теми же средствами, что защита от любого кода - изоляция, права доступа, бэкапы. Доверяй модели сколько угодно, но не доверяй ей свой $HOME без песочницы.

Больше про границы доверия агентам - в разборе можно ли доверять ИИ-агенту в бизнесе. Про то, почему системы из нескольких агентов ломаются не от глупости моделей, а от архитектуры - в разборе многоагентных систем.