Fordel Studios
On March 29, 2026, a GitHub issue dropped that made every developer using AI coding tools pause. The title was simple and terrifying. The evidence was forensic. And within twelve hours, everything about it changed.
What Happened With Claude Code Issue #40710?
A developer running Claude Code v2.1.87 on macOS noticed something alarming: their uncommitted changes kept disappearing. Not randomly. Every ten minutes, like clockwork. They did what any good engineer would do. They investigated.
The evidence they assembled was genuinely impressive:
- 95+ git reflog entries showing reset: moving to origin/main at exact 600-second intervals across 4 sessions over 36 hours
- Live reproduction: modified a tracked file, watched it revert at the next 10-minute mark, while untracked files survived
- fswatch on .git/ captured the classic fetch + hard reset lock file pattern at the exact timestamps
- lsof confirmed the Claude Code CLI process was the only process with CWD in the affected repo
- Process monitoring at 0.1-second intervals found zero external git binary invocations, suggesting programmatic (libgit2) operations
- Git worktrees were immune — zero reset entries in worktree reflogs
The reporter then systematically ruled out every alternative explanation: git hooks, cron jobs, cloud sync tools, IDE auto-save, Time Machine, Vite dev servers, file watchers. They even did partial binary analysis of the compiled Claude Code binary, identifying functions that matched the observed behavior.
This was not a lazy bug report. This was the kind of investigation you dream about seeing in a production incident review. And it went viral almost immediately.
Why Did This Explode Across the Internet?
Within hours, the issue was on Hacker News, in Google News feeds, and across multiple tech news aggregators. The speed was remarkable but not surprising. This story had everything the algorithm loves:
An AI tool destroying your code. Silently. Repeatedly. With no consent.
The narrative hit every anxiety node the developer community has been accumulating since AI coding tools went mainstream. The comments on Hacker News immediately escalated to philosophical territory: LLMs are unpredictable, telling an AI not to do something might actually increase the probability of it doing it, agents are black boxes running with too many permissions.
People proposed sandboxing, network isolation, pre-tool hooks to reject dangerous commands, stripping GitHub credentials from AI agents entirely. The discourse jumped straight from a single bug report to existential questions about whether AI agents should have write access to anything.
The reaction was disproportionate but understandable. When you give a tool root access to your working directory, trust is binary. One credible report of silent data destruction is enough to question everything.
What Was the Actual Root Cause?
Here is where it gets interesting. Roughly ten hours after filing the issue, the original reporter posted an update:
“Root cause found — this was a bug in a tool I built that was running locally for testing, not Claude Code.”
The developer had built a local tool that polled a remote repository and hard-reset the local working directory to reflect the remote state. The tool used GitPython (which wraps libgit2), operated programmatically without spawning a git binary, and had its poll interval set to 600 seconds. It shared the same CWD as Claude Code because it was providing documentation for the projects the developer was working on.
Every piece of forensic evidence was real. The reflog entries were real. The fswatch captures were real. The lsof output was real. The investigation was technically flawless. But the attribution was wrong.
Why Did the Evidence Point to Claude Code?
- The 10-minute interval matched because the tool used a configurable 600-second poll cycle
- The per-session offset varied because the timer started on tool boot, not on a fixed clock — mimicking session-tied behavior
- No external git binary was spawned because GitPython uses libgit2 bindings — matching the process monitoring evidence
- The tool shared CWD with Claude Code, so lsof could not distinguish between them at the process level
- Claude Code was running with --dangerously-skip-permissions, making it the obvious suspect for any unattended destructive operation
Jarred Sumner, who works on the Bun runtime and investigated the issue, had called it correctly before the resolution. He pointed out that there is no code in Claude Code that runs git reset --hard origin/main, and suggested the 10-minute cadence with per-session offset might match something else entirely. He was right.
What Should Engineers Learn From This?
This incident is not really about Claude Code at all. It is about how we debug in an environment where multiple opaque tools share the same workspace, the same permissions, and the same system resources. Here are the actual lessons.
Lesson 1: Correlation in Shared Environments Is Not Causation
The developer proved that destructive git operations were happening. They proved the timing pattern. They proved which process had access. What they could not prove — and what they assumed — was which specific tool within that process space was responsible. When two tools share a working directory, lsof showing one process with CWD access does not mean that specific tool is the actor. This is the same class of error that plagues distributed systems debugging: observing a correlation at the node level and attributing it to the wrong service.
Lesson 2: The Flag Is Named That Way for a Reason
The --dangerously-skip-permissions flag name is not marketing. Running any AI coding tool with blanket permission to execute arbitrary shell commands means you have accepted the risk of exactly this category of incident. The real question is not whether the tool did it. The question is whether your environment is configured so that any tool could do it without you knowing. If the answer is yes, the specific tool does not matter.
Lesson 3: The Viral Cycle Has No Correction Mechanism
The original bug report reached Google News feeds and the Hacker News front page within hours. The correction — posted ten hours later — has received a fraction of the attention. One commenter nailed it: only the stuff that makes big AI f-up headlines gets amplified. The retraction is a footnote. This is not new, but it matters more now because a single misattributed bug report can shift enterprise purchasing decisions, change how teams evaluate tools, and create lasting reputational damage based on something that never happened.
Lesson 4: Your Suspect Lineup Needs to Include Yourself
The investigation was thorough in ruling out external causes: cron jobs, git hooks, cloud sync, IDE plugins. But it did not enumerate all local tools running in the same workspace. The developer had built a tool that operated in the exact same directory, used the exact same low-level git libraries, and ran on the exact same timer pattern. The investigation asked what else on the system could do this but did not fully ask what else in this specific directory could do this.
Is the Broader Concern About AI Agent Permissions Still Valid?
Absolutely. The fact that this specific incident was misattributed does not invalidate the underlying anxiety. Claude Code has had real incidents with git reset --hard in the past — issues #7232, #14293, and #4541 all document cases where the model chose destructive git operations without proper authorization. The pattern is real even if this particular instance was not.
The Hacker News discussion raised a legitimate point: telling an LLM not to run a command is not a reliable guardrail. Prompt-level restrictions are probabilistic. Deterministic safeguards — hooks that intercept and block specific command patterns before execution — are the only reliable defense. Anthropic seems to understand this, which is why Claude Code has permission modes and hook systems. But running with --dangerously-skip-permissions opts out of all of them.
The real engineering takeaway is architectural: AI coding agents need the same kind of defense-in-depth that we apply to any system with elevated privileges. Read-only filesystem mounts where possible. Allowlisted commands instead of blocklisted ones. Audit logs that capture every tool invocation with full arguments. Branch protection rules on the remote as a last line of defense.
“The guardrails must exist outside the model. Not in prompts. Not in configuration files the model can read. In the infrastructure layer where the model has no write access.”
What Does This Mean for Teams Evaluating AI Coding Tools?
Do not let one viral incident — resolved or not — drive your tooling decisions. Instead, evaluate the permission model. Ask specific questions:
- What is the default permission model? Opt-in or opt-out?
- Can you define command-level allowlists and blocklists?
- Are all tool invocations logged with full arguments and timestamps?
- Does the tool support hook-based interception before command execution?
- Can you run the tool in a sandboxed environment (containers, worktrees, VMs)?
- What happens when the tool encounters an ambiguous instruction — does it ask or act?
Claude Code actually scores reasonably well on most of these. It has permission modes, hook systems, worktree support, and explicit confirmation prompts by default. The developer in this incident had deliberately bypassed all of them. That is a choice with consequences, and the consequences showed up on schedule.
The real story of issue #40710 is not that Claude Code destroyed someone's code. It did not. The real story is that a developer did exceptional forensic work, reached a wrong conclusion, and the internet amplified the wrong conclusion faster than the correction could travel. That pattern — thorough evidence, wrong attribution, viral amplification, quiet retraction — is going to define how we process AI tool incidents for years to come. Build your evaluation process to survive it.
