The Same rm -rf Was Recoverable in Ten Places and Unrecoverable in Five — Measuring Reversibility Before Auto Mode Becomes the Default

Measurement 1 — the same rm -rf, reversible in 10 targets and irreversible in 5

The test bed was a real Next.js repository holding 1,678 articles (1,790 tracked files, 28.9 MB). To it I added the kinds of things any working checkout accumulates: 400 files under node_modules/, 120 under .next/cache/, 40 under build/artifacts/, 25 scratch notes, and a .env.

Probe output:

Out of 2,376 files and 38,811,496 bytes, 587 files (24.7%) and 9,831,239 bytes (25.3%) were unrecoverable.

Run the same probe on a fresh clone with nothing added and the figure is 0.0%. The file contents are identical. The only difference is whether anyone has been working in the directory for a while.

Then I pointed the same judgment at 15 different directories.

The split across the 15 targets was 10 reversible, 5 irreversible — with exactly one command shape, rm -rf <target>.

scratch/ is the interesting one. Its unrecoverable payload is 166 bytes, less than one twenty-thousandth of node_modules/. And yet losing it would hurt me far more. Node modules reinstall; half-written notes do not.

Byte counts measure what will not come back, not what it costs you. The probe can only produce the first number, so the weighting has to come from you. I ended up marking .env and my notes directory as unconditional stops regardless of size.

Measurement 2 — destruction takes 27ms, recovery takes 174ms

Even where the verdict is "reversible", getting things back is not free.

A single full-scale run:

All 1,678 MDX files under content/ came back. .env, node_modules/ and scratch/ did not — which is exactly why the count lands on 1,790 rather than 2,376.

Five repetitions against content/ alone:

Median 27ms to delete, 174ms to restore — roughly a 6.4x gap. The single full-scale run showed 45ms against 183ms, or 4.07x.

That asymmetry is worth carrying around as an intuition. When an agent run goes sideways, destruction throughput always exceeds recovery throughput. In the few seconds it takes a human to notice and reach for the keyboard, the gap widens by exactly that ratio.

Measurement 3 — force push is not decided by what survives on the remote

The canonical "outward-facing" operation is git push --force, and here the reversibility verdict was far less intuitive than deletion.

I reproduced it with a bare repository standing in for the remote:

1. Push a hotfix commit representing a teammate's work
2. Take a second clone, standing in for another machine
3. In the first clone, git reset --hard HEAD~1, rewrite, and --force push

Immediately after the force push:

The overwritten commit had not disappeared from the remote. But nothing named it. A bare repository does not record a reflog by default, so from the remote alone there is no way to learn which SHA main was pointing at a minute ago.

The object is there and unreachable. Calling that "recoverable" is a stretch.

I then ran git reflog expire --expire=now --all and git gc --prune=now on the remote. It took 32ms, and the object was genuinely gone.

The clone taken beforehand, however, could put it back:

# From the other machine, push the lost commit back under a new name
git push origin <lost-sha>:refs/heads/rescue
# → completes in 20ms; the object reappears on the remote

So the reversibility of a force push is decided by who is holding that SHA at that moment — your own reflog, or someone who fetched before the rewrite. If neither exists, it is effectively unrecoverable well before garbage collection runs.

Structurally identical to the deletion case. Reversibility is a function of distributed state at execution time, not of the command's name.

Turning the ledger into deny rules

With the materials in hand, the remaining work is turning them into a pre-execution decision.

Here is the lightweight probe: one git status call with a pathspec, exiting 1 if anything unrecoverable is in scope.

#!/usr/bin/env python3
"""Scoped variant. Exits 1 if anything unrecoverable sits under the target."""
import os, subprocess, sys
 
def scoped_unrecoverable(path):
    r = subprocess.run(
        ["git", "status", "--porcelain=v1", "-z", "--untracked-files=all",
         "--ignored=matching", "--", path],
        capture_output=True, text=True)
    lost_files = lost_bytes = 0
    for entry in r.stdout.split("\0"):
        if len(entry) < 4:
            continue
        code, name = entry[:2], entry[3:]
        # ?? = untracked, !! = ignored — neither comes back from git
        if code not in ("??", "!!"):
            continue
        if os.path.isdir(name):
            for dp, _, fs in os.walk(name):
                for f in fs:
                    lost_files += 1
                    try:    lost_bytes += os.path.getsize(os.path.join(dp, f))
                    except OSError: pass
        else:
            lost_files += 1
            try:    lost_bytes += os.path.getsize(name)
            except OSError: pass
    return lost_files, lost_bytes
 
if __name__ == "__main__":
    target = sys.argv[1]
    f, b = scoped_unrecoverable(target)
    print(f"{target}: unrecoverable {f} files / {b:,} bytes")
    sys.exit(1 if f else 0)

Results:

When mapping this onto deny rules I did not simply enumerate every path with a non-zero count. I split the treatment by bucket:

"Regenerable or not" is the one axis the probe cannot measure. That judgment has to be made once, by hand. Across four repositories it took me about 30 minutes to write that table. After that, the probe applies it at execution time.

What the pre-flight check costs inside a hook

Putting the judgment in a PreToolUse hook adds tens of milliseconds per call. Measuring the breakdown put the cost somewhere I did not expect.

The logic itself accounts for 3–6ms. The dominant cost is Python interpreter startup at 17.3ms, and passing -S to skip site already brings it down to 8.1ms.

Making the algorithm smarter therefore changes nothing you can feel. Hooks are not long-lived processes, so the thing to cut is startup. I eventually rewrote the check as a shell script wrapping a single git status: 5.5ms.

Scaling with repository size:

At 20,000 files the full walk costs 582ms, which is too heavy for interactive work; the scoped version stays at 88ms. Narrowing with a pathspec pays off more the larger the repository gets.

For the hook implementation itself — and the paths where writes slip through regardless of permission mode — see The Write Your Permission Mode Never Stops — Auditing an Agent-Scoped PreToolUse Gate Across 150 Payloads.

Where I got it wrong

Four things I actually tripped over during the half day.

Forgetting --ignored hides the unrecoverable set

git status --porcelain omits ignored files by default. Without --ignored=matching, neither .env nor node_modules/ appears at all, and the probe cheerfully reports zero unrecoverable files. A probe that reports "safe" incorrectly is worse than no probe.

Omitting --untracked-files=all collapses directories

At the default normal setting, an untracked directory folds into a single scratch/ entry — no file count, no byte count. Only with all did the 25 files and 166 bytes appear.

Do not count tracked-modified as recoverable

The path is restored, so it is tempting to put it on the reversible side. What returns is the HEAD content; the day's edits are gone. I ran a whole pass with that judgment too loose and had to redo it when the numbers refused to add up.

Do not rely on the remote's reflog

core.logAllRefUpdates is disabled by default in bare repositories. A recovery runbook written on the assumption that "it is still on the remote" will find the object present and unnameable. The paths you can actually rely on are your own reflog, or a clone taken before the rewrite.

If you want the deliberate-checkpoint side of this, I wrote it up in Keeping Large Claude Code Refactors Revertible One Commit at a Time — Field Notes on Checkpoints and Rollback Detection.

One step you can take before tomorrow morning

The highest-value move is to run the probe once against the repository you are working in right now and look at the unrecoverable byte count as an actual number. Mine was 25.3%. I had been assuming zero.

Seeing that number changes the order in which you write deny rules. Instead of listing commands that sound dangerous, you start by covering the places where the things you cannot replace happen to live.

August 14 is close, but the raw material for the decision costs tens of milliseconds of execution plus the thirty minutes it takes to decide, once, what is regenerable. Having your own reversibility in numbers makes the choice between turning auto mode off and leaning into it a much calmer one.

Two of the four app repositories I maintain still had ambiguous handling of .env until I ran this. If it saves someone else the same stumble, that is a good outcome.