Claude Code runs git reset --hard origin/main every 10 minutes, destroying uncommitted changes

Summary

Claude Code's internal checkpoint/file-history-snapshot system performs git reset --hard origin/main on the main working tree every 10 minutes, silently destroying all uncommitted changes to tracked files. This was confirmed via 90+ git reflog entries at exact 10-minute intervals and reproduced live.

Environment

• Claude Code version: 2.1.87
• OS: macOS 15.4 (Darwin 25.3.0)
• Shell: zsh
• Node: v22.x
• Git: 2.x

Reproduction Steps

1. Start a Claude Code session in a git repo with a remote
2. Edit a tracked file (e.g., via the Edit tool or manually)
3. Do not commit
4. Wait 10 minutes
5. Run git status — the modification is gone
6. Run git reflog --date=iso | head -5 — you'll see reset: moving to origin/main

Untracked files (new files not yet git add-ed) survive. Only tracked file modifications are destroyed.

Evidence

Git reflog shows exact 10-minute intervals

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
e8ea2c9 HEAD@{2026-03-29 21:39:09 +0200}: reset: moving to origin/main
e8ea2c9 HEAD@{2026-03-29 21:29:09 +0200}: reset: moving to origin/main

90+ such entries were found across 4 sessions over ~36 hours. The second offset is consistent within each session but varies between sessions (:08, :36, :41, :09), confirming a setInterval(fn, 600000) tied to session start time.

Live reproduction

1. Modified src/lib/api.ts (tracked file) and created .canary-test.txt (untracked file)
2. Monitored every 15 seconds
3. At the next 10-minute mark, api.ts silently reverted to clean state
4. .canary-test.txt (untracked) survived
5. Reproduced consistently across 4 consecutive 10-minute cycles

Mechanism is internal to the Node.js process

• fswatch on .git/ detected lock file operations (.git/refs/remotes/origin/HEAD.lock, .git/refs/heads/main.lock) at exact reset times
• No external git binary was spawned — process monitoring at 0.1-second intervals found zero git processes around reset times
• This indicates programmatic git operations (likely libgit2 or similar) within the Claude Code Node.js process
• Session JSONL files contain file-history-snapshot entries with trackedFileBackups and isSnapshotUpdate: True fields

Git worktrees are immune

The worktree reflog shows zero reset: moving to origin entries. The periodic reset targets the main working tree only.

Impact

Any uncommitted changes to tracked files in the main working tree are silently destroyed every 10 minutes. This caused significant rework in a ~2 hour session where changes had to be re-applied 3+ times before the cause was identified.

The bug is invisible when all changes are committed (the reset is a no-op when HEAD equals origin/main), which makes it appear intermittent.

What was ruled out

A thorough investigation eliminated all external causes:

• Git hooks — all inactive (.sample only)
• Claude Code user hooks — audio notifications only, none reference git
• macOS mechanisms — no cloud sync, cron, LaunchAgents, or file watchers covering the project
• Vite/SvelteKit dev server — all file writes go to output directories, zero git awareness
• IDE/editors — no format-on-save, no auto-restore configured

Workaround

1. Use git worktrees — confirmed immune to this bug
2. Commit frequently — committed changes survive the reset

Related Issues

• #8072 — "Critical Bug: Code Revisions Being Repeatedly Reverted"
• #11169 — "Auto-Compact causes model to revert to previously rejected code patterns"
• #10948 — "Auto-compact triggers mid-task causing context loss and hallucinations"