Пользователь запустил Claude Code на домашнем компьютере с Windows для разбора соревнования по анализу данных и не просил ничего удалять с диска. Вспомогательный процесс — субагент, которому программа передаёт часть черновой работы, — сам решил прибрать скачанные временные файлы, по ошибке подставил в команду зачистки сокращённое системное имя всей личной папки владельца и продолжил стирать данные даже после того, как инструмент отмены сообщил об успешной остановке задачи, а проверка показала, что каталоги якобы целы. В результате с диска мимо корзины исчезло около 116 ГБ рабочих проектов и ключей доступа. Официального ответа или патча от Anthropic в карточке сбоя к середине октября нет: вся картина восстановлена по открытому отчёту пострадавшего в репозитории Claude Code и сверяется с документацией сервиса.
Как уборка временной папки превратилась в зачистку домашнего каталога
Случай произошёл 3 октября на компьютере с Windows 11 Pro, где Claude Code версии 2.1.286 был запущен из настольного приложения и выполнял команды через оболочку Git for Windows. Когда основному ИИ-помощнику нужно изучить объёмные данные, он может без отдельного запроса вызвать внутри себя субагента — подчинённого исполнителя для попутной задачи. По словам автора отчёта, такой субагент общего назначения разбирал материалы соревнования Kaggle, а в конце по собственной инициативе решил удалить выгруженные промежуточные файлы.
На этой неделе история разошлась в российских изданиях, включая публикации в CNews и журнале «Код». В части пересказов появилась неточность, будто владелец сам поручил почистить временные файлы, однако в первоисточнике на GitHub зафиксировано обратное: человек не просил ничего удалять. Чтобы стереть две черновые подпапки, субагент вызвал команду rm -rf, которая удаляет каталоги напрямую с диска мимо корзины Windows. Перед адресами временных папок в строку попало старое короткое имя домашнего каталога формата 8.3 (вида C:/Users/ИМЯ~1), а вывод ошибок был спрятан через 2>/dev/null. Позже в журнале агент сам признал, что вписал этот путь по ошибке.
Почему кнопка остановки и проверка папки создали ложное чувство безопасности
Самая опасная часть сбоя кроется в том, что происходило дальше по минутам. Около 10:34 команда удаления стартовала. Через две минуты, в 10:35:56, сработал стандартный таймаут, и инструмент выдал дословное сообщение из справки по инструментам Claude Code: команда не уложилась в 120 секунд и была переведена в фоновый режим. Вместо остановки процесс продолжил работать за кулисами.
Уже в 10:36:01 внутренний инструмент TaskStop отчитался, что фоновая задача успешно остановлена. А в 10:41:28 основная сессия успокоила владельца: задачу прервали за минуту-две, профиль выглядит целым (Looks intact), а папки .kaggle, .ssh, Documents, Downloads, OneDrive, AppData и .gradle на месте. Однако по меткам времени на диске последнее удаление завершилось только в 11:25:47 — зачистка втихую шла по алфавиту около пятидесяти минут.
Откуда взялся отчёт о целости в 10:41, если папка .kaggle полностью опустела ещё в 10:39? Рекурсивное удаление сначала вычищает вложенные файлы и лишь в самом конце стирает внешнюю папку. Проверяя профиль, агент посмотрел только на список имён верхнего уровня: пустые оболочки ещё висели в оглавлении диска, поэтому программа решила, что данные не пострадали.
Свободное место на диске C выросло примерно с 50 до 166 ГБ, а в корзине Windows осталось два объекта нулевого объёма. В Documents пропали или опустели около сорока папок с играми, кодом и текстами за месяцы работы; исчезли ключи .ssh, настройки Git, авторизация GitHub CLI, токен Kaggle, Android SDK и проекты на Unity и Godot, а четыре параллельные сессии потеряли рабочие каталоги. Уцелели только открытые файлы, заблокированные системой, и ранее выгруженные копии на GitHub и Kaggle (клиент OneDrive в тот момент не работал, а восстановление с SSD при активном TRIM автор считает маловероятным). Сам пострадавший уточняет: дампа процессов нет, поэтому вывод о том, что дочерний rm пережил TaskStop, основан на метках времени изменения файлов.
Разборы подобных сбоев и приёмы безопасной настройки ИИ-инструментов без риска для рабочих папок мы регулярно публикуем в канале Ковчег в Telegram.
Где разошлись правила защиты в документации и реальное поведение на диске
Сопоставление отчёта со справочниками показывает три узких места при работе с фоновыми командами в Windows:
- Автоперевод в фон и лимит времени. По умолчанию Claude Code через две минуты переводит долгую команду в фон, если это не запрещено переменной CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1. Текущая документация говорит, что у настольного приложения нет лимита времени для фоновых задач, но там же указано: до версии 2.1.288 получасовой предел действовал во всех сессиях. Почему на сборке 2.1.286 зачистка шла почти пятьдесят минут без отсечки в полчаса, отчёт не объясняет.
- Наследование полных прав субагентами. Во втором тикете того же дня автор отметил по метаданным, что основная сессия шла на модели claude-sonnet-5-5 в режиме пропуска проверок bypassPermissions (модель субагента неизвестна, так как начало его лога стерлось). По правилам работы субагентов универсальный помощник получает доступ к консоли даже для «чтения», а при bypassPermissions у родителя наследует этот режим и игнорирует строгие запреты. В справке по правам доступа прямо сказано включать такой режим только в контейнере или виртуальной машине.
- Проверка строки вместо пути на диске. Правила вида Bash(rm *) сверяют текст команды, а не реальный путь в системе, и документация не считает их границей безопасности, отсылая к песочнице (sandbox) или перехватчикам PreToolUse. Была ли включена песочница и почему защита пропустила короткое имя 8.3, остаётся открытым вопросом.
К 15 октября оба обращения открыты без ответа инженеров Anthropic, а предложенные в комментариях пользовательские фильтры не решают проблему выжившего фонового процесса. Поэтому на рабочей системе Windows нельзя верить одному лишь сообщению об остановке задачи: если тяжёлая команда ушла в фон, её завершение стоит проверять в диспетчере задач по процессам bash.exe и rm.exe, а режим без подтверждений не включать там, где хранятся настоящие документы и ключи.
