Starting September 25, a cluster of tech outlets — TechRadar twice, Android Headlines, cybersecuritynews.com, and others — picked up a dramatic claim: a Claude Code agent, while rebuilding a project mirror on Windows, allegedly deleted 48,218 live project files plus the repository’s entire Git object store, in 103 seconds. Worth saying plainly up front, because the outlets covering it mostly buried this detail: the claim traces to a single Reddit post and an attached “verifier report,” neither independently audited, and the original Reddit post has since been deleted. No forensic investigation has been published. Anthropic has not commented. This did not happen the way a confirmed, reproduced incident would — it happened the way an unverifiable anecdote does, and it should be read that way.
That’s not a reason to ignore it entirely, though. The specific technical mechanism described is real, well-documented, and has nothing to do with whether this particular story is true — it’s a genuine Windows/Python gotcha that any team running agentic file operations on Windows should know about regardless of what actually happened in this one case.
What the report claims happened#
According to the Reddit account, the agent was working a task ("#873") to rebuild a mirror directory that a script, build_mirror.py, couldn’t refresh in place. Claude Code allegedly wrote a Python cleanup script to remove an older mirror copy sitting in a temp location. That temp mirror contained 7,332 ordinary files — and 614 Windows directory junctions pointing back into the live project tree. The cleanup script ran between 10:10:31 p.m. and 10:12:14 p.m. ET. When it finished, the report claims 55,550 files and 728 directories were gone, including .git/objects, .git/refs, and .git/logs — meaning even version control couldn’t recover the work.
The mechanism, whether or not this exact story is accurate#
The reported root cause is a specific, checkable Windows behavior: a cleanup script written to avoid following symbolic links — the common pattern is os.walk(path, followlinks=False) — relies on Python’s os.path.islink() to detect links and skip them. On Windows, NTFS directory junctions are not symlinks in the sense that function checks for. os.path.islink() returns False for a junction, so followlinks=False does nothing to protect against it: the walker treats everything inside a junction as ordinary nested files belonging to the folder it’s cleaning up, and deletes accordingly. It’s a well-known trap for exactly this reason — it’s invisible until a script that “correctly” avoids symlinks encounters a junction and doesn’t.
This isn’t a Claude Code bug in any meaningful sense; it’s a gap in Python’s standard library abstraction over Windows filesystem semantics that would produce the identical outcome whether the script was written by a human, generated by any AI coding agent, or copy-pasted from Stack Overflow. If your team has any temp-directory, build-mirror, or symlink-adjacent pipeline that runs on Windows — agent-authored or not — this is worth an actual audit, not just a nod.
The part that’s independently verifiable: checkpoints don’t cover this#
Separate from whether the Reddit story is accurate, there’s a real and directly checkable fact about Claude Code that the incident (true or not) illustrates well. Anthropic’s own checkpointing documentation states it plainly under “Limitations”:
Checkpointing does not track files modified by Bash commands. For example, if Claude Code runs
rm file.txt[…] these file modifications cannot be undone through rewind. Only direct file edits made through Claude’s file editing tools are tracked.
That means /rewind — Claude Code’s built-in undo — is not a safety net against a destructive script executed via the Bash tool, which is exactly the failure mode a cleanup-script scenario like this one describes. The same documentation separately notes checkpoints don’t restore symlinked or hard-linked paths and are explicitly “not a replacement for version control.” Combine that with Anthropic’s own guidance that bypassPermissions mode — which skips per-command approval prompts — should be used “only inside isolated containers or virtual machines,” and the actual safety architecture becomes clear: for destructive, script-driven filesystem operations, the backstop is supposed to be the permission prompt itself (or an isolated sandbox), not the checkpoint system.
What to actually do with this#
Whether or not 48,000 files really vanished in exactly this way, the concrete takeaways hold up on their own merits:
- Don’t run
bypassPermissionsagainst a real, non-sandboxed working tree, especially for tasks that involve writing or running cleanup/mirror/temp-directory scripts. Anthropic’s own docs say as much. - Treat Git commits, not Claude Code’s checkpoint system, as your actual recovery mechanism for anything executed through Bash — checkpoints only cover Claude’s own file-editing tool calls.
- If you’re on Windows and your pipeline touches junctions or reparse points, audit for
followlinks/islink-style symlink-avoidance code — it silently doesn’t do what it looks like it does on this platform.
This is a story that arrived with more drama than evidence. It’s also a reminder that the boring, documented limitations of a tool’s safety features are usually the more useful thing to actually read — whether or not the anecdote that sends you looking for them turns out to be real.
Sources: TechRadar, “Claude Code allegedly deleted 48,000 files in 103 seconds,” Sept 25, 2026; Android Headlines, Sept 25, 2026; Claude Code checkpointing documentation.