ИИ-агент Claude удалил 48 218 файлов вместо копирования проекта: что это говорит о безопасности вайбкодинга

ИИ-агент Claude получил задачу собрать зеркало проекта, а вместо этого создал скрипт полной очистки и за 103 секунды удалил 48 218 рабочих файлов из дерева проекта в Windows. Удаление уложилось в интервал с 22:10:31 по 22:12:14. Вместе с файлами исчезло хранилище объектов Git, и восстановить данные полностью не удалось. Разбор инцидента опубликован 26 сентября 2026 года.

Формально ничего опасного в задаче не было: проект нужно было скопировать для задачи №873. Катастрофу вызвало техническое предположение, которое не выдержало проверку в среде Windows. При этом после деструктивных действий агент написал «Я что-то сломал».

Что случилось: хронология инцидента с Claude

Кто такой разработчик-вайбкодер и что он поручил агенту

Вайбкодер - это разработчик, который пишет код в основном через ИИ-агентов: формулирует задачу обычным языком, а модель сама создаёт и выполняет команды. В этом случае разработчик поручил Claude собрать зеркало проекта, то есть полную копию рабочего дерева Dashboard, для задачи под номером «#873». Ничего разрушительного в просьбе нет: зеркала нужны для тестов, сборок и проверок, чтобы не трогать основную версию.

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

103 секунды: как разворачивались события

Скрипт build_mirror.py не смог обновить зеркало «на месте», и агент пошёл другим путём: написал на Python отдельный скрипт, который удалял старую копию, хранившуюся во временной директории. Дальше счёт пошёл на секунды.

Собственный лог скрипта зафиксировал 55 550 файлов, 614 ссылок и 1 808 директорий. В зеркале должно было находиться 7 332 обычных файла. Вычтя это число, автор отчёта об инциденте получил 48 218 удалённых рабочих файлов.

Показатель	Значение
Интервал удаления	22:10:31-22:12:14, то есть 103 секунды
Строки в логе скрипта	55 550 файлов, 614 ссылок, 1 808 директорий
Файлы, которые должны были попасть в зеркало	7 332
Удалённые рабочие файлы	48 218
Очищенные каталоги	728, в том числе 418 в каталоге Runners
Пути в сохранившемся индексе Git	7 221

Реакция агента и попытки восстановления

Восстановить данные полностью не удалось. Сильнее всего пострадало хранилище Git: директории .git/objects, refs и logs оказались пустыми, поэтому команда git log перестала находить коммиты.

Индекс Git сохранился и по-прежнему содержал список из 7 221 пути, но сами объекты (blob-файлы) исчезли. Без объектов вернуть историю средствами Git невозможно. Верификатор насчитал 728 очищенных каталогов, включая 418 в каталоге Runners, тогда как корневые файлы, документация, резервные копии, записи чатов и файлы за пределами панели управления остались нетронутыми.

Почему скрипт удалил лишнее: техническая причина простыми словами

Зеркало содержало 7 332 обычных файла и 614 символических ссылок на директории (junctions) в Windows, которые указывали обратно на рабочее дерево проекта Dashboard. Скрипт очистки использовал функцию os.walk(..., followlinks=False) и, судя по логике кода, рассчитывал, что она не даст перейти по ссылкам в связанные директории.

В Windows это предположение оказалось фатальным: функция os.path.islink() возвращала false для junction-ссылок, из-за чего скрипт воспринимал связанные директории как обычные пути и обходил защиту для вложенных папок. Механизм защиты срабатывал только для файлов в корне ссылки. По данным разбора инцидента, вложенные директории обходились и удалялись.

Что такое junction-ссылки и почему Windows их «не видит»

Junction - это ссылка на папку в файловой системе Windows. Работает она похоже на ярлык, но на более глубоком уровне: программы обращаются к ней как к обычной директории. Python распознаёт её не всегда: функция os.path.islink() возвращает false. Так ведёт себя стандартная библиотека Python в среде Windows, и винить в этом конкретную модель не стоит.

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

Как защита обошла сама себя

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

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

Что такое вайбкодинг и почему он стал массовым

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

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

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

Риски ИИ-агентов с доступом к реальным действиям

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

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

Почему «просто попросить» недостаточно

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

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

Песочница и изоляция: что это и зачем

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

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

Почему Git не спас: ограничения системы контроля версий

Git хранит содержимое проекта в виде объектов (blob-файлов) внутри каталога .git/objects, а индекс содержит только список путей. Если объекты удалены, индекс бесполезен: он знает, какие файлы должны быть, но не хранит их содержимое.

В инциденте директории .git/objects, refs и logs оказались пустыми, поэтому git log перестал находить коммиты. Индекс сохранился и содержал 7 221 путь, но восстановление средствами Git провести не удалось. Git помогает откатить изменения, однако резервную копию он не заменяет. Отдельный бэкап вне рабочего каталога, желательно с версионированием и хранением на другом носителе, остаётся базовой страховкой.

Как защититься: практические меры для команд и пользователей

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

Чек-лист безопасности при работе с ИИ-агентами

• Запускайте агента в песочнице или на копии данных, а не на рабочем дереве.
• Включите ручное подтверждение для удаления, перезаписи и массового перемещения файлов.
• Делайте резервные копии вне Git и вне рабочего каталога.
• Читайте скрипты, которые создал агент, до запуска: ищите вызовы удаления и рекурсивный обход директорий.
• Ограничивайте права агента доступом только к тем папкам, которые нужны для задачи (принцип наименьших привилегий).
• Прогоняйте опасный скрипт на тестовой копии с небольшим объёмом данных.
• Логируйте действия агента, чтобы понимать, что именно он сделал и когда.

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

Что это значит для не-разработчиков: ИИ в быту и на работе

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

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

Реакция сообщества и удаление поста с Reddit

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

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

Есть вопрос или заметили неточность в разборе? Напишите нам, мы обновим материал.