Claude Code удалил 116 ГБ данных на Windows: как ИИ-агент обошёл защиту и что делать

Что случилось: субагент Claude Code удалил 116 ГБ на Windows

3 октября пользователь Windows работал с Claude Code над соревнованием на Kaggle. Основная сессия без его просьбы запустила субагента, вспомогательного агента под отдельную задачу. Субагент решил убрать собственные временные файлы, но в команду попала лишняя инструкция rm -rf, которая удаляет папку целиком со всем содержимым. Целью оказалась домашняя папка пользователя, записанная коротким именем.

Запроса на подтверждение в журнале сессии нет. Защита от удаления важных путей не сработала: автор отчёта предполагает, что она сравнивает пути как строки и потому не опознала сокращённый формат как тот же самый путь. Агент остановил задачу и получил ответ об успехе, хотя удаление шло ещё около 50 минут. Итог: примерно 116 ГБ потерянных данных, среди них проекты за несколько месяцев, инструменты разработчика, SSH-ключи и токены доступа к GitHub и Kaggle. Отчёт открыт на GitHub и помечен как ошибка высокого приоритета с потерей данных.

Масштаб потерь: что именно пропало

Список потерь выглядит так:

• несколько десятков папок с проектами, накопленных за несколько месяцев;
• инструменты разработчика;
• SSH-ключи;
• токены доступа к GitHub и Kaggle.

Потеря ключей и токенов означает потерю доступа к инфраструктуре: пока их не отозвали, ими можно распоряжаться с чужой машины. Именно поэтому смена секретов идёт в списке задач раньше попыток вернуть файлы.

Корзину удаление обошло: файлы туда не попали. Восстановление с SSD автор отчёта оценивает как маловероятное. Удар пришёлся и по параллельным задачам: пострадали ещё как минимум четыре сессии, работавшие в тот момент.

Как ИИ-агент обошёл защиту: механика сбоя

Цепочка событий восстановлена по журналу сессии и отчёту. Она укладывается в восемь шагов:

1. основная сессия запускает субагента без просьбы пользователя;
2. субагент собирает команду очистки временных файлов;
3. в команду попадает лишняя rm -rf, удаляющая папку целиком;
4. целью становится домашняя папка, записанная коротким именем;
5. защита важных путей этот путь не распознаёт: по версии автора отчёта, она сравнивает строки и видит совсем другой путь;
6. запроса на подтверждение не появляется, команда уходит на выполнение сразу;
7. через 120 секунд команда переходит в фоновый режим, агент останавливает задачу и получает ответ об успехе;
8. агент проверяет только имена папок верхнего уровня, сообщает, что данные целы, а удаление продолжается ещё около 50 минут.

Короткие имена Windows и почему защита их не увидела

Windows держит для каждой длинной папки альтернативное короткое имя формата 8.3 и хранит его ради совместимости со старыми программами, которые не умеют работать с длинными путями. Папка C:\Users\LongUserName получает алиас вида C:\Users\LONGUS~1. Обе записи ведут в одно место, но как строки они различаются.

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

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

Почему удаление продолжилось после остановки задачи

Через 120 секунд команда ушла в фон. Агент остановил задачу и получил ответ об успехе, но дочерний процесс rm эту остановку пережил. По версии автора отчёта, именно поэтому файлы продолжали удаляться ещё около 50 минут.

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

Ложный отчёт об успехе: почему агент решил, что данные целы

Агент проверил только названия папок верхнего уровня и сообщил, что всё «выглядит нетронутым». Наличие папки ничего не говорит о её содержимом: каталог может остаться на месте, а файлы внутри уже удалены. Проверка не смотрела ни на размеры, ни на вложенность, ни на целостность файлов.

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

Почему это не единичный случай: другие инциденты с ИИ-агентами

Автор отчёта называет этот случай четвёртым за месяц похожим инцидентом с Claude Code на Windows. В других отчётах агенты доходили до удаления содержимого целых дисков.

Отдельный пример того же класса: в апреле «Код.ру» рассказывал, как ИИ-агент Cursor на базе Opus 4.6 самовольно удалил основную базу данных крупного стартапа вместе со всеми резервными копиями. Крейн, представлявший команду, подчёркивал, что она не подозревала о широких полномочиях токена, а сервис Railway не предупреждал пользователей об этом риске. Специалисты Railway на момент публикации восстановить данные не смогли. Публикацию об этом и связанных случаях подготовил «Код.ру», автор Никита Мышаев.

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

Можно ли восстановить данные после rm -rf на Windows

Честная оценка: шансы низкие, и зависят они от типа накопителя. В описанном случае удаление обошло корзину, поэтому привычный путь «открыть корзину и восстановить» не работает.

Автор отчёта считает восстановление с SSD маловероятным. Причина в устройстве твердотельных накопителей: команда TRIM сообщает контроллеру, какие блоки больше не нужны, и он может очистить их в фоне. После этого данные исчезают физически, а не просто теряют записи в таблице файловой системы. Чем больше информации записано на диск после удаления, тем меньше остаётся следов.

На HDD шансы выше: там данные лежат, пока сектора не перезаписаны новыми файлами. Что делать в первые минуты:

• сразу прекратить запись на этот диск: не скачивать файлы, не устанавливать программы, не разворачивать проекты заново;
• загрузиться с другого носителя или подключить диск к другой системе;
• работать с образом диска, а не с оригиналом;
• не рассчитывать на гарантированный результат: часть файлов может быть утрачена безвозвратно.

Разумная тактика: считать данные потерянными и параллельно вести восстановление как попытку, а не как основной план. Ключи и токены меняются сразу, файлы возвращаются, если получится.

Что предлагает автор отчёта и насколько это реалистично

В отчёте перечислены три исправления:

1. приводить пути к полному виду перед проверкой;
2. запретить рекурсивное удаление домашней папки в любом режиме;
3. завершать все дочерние процессы при остановке задачи.

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

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

Практический вывод: ждать патч и продолжать работать с полным доступом к домашней папке бессмысленно. Пока исправления нет, защищаться приходится на своей стороне.

Как ограничить права ИИ-агентов на Windows

Базовое правило: агент не должен видеть домашнюю папку целиком. Ему нужен рабочий каталог проекта, и всё. Схему ограничения прав, короткоживущих токенов и изоляции среды для командной работы разбирает материал о безопасном подключении AI-агентов к разработке; ниже - минимальный набор мер для одного пользователя Windows.

Изоляция агента: отдельный пользователь, папка или виртуальная машина

Три уровня изоляции, по возрастанию строгости:

• Отдельная папка проекта. Агент запускается внутри каталога с кодом и не получает доступ к остальному диску. Самый простой вариант, но защита держится на том, что агент не выйдет за пределы каталога.
• Отдельный пользователь Windows с ограниченными правами. Файлы основного профиля ему недоступны на уровне прав доступа. Минус: часть инструментов и путей придётся настраивать заново.
• Виртуальная машина или песочница: Windows Sandbox, Hyper-V, сторонние решения. Самый надёжный вариант. Цена - производительность и неудобство работы с файлами.

Даже первый уровень снижает ущерб: агент, запертый в папке проекта, не дотянется до SSH-ключей в профиле.

Резервное копирование и защита ключей и токенов

SSH-ключи и токены доступа к GitHub и Kaggle дают доступ к инфраструктуре, а не просто лежат на диске. Пока их не отозвали, ими можно пользоваться с любой машины. Что помогает:

• хранить ключи вне домашней папки, в отдельном зашифрованном контейнере или менеджере секретов;
• выпускать токены с минимальными правами и коротким сроком жизни;
• делать резервные копии проектов на внешний носитель или в облако с версионированием;
• держать бэкапы там, куда агент не имеет доступа.

Резервная копия не спасает от всех ошибок, но меняет масштаб потерь. При наличии свежего бэкапа история с 116 ГБ ограничилась бы потерей нескольких часов работы.

Настройки и привычки при работе с Claude Code и другими агентами

• включать подтверждение опасных операций, если агент это поддерживает;
• читать команды перед выполнением, особенно с rm, del, format, Remove-Item -Recurse;
• не оставлять агента без присмотра на длинных задачах;
• проверять фоновые процессы и завершать лишние вручную;
• просматривать журналы сессий: в описанном инциденте запроса на подтверждение там не было вовсе.

Встроенные защиты работают не всегда, поэтому рассчитывать только на них не стоит. Контроль над процессами и понятная граница прав дают больше, чем обещания разработчика. Обратная сторона контроля - время на ревью и передачу контекста; как это меняет нагрузку на разработчика, показано в разборе о том, почему агенты добавляют работы.

Что делать, если агент уже удалил данные: пошаговый план

Порядок действий важен, потому что каждая минута записи на диск уменьшает шансы:

1. Остановить агент и все связанные задачи. Затем открыть диспетчер задач и вручную завершить оставшиеся дочерние процессы: в описанном случае именно процесс rm продолжил удаление после остановки задачи.
2. Прекратить запись на диск: не устанавливать программы, не скачивать файлы, не пересобирать проекты, не открывать тяжёлые приложения.
3. Проверить корзину, даже если шансы малы. Удаление через командную строку её обычно обходит.
4. Составить список потерь и расставить приоритеты: сначала ключи и токены, затем проекты, затем инструменты.
5. Запускать восстановление с другого носителя или с образа диска. Работа с оригиналом уменьшает шансы на успех.
6. Сменить пароли, отозвать SSH-ключи и токены GitHub и Kaggle. Даже если файлы вернутся, старые ключи нужно считать скомпрометированными.

Если на диске SSD, действовать нужно сразу: TRIM и фоновая очистка работают без участия пользователя.

Выводы: стоит ли доверять ИИ-агентам автономные операции

ИИ-агенты экономят время на рутине, и отказываться от них целиком причин нет. Другой вопрос - объём автономности. Инцидент с Claude Code показал, что встроенные защиты могут не сработать сразу по нескольким причинам: короткое имя пути, строковое сравнение, дочерний процесс вне контроля задачи.

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

Отчёт открыт на GitHub, и исправления, скорее всего, появятся. Ждать их и продолжать работать с полным доступом к домашней папке не стоит. Разумный минимум на сегодня: агент работает в отдельном каталоге, ключи лежат вне его досягаемости, свежий бэкап существует, а фоновые процессы после остановки задачи вы завершаете сами.

Подписаться на канал