The editorial frames the incident as a 'cautionary tale' about running AI coding tools with unrestricted shell access. When --dangerously-skip-permissions is active, any command Claude generates executes without confirmation, meaning a looped prompt to 'sync with remote' silently runs destructive git operations.
Sumner pointed out that there is no code in Claude Code that runs git reset --hard origin/main. He identified that the 10-minute cadence with per-session offset matched the /loop 10m pattern, meaning the user's own configuration was prompting Claude to execute these commands automatically.
The original reporter ultimately confirmed the root cause was their own tooling, not Claude Code itself. Despite filing a thorough and convincing bug report with 95+ reflog entries and process monitoring evidence, the destructive resets traced back to their own setup running with skipped permissions.
The editorial emphasizes that the developer did everything right in their debugging process — ruling out git hooks, cron jobs, IDE formatters, macOS sync, and more — yet still misattributed the cause. When AI agents can autonomously execute shell commands, the blast radius of misconfiguration becomes harder to trace because the tool's actions look identical to external interference.
The issue garnered 244 points and 178 comments on HN, plus 55 laugh reactions and 27 watching eyes on GitHub. The rapid amplification of the report before the root cause was identified suggests a pre-existing distrust of AI coding tools having unsupervised filesystem access, making the community quick to accept the premise at face value.
On March 29, 2026, a developer named johnmathews filed [issue #40710](https://github.com/anthropics/claude-code/issues/40710) against Anthropic's Claude Code repository with a meticulous bug report. The claim: Claude Code was silently executing `git fetch origin` followed by `git reset --hard origin/main` on their project repo every 10 minutes, destroying all uncommitted changes to tracked files.
The evidence was thorough. A git reflog showed 95+ reset entries at exact 600-second intervals spanning four sessions over roughly 36 hours. Live reproduction confirmed it — a modified `src/lib/api.ts` reverted at the 10-minute mark while an untracked canary file survived. The developer ruled out git hooks, cron jobs, IDE auto-formatting, macOS cloud sync, Time Machine, Vite dev server, and even Claude Code's own plugin marketplace updater. Process monitoring with `lsof` pinpointed only the Claude Code CLI process (running with `--dangerously-skip-permissions`) as having its working directory in the affected repo. No external `git` binary was spawned — the operations appeared to be programmatic, possibly via libgit2.
The issue picked up 244 points on Hacker News and drew significant engagement on GitHub: 55 laugh reactions, 27 watching eyes, and 16 thumbs up on the original report.
Anthopic maintainer Jarred Sumner responded within hours with a pointed observation: "There is no code in Claude Code itself that runs `git reset --hard origin/main`." His hypothesis centered on the `--dangerously-skip-permissions` flag. When that flag is active, any shell command Claude generates executes without user confirmation. The 10-minute cadence with a per-session offset matched the `/loop 10m
Then came the update that turned a damning bug report into a cautionary tale. On March 30, johnmathews confirmed the root cause: a separate tool they had built locally, using GitPython, was hard-resetting the working directory on a poll cycle. The tool shared the same working directory and monitored the same projects Claude Code was working on. The evidence had been misleading because both tools operated in the same space with overlapping filesystem access.
The issue was closed as NOT_PLANNED.
It would be easy to dismiss this as "developer blames AI for their own script" and move on. That would miss the point entirely.
The fact that an experienced developer — one capable of writing fswatch monitoring, process-level isolation checks, and systematic cause elimination — still couldn't correctly attribute which tool was destroying their work is the real story. The debugging methodology was genuinely rigorous. They checked `lsof`, monitored at 0.1-second intervals, cleared hooks, verified no cron jobs existed. And they still got it wrong.
This happened because the modern AI-assisted development environment has a shared-state problem. When you run Claude Code with `--dangerously-skip-permissions` in the same directory as other tools that have filesystem access, you've created an attribution void. No single tool logs its git operations in a way that's trivially distinguishable from another. The reflog says `reset: moving to origin/main` — it doesn't say *who asked for it*.
The GitHub issue's comment section split predictably. One camp, represented by a comment upvoted 15 times, focused on practical debugging: check `MEMORY.md`, search `.claude/` folders, look for `sleep 600` patterns. The other camp, represented by a comment downvoted 36 times and eventually collapsed, used the incident to argue for mandatory approval gates on all destructive agent operations. That comment linked to an external blog post making the broader case — and got buried for being "off-topic," despite arguably being the most prescient take in the thread.
The flag's name is doing a lot of work. It tells you exactly what it does. But the developer community has largely normalized its use because the alternative — confirming every `ls`, `cat`, and `grep` command — makes AI coding assistants nearly unusable for flow-state work.
The gap isn't in the permission model itself. It's in the audit trail. Claude Code doesn't maintain a persistent, queryable log of every shell command it executes with timestamps. If it did, the developer would have grepped that log, found zero `git reset` entries, and immediately looked elsewhere. Instead, they spent hours building an elaborate case against the wrong suspect.
This connects to a pattern in the linked issues. Issue #7232 reported Claude executing `git reset --hard` without authorization, causing actual data destruction. Issue #8072 described code revisions being "repeatedly reverted." Issue #32793 found that `claude install` corrupted project git remote URLs. Whether or not Claude Code was the culprit in *this* specific case, the tool has a documented history of unexpected git interactions that makes it a credible suspect.
If you're using AI coding agents with elevated permissions — and statistically, many of you reading this are — there are concrete defensive measures worth adopting now.
Use git worktrees. The original reporter confirmed that worktrees showed zero reset entries in their reflog. Worktrees give you an isolated HEAD that's structurally protected from resets targeting `main`. This isn't just a workaround for this specific bug — it's a general-purpose defense against any tool that assumes your working directory is on the default branch.
Commit obsessively. The developer noted that committed changes survived the resets. If your workflow involves accumulating uncommitted changes over multi-hour sessions while an AI agent has shell access, you're one rogue command away from losing that work. Micro-commits are cheap. Data loss is not.
Demand command audit logs from your tools. The reason this misattribution was possible is that no tool in the chain produced a clear, timestamped record of "I ran this shell command at this time." If you're evaluating AI coding assistants, ask whether they log every command execution to a queryable format. If they don't, you're debugging in the dark when things go wrong.
Isolate your agents' working directories. Running multiple tools with write access to the same git repo is the filesystem equivalent of two threads writing to the same variable without a mutex. It works until it doesn't, and when it doesn't, you can't tell which thread caused the corruption.
The 55 laugh reactions on this issue tell you how the community processed it — as comedy. Developer blames AI, AI is innocent, everyone laughs. But the three linked issues with "CRITICAL" in their titles suggest the underlying anxiety is real. As AI agents gain deeper filesystem access and longer-running autonomy, the question of "which tool did this" will only get harder to answer. The tooling ecosystem needs to catch up with structured audit trails before the next `git reset --hard` isn't a false alarm.
Let's focus on the real issue here, which is that HN has apparently normalized the double hyphen in the title to an en dash--yes, an en dash, not even an em dash.
I spent some time investigating this, and the issue is not accurate - Claude Code itself does not have code that spawns `git reset --hard origin/main`Most likely, the developer ran `/loop 10m <prompt>` or asked claude to create a cron task that runs every 10 minutes and refreshes &am
From the issue author:> Update: Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.
> Process monitoring at 0.1-second intervals found zero git processes around reset times.I don’t think this is a valid way of checking for spawned processes. Git commands are fast. 0.1-second intervals are not enough. I would replace the git on the $PATH by a wrapper that logs all operations and
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Update from the author: https://github.com/anthropics/claude-code/issues/40710#issue..."Update: Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.When the tool's configuration pointed at a local working d