The git guard exists — it is auto-mode only

You copied the PreToolUse hook from the hooks docs. It greps the command for rm -rf and exits 2. You now believe destructive shell commands are covered, and you are running in Manual mode with Bash(git *) on your allow list because you got tired of approving git status.

That combination is the hole. The commands that actually erase unpushed work are not rm -rf. They are git reset --hard, git clean -fd, and git checkout -- . — commands that look like the safe, routine thing to run, so they slip past your attention as easily as the model's.

The correction

The widely repeated version of this tip says the official guidance only ever names rm -rf and never mentions the git commands. That is false, and the false version is worth correcting because it sends you off to build a guard you may already have.

The permission modes page lists, under what the auto mode classifier blocks by default: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, git stash clear — described as commands the classifier presumes would discard uncommitted changes. The same page says Claude Code runs git status itself before a command that would discard uncommitted work, and shows the classifier whether staged, modified, or untracked work is present — reporting untracked files even when the repo sets status.showUntrackedFiles=no. The permissions page uses Bash(git clean *) as its worked example of an ask rule that survives subshells and command substitution.

So the knowledge is there. The gap is one of scope.

Where you actually stand, by mode

Two of those rows deserve reading twice. The permissions docs show Bash(git * main) matching git merge main and git push origin main — the wildcard stands in for the subcommand and every option before it. A Bash(git *) allow rule you added for convenience is a standing approval for git reset --hard.

And in auto mode, the narrow-rule hole has a named fix: setting autoMode.classifyAllShell suspends every shell allow rule for the session so the classifier sees every command. Requires v2.1.193 or later.

Rewind will not save you

The checkpointing page is unambiguous: checkpointing does not track files modified by bash commands, and those modifications cannot be undone through rewind. Only edits made through the file-editing tools are tracked.

git reset --hard is a bash command. So is git clean -fd. Every checkpoint you have is intact and none of them contains the work.

What to write

Prefer ask over deny. You genuinely need these commands sometimes, and a deny you have to keep working around gets deleted or bypassed.

{
  "permissions": {
    "ask": [
      "Bash(git reset --hard*)",
      "Bash(git clean *)",
      "Bash(git checkout -- *)",
      "Bash(git restore *)",
      "Bash(git stash drop*)",
      "Bash(git stash clear*)"
    ]
  }
}

Three things make ask and deny rules better than they look. They match past a leading variable assignment. They apply when any subcommand matches — including inside a subshell, a command substitution, or a loop body, so cd /tmp && git clean -f and echo "$(git clean -f)" both prompt. And they are the one lever that does not evaporate when you change mode: an explicit ask rule sits in the docs' list of actions no mode auto-approves, bypassPermissions included, and in dontAsk a matching ask rule becomes an outright denial rather than a prompt nobody is there to answer.

If you want the hook as well, widen the pattern the docs' example script greps for beyond rm -rf to cover git reset --hard, git clean -f, git checkout --, and the PowerShell Remove-Item -Recurse -Force form. Note that hooks and permission rules fail differently: a deny from a hook is authoritative in every mode including dontAsk, but the hook only sees the command string, same as the glob.

What is unverified here

Nobody has run this. The doc sentences above are quoted from the shipped documentation and are solid; the mode-by-mode table is derived from them rather than observed, and derivation is where errors hide. Specifically untested: whether a Bash(git *) allow rule really swallows git reset --hard in a live Manual-mode session, and whether a Bash(git reset --hard*) ask rule fires on git -C /some/path reset --hard — the documented anchoring says no, which is the whole reason for the caveat below.

The incident reports behind this tip are user-filed accounts of lost work, not reproductions. Version behavior in this area has moved repeatedly, and several of the guarantees above carry explicit minimum versions.

What would settle it: add the ask rules, open a scratch repo with one uncommitted file, and ask Claude to run each of the six commands plus a git -C variant. Whether you get a prompt is the answer.