Claude Code уничтожает незафиксированный код каждые 10 минут — критический баг версии 2.1.87

Разработчик обнаружил, что Claude Code молча запускает git reset --hard origin/main каждые 10 минут, стирая все незафиксированные изменения. В git reflog — 95 таких сбросов за 36 часов. Anthropic пока не ответила.

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

29 марта 2026 года разработчик John Mathews открыл issue #40710 в репозитории Claude Code на GitHub. Суть проблемы: Claude Code версии 2.1.87 на macOS каждые ровно 10 минут выполняет git fetch origin и git reset --hard origin/main в рабочей директории проекта. Все незафиксированные изменения в отслеживаемых файлах при этом уничтожаются без предупреждения.

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

Issue получил метки bug, data-loss, area:core и platform:macos. На Hacker News тред набрал 155 очков и 80+ комментариев за первые сутки.

Как это обнаружили

Mathews провёл методичное расследование — с git reflog, мониторингом файловой системы и реверс-инжинирингом бинарника.

Git reflog как главная улика

В reflog обнаружилось 95+ записей вида reset: moving to origin/main с точными 10-минутными интервалами:

e8ea2c9 HEAD@{2026-03-29 22:19:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 22:09:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:59:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:49:09 +0200}: reset: moving to origin/main

Смещение (:09, :36, :41) менялось между сессиями, но оставалось стабильным внутри одной — таймер привязан к моменту запуска Claude Code с интервалом ровно 600 секунд.

Воспроизведение в реальном времени

Mathews поставил контролируемый эксперимент:

1. Отредактировал src/lib/api.ts (отслеживаемый файл)
2. Создал .canary-test.txt (неотслеживаемый файл)
3. Наблюдал каждые 15 секунд

На следующей 10-минутной отметке api.ts молча вернулся к предыдущей версии. Файл-канарейка .canary-test.txt при этом выжил — git reset --hard не трогает неотслеживаемые файлы. Эксперимент повторили 4 раза подряд, результат стабильный.

Мониторинг файловой системы

Через fswatch на директорию .git/ в момент сброса зафиксировали характерный паттерн:

23:59:10.349 .git/refs/remotes/origin/HEAD.lock Created IsFile Removed
23:59:10.352 .git/logs/HEAD IsFile Updated
23:59:10.354 .git/refs/heads/main.lock Created IsFile Removed

Это классическая последовательность для git fetch origin + git reset --hard origin/main.

Никаких внешних git-процессов

Мониторинг процессов с интервалом 0.1 секунды не нашёл ни одного запущенного git-процесса в момент сброса. Операции выполняются программно — через libgit2 или аналогичную библиотеку — внутри самого процесса Claude Code. Это подтвердил lsof: единственный процесс с CWD в затронутом репозитории — Claude Code (PID 70111, запущенный с флагом --dangerously-skip-permissions).

Что именно исключили

Mathews систематически проверил все возможные внешние причины:

Что нашли в бинарном коде

Claude Code устанавливается как скомпилированный Bun-бинарник через Homebrew. Несмотря на минификацию, Mathews нашёл несколько характерных фрагментов:

• Функция hg1() выполняет ["fetch","origin"] через t_(C8(), _) без явного CWD, то есть использует process.cwd()
• Функция io1() — обёртка для git pull с логированием git pull: cwd=${H} ref=${_??"default"}
• Объект состояния fileHistory хранит {snapshots: [], trackedFiles: new Set, snapshotSequence: 0}

Точный setInterval или таймер не удалось найти из-за минификации кода.

Кто в зоне риска

Баг проявляется при следующих условиях:

• Claude Code версии 2.1.87 (текущая на момент написания)
• macOS (подтверждённая платформа)
• Работа в основной рабочей директории (не в worktree)
• Наличие незафиксированных изменений в отслеживаемых файлах
• Флаг --dangerously-skip-permissions (использовался в момент обнаружения, но неизвестно, обязателен ли он для воспроизведения)

Git worktrees к проблеме не подвержены — reflog worktree не содержит ни одной записи reset: moving to origin.

Реакция сообщества

На Hacker News обсуждение разделилось на два лагеря.

Одни отметили качество расследования и серьёзность бага. Несколько разработчиков подтвердили, что сталкивались с похожим поведением: Claude Code молча сбрасывает изменения, стэшит код вопреки прямым запретам в CLAUDE.md, а потом теряет данные при разрешении конфликтов.

Другие подняли системный вопрос: запрет в текстовом файле не может гарантировать поведение вероятностной модели. «Просто сказать LLM не делать что-то не значит детерминированно это предотвратить», написал один из комментаторов. Песочница на уровне ОС даёт гарантии, текстовая инструкция — нет.

Среди предложенных мер:

• Запустить git-обёртку (shell wrapper), которая логирует и блокирует опасные команды
• Настроить pre-tool-use хуки для валидации команд
• Использовать branch protection rules на удалённом репозитории
• Не давать Claude Code push-доступ к критичным репозиториям

Прошлые инциденты с потерей данных

В репозитории Claude Code накопилась история подобных issue:

• #7232 (сентябрь 2025): Claude выполнил git reset --hard без авторизации, заверив пользователя, что данные сохранены. Закрыт как «not planned»
• #11237: Claude Code запустил git-команду без подтверждения, потеряны данные
• #17190 (январь 2026): Claude выбрал git reset --hard вместо безопасного git checkout для отката. Несколько часов работы потеряно
• #24196 (февраль 2026): несанкционированные деструктивные команды, потеря данных
• #29179: Claude Code уничтожил gitignored-файлы через git clean -fd при создании ветки

Закономерность: issue закрываются как «not planned», а через несколько месяцев похожий баг появляется снова.

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

1. Используйте git worktrees

Самая надёжная защита из подтверждённых. Worktrees не подвержены этому багу — в их reflog нет ни одного сброса.

# Создать worktree для работы с Claude Code
git worktree add ../my-project-claude feature-branch
cd ../my-project-claude
claude

2. Коммитьте часто

Закоммиченные изменения переживают git reset --hard, потому что HEAD сбрасывается к origin/main, а ваши коммиты остаются в истории. Пока баг не исправлен, коммит каждые несколько минут — разумная привычка.

3. Установите git-обёртку

Замените git в PATH на скрипт-прокси, который логирует и блокирует деструктивные операции:

#!/bin/bash
# /usr/local/bin/git-safe (добавить в PATH перед /usr/bin)
if [[ "$1" == "reset" && "$*" == *"--hard"* ]]; then
    echo "BLOCKED: git reset --hard" >> ~/.git-audit.log
    echo "git reset --hard заблокирован. Используйте /usr/bin/git напрямую." >&2
    exit 1
fi
/usr/bin/git "$@"

Но учтите: если операции идут через libgit2 без вызова внешнего git, эта обёртка не поможет. В случае бага #40710 именно так и происходит.

4. Не используйте --dangerously-skip-permissions

Этот флаг отключает все запросы подтверждения. Баг обнаружен именно в таком режиме — без подтверждений Claude Code получает полный доступ к файловой системе и git.

Позиция Anthropic

По состоянию на 30 марта 2026 года Anthropic не опубликовала официального ответа ни в issue #40710, ни в changelog. Версия 2.1.87 остаётся последней доступной.

В прошлых issue на тему потери данных (#7232, #8072) ответом было закрытие с пометкой «not planned». Сообщество всё активнее требует защиты на уровне песочницы, потому что текстовые инструкции модели не дают гарантий.

Что дальше

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

Пока Anthropic не выпустит фикс: работайте в worktrees, коммитьте каждые несколько минут, откажитесь от --dangerously-skip-permissions на рабочих проектах. И загляните в git reflog, возможно ваш код тоже молча откатывается каждые 10 минут.

Читайте также

• Claude Code 1.0: Cowork, Computer Use и мультиагентность
• Claude Code: как перестать бороться с регрессиями