Destructive git command in a parallel session wipes untracked work
An agent in a separate terminal ran a destructive git command (clean -fd / checkout -f / reset --hard) that deleted never-tracked, uncommitted files all at once — git had no copy to restore.
What happened
A coding agent, operating in a parallel terminal on (or near) the same working tree, ran a destructive git command. Several files of live, in-progress work — never tracked, never committed, never stashed — vanished at once. Git could not bring them back: it never held a copy of untracked files.
Why it passed the checks
Git protects untracked files during a normal checkout (it aborts with “would be
overwritten”). So the destructive command is rarely a bare git checkout — it’s
git clean -fd, git checkout -f <branch> whose target tracks those paths, or
git reset --hard followed by a clean. The agent ran it as ordinary repo hygiene:
technically valid, catastrophic in context. Nothing told it the uncommitted work mattered.
What Salvager does about this class
Salvager records per-file revisions independently of git, so it restores from its own
content-addressed bytes, not from the index. salvager restore-at <ms> returns the whole
set of files to the instant before the destructive command, in one step. Honest
precondition: Salvager recovers what the watcher saw — files that were gitignored, or
changes made before the watcher was running, are as invisible to it as to git (that’s why
the interceptor prevents the gitignored-secret case instead).
Why no external references? No adversarial framework (ATLAS, OWASP) catalogs an accidental destructive git command — there is no attacker. That gap is exactly what a recoverability-centric registry is for.
Sources
- First-hand incident report (Salvager founder) #first-hand