Summary

Claude Code performs git fetch origin + git reset --hard origin/main on the user's project repo every 10 minutes via programmatic git operations (no external git binary spawned). This silently destroys all uncommitted changes to tracked files. Untracked files survive. Git worktrees are immune.

Environment

• Claude Code version: 2.1.87 (Homebrew cask, compiled Bun binary)
• OS: macOS 15.4 (Darwin 25.3.0, arm64)
• Shell: zsh

Evidence

1. Git reflog: 95+ entries at 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
...
8792b6c HEAD@{2026-03-29 16:55:41 +0200}: reset: moving to origin/main
8792b6c HEAD@{2026-03-29 16:45:41 +0200}: reset: moving to origin/main
...
32aa7c7 HEAD@{2026-03-28 15:47:36 +0100}: reset: moving to origin/main
32aa7c7 HEAD@{2026-03-28 15:37:36 +0100}: reset: moving to origin/main

The second offset is consistent within each session but varies between sessions (:08, :36, :41, :09), confirming a timer tied to session start time with a 600-second interval. 95+ entries observed across 4 sessions over ~36 hours.

2. 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 — modification gone
4. .canary-test.txt (untracked) survived
5. Reproduced consistently across 4 consecutive cycles

3. fswatch caught the file operations

At the exact reset time, fswatch on .git/ captured:

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

This is the classic pattern for git fetch origin + git reset --hard origin/main.

4. Only the Claude Code process is a candidate

lsof confirms the Claude Code CLI process (PID 70111, claude --dangerously-skip-permissions) is the only process with CWD in the affected repo. Two other Claude CLI sessions are in different directories.

5. No external git binary spawned

Process monitoring at 0.1-second intervals found zero git processes around reset times. The operations are programmatic (libgit2 or similar) within the Claude Code process, confirmed by .git/ lock file creation without any external process.

6. Worktrees are immune

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

What was ruled out

A thorough investigation eliminated all external causes:

Binary analysis (partial)

From the compiled binary at /opt/homebrew/Caskroom/claude-code/2.1.87/claude:

• hg1() function does ["fetch","origin"] via t_(C8(), _) without explicit CWD, defaulting to process.cwd()
• io1() function is a git pull wrapper logging git pull: cwd=${H} ref=${_??"default"}
• fileHistory state tracks {snapshots: [], trackedFiles: new Set, snapshotSequence: 0}
• The exact timer/setInterval setup could not be identified in minified code

Impact

Any uncommitted changes to tracked files in the main working tree are silently destroyed every 10 minutes. During a 2-hour session, 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), making it appear intermittent.

Question for the Claude Code team

What internal mechanism runs git fetch origin + git reset --hard against process.cwd() every 600 seconds? This could not be determined from the outside due to the compiled binary and lack of sudo for process tracing.

Workarounds

1. Use git worktrees — confirmed immune (zero reset entries in worktree reflog)
2. Commit frequently — committed changes survive the reset

Related issues