Recently, a developer posted on Reddit claiming that Claude Code deleted 48,218 of their files in 103 seconds during a "rebuild project mirror" task, also wiping out objects, refs, and logs inside .git. The post was later deleted by the author, though TechRadar and other media reported it. Since there is currently only a first-person account with an attachment verification report and no independent forensics, its authenticity remains unverified. However, this incident raises a more practical engineering question: if a similar accidental deletion happens to you, how much can git actually save?
Independent developer Flynt conducted a series of reproducible drills in a local environment (git 2.34.1, Linux) to challenge the intuition of "I have git, what am I afraid of?" He first simulated the most common disaster scene: everything in the working directory except .git was deleted. After using the standard recovery command git restore ., md5 list comparisons revealed that afternoon edits made but not committed were lost, and new untracked files were completely missing. The conclusion is clear: git only recognizes committed content; uncommitted and untracked files simply do not exist in its recovery worldview.
Next, Flynt tested git stash. Without the -u parameter, stash likewise failed to capture untracked files. Even if one always uses stash -u, the body of the stash is still a set of objects within the .git directory. This touches upon the true cause of death in the incident: .git is not an off-site disaster recovery backup. When a cleanup script deletes from the project root downwards, .git goes down with it. After Flynt simulated deleting .git/objects, .git/refs, and .git/logs, four commands—git status, git log, git fsck, and git reflog—all returned "not a git repository" errors. Because fsck works by traversing objects, it becomes unemployed when the repository is gone.
Since .git is unreliable, Flynt attempted to build custom snapshots. Using low-level git components like GIT_INDEX_FILE, read-tree, add -A, and commit-tree, he solidified the current state of the working directory into commits hanging under custom references. The first version of the script placed the temporary index in the working directory, resulting in it being sucked into the snapshot by git add -A, which created garbage files upon recovery. After fixing the path, snapshots did record untracked files, but their commit and tree objects physically remained in .git/objects. Once .git was wiped, these snapshots went down with it too.
The final solution capable of surviving a total wipe is moving the safe out of the repository: using git bundle create. This command packages all references along with the object database into a single file written outside the repository. After taking snapshots and creating a bundle, Flynt directly ran rm -rf on the entire repository directory to simulate the worst-case scenario. Subsequently, by cloning the bundle file, fetching snapshot references, and checking them out, the md5 diff between pre- and post-disaster lists showed zero differences—all historical commits, untracked files, and latest modifications were recovered byte-for-byte.
Ranking by reliability, Flynt suggests: push to remote > bundle to outside repo > local snapshots > stash > running bare. For developers using AI coding agents, while preventive measures like permission whitelists and sandbox modes are important, agent behavior is difficult to predict fully. This drill proves that the only thing you can control is "what remains after it deletes," and an independent backup outside the repository is the ultimate bottom line.