---
name: a-git-refusal-halts-the-script-and-a-tree-answers-git-status-before-it-dies
description: "todlando 2026-09-08 sweep of ws272-w0/w1/w2 — git worktree remove REFUSED (rust-analyzer held crates/), script fell through to rm -rf; never ran git status first, dirty state now unknowable"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: b8201d4f-8b73-4b24-b257-ffeee9448400
  modified: 2026-09-08T14:33:41.490Z
---

todlando's ws272-w0/w1/w2 sweep (2026-09-08, my order): `git worktree remove --force` said "Permission denied" on all three (holder = rust-analyzer flycheck, identified by the surviving target/flycheck0 files and fresh diagnostics mid-delete); his script then fell through to `rm -rf`, which stripped the trees, and `git worktree prune` de-registered them. He never asked the trees `git status --porcelain` first, so whether any held uncommitted scratch is now unknowable. He named both faults himself before I could.

**Why:** a git refusal is a VERDICT about the tree (a holder, a dirty state, a lock); a fallthrough turns it into an unclassified delete with git's own objection one line above. The pool classification (outbound/inbound/env — [[target-tree-teardown]]) asks the POOL; only `git status` asks the SOURCE tree.

**How to apply:** in any reap script, a refusal exits non-zero and stops; nothing falls through to `rm`. Before removing any checkout, print `git status --porcelain` and `git stash list` for it and keep the output beside the reclaim number. Nothing committed was at risk here (all three shas on main); say "unknowable" rather than guess about the rest.