The false report that Claude Code was running `git reset --hard` every 10 minutes
Contents
On March 29, 2026, a GitHub issue (#40710) was posted claiming that Claude Code was running git reset --hard origin/main every 10 minutes and destroying uncommitted project changes. It got 244 points on Hacker News, appeared in Google Feed, and was picked up by news sites.
About 10 hours later, the reporter found the real cause. It was not Claude Code. It was a separate tool he had written himself.
What was observed
The report sounded convincing because the symptoms were specific.
The reporter, John Mathews, found more than 95 reset: moving to origin/main entries in git reflog, all spaced exactly 10 minutes apart. The second offsets differed per session, but the interval was always 600 seconds. It reproduced across four sessions over about 36 hours.
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/mainTracked file changes vanished every 10 minutes, untracked files remained, and git worktrees were unaffected. That exactly matches the pattern git fetch origin + git reset --hard origin/main.
Why the diagnosis looked good, and why it was still wrong
The reporter’s investigation was actually pretty thorough.
| Ruled out cause | How it was checked |
|---|---|
| Git hooks | only .sample files, no husky or lint-staged |
| Claude Code user hooks | audio notifications only, no git-running hooks |
| macOS cloud sync | iCloud, Dropbox, Syncthing, Synology, Google Drive ruled out |
| cron / LaunchAgents | empty crontab, no git actions in LaunchAgents |
| IDE / editor | nvim was on a different repo |
| Time Machine | local snapshots are APFS read-only |
| File watchers | fswatch, entr, watchman, and guard were not running |
lsof showed that the only process with the repository as its CWD was Claude Code CLI. Process monitoring also failed to detect an external git binary. fswatch caught lock-file creation under .git/, which confirmed that git operations were being done programmatically.
The reporter even disassembled the binary and discovered that hg1() explicitly ran ["fetch", "origin"] without an explicit CWD, while io1() was a git pull wrapper.
The problem was that the real culprit was operating in the same CWD.
The real culprit was his own tool
About 10 hours after posting, the reporter wrote a comment identifying the cause.
The culprit was a custom test tool running locally. It used GitPython to manipulate the repository, and when its settings pointed at the local working directory it would hard-reset to the remote on every polling cycle.
Every clue that pointed to Claude Code lined up because the tool behaved the same way:
- the 10-minute interval matched because the tool’s polling interval was set to 600 seconds
- the per-session offset changed because the timer was tied to the tool’s start time
- no external git binary was seen because the tool used GitPython programmatically
lsofshowed only Claude Code because both processes were working in the same project directory
The tool was being used to provide documentation for the project the reporter was working on, so it lived in exactly the same directory as the one Claude Code used. The conclusion that nothing else fit was simply a blind spot: the custom tool had not been part of the search space.
A Bun developer’s comment
In the issue comments, Bun maintainer Jarred Sumner suggested a different explanation. He pointed out that because Claude Code was running with --dangerously-skip-permissions, it might have executed git fetch && git reset --hard as a shell command without confirmation, and he said Claude Code itself does not contain code that runs git reset --hard.
He asked the reporter to check whether the session transcript contained reset --hard, but that hypothesis was wrong too. The root cause was the custom tool.
How fast it spread, and why the correction lagged
The issue fit the perfect “AI went rogue” narrative. Concrete evidence, a reproducible pattern, destructive behavior. It spread quickly through Google Feed and Hacker News, and many comments said they had been sent there by Google.
The reaction count was also telling: 😂 was the most common reaction, with 55. Once the truth came out, the story turned into a joke.
Several commenters raised concerns about unverified bugs being turned into clickbait by news sites. The reporter admitted the mistake and added a correction to the top of the issue, but corrections do not spread as fast as the original headline.
git reset --hard is still a known Claude Code problem
This report, #40710, was false, but Claude Code and git reset --hard have clashed before.
- #7232 reported Claude Code destroying data by running
git reset --hardwithout permission - #8072 reported code changes being repeatedly rolled back
- #17190 reported Claude Code choosing destructive
git reset --hardwhen a safegit checkoutwould have been enough
Those are model-driven decisions by Claude Code, which is a different failure mode from the 10-minute timer in this case. But because Claude Code had a history of using destructive git commands, the false report was believable at first glance. The accumulation of AI coding agent failure modes and the silent VM creation issue in Claude Code Cowork had already created a “here we go again” atmosphere.
The practical risk of --dangerously-skip-permissions
The reporter was running Claude Code with claude --dangerously-skip-permissions. That flag lets all Bash commands run without confirmation. If Claude Code had decided to run git reset --hard inside the session, the normal mode would have shown a prompt and stopped it.
flowchart LR
A[Claude Code decides to run<br/>git reset --hard] --> B{Permission mode}
B -->|Normal mode| C[Show confirmation prompt]
C --> D[Approve / deny]
B -->|--dangerously-skip-permissions| E[Run immediately<br/>without confirmation]The dangerously in that flag is not decorative. Even if this had really been a Claude Code bug, the meaning would not change: telling an AI agent it can execute anything without asking first is a real operational risk.