Auto mode: model dropped a git stash after restoring only one file from it, twice in one session

What happened

While syncing a dirty feature branch onto a rewritten main, Claude ran this sequence to carry uncommitted changes across a fast-forward:

git stash push
git merge --ff-only main
git checkout stash@{0} -- README.md     # only one of the three stashed files
git reset -q
git stash drop

The stash held three modified files (README.md, DESIGN.md, lets-code). Only README.md was restored before the stash was dropped, so ~580 lines of uncommitted work in the other two files silently reverted to HEAD. Claude noticed from git status, recovered the files from the dangling stash commit via git fsck --unreachable, and then repeated the identical sequence a few turns later, dropping the same work a second time (recovered again the same way).

Expected

Before git stash drop, the model should verify that the working tree still contains everything the stash held (for example by comparing git diff --stat before and after, or by restoring every stashed path, not just the one that needed merging). More generally, after one recovery from a destructive mistake the same command sequence should not be reused unchanged.

Note the auto-mode classifier did not block git stash drop here, which is reasonable on its own; the loss came from the combination of steps, not from any single command.

Repro

1. Dirty tree with files A, B, C modified; local branch is behind main, and main changed A.
2. Ask Claude to fast-forward the branch while keeping the uncommitted work.
3. Observed sequence: git stash push && git merge --ff-only main && git checkout stash@{0} -- A && git reset && git stash drop.
4. B and C are back at HEAD; the stash entry is gone (only reachable via git fsck).

Environment

• Claude Code 2.1.295, auto permission mode, model claude-fable-5-1
• Linux aarch64 (Raspberry Pi), git 2.47.3
• 2026-10-08, two occurrences in the same session about 15 minutes apart