Model destroyed uncommitted work with directory-scoped git restore while cleaning up another agent's rm accident — after stating the bulk-op lesson itself

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 7, 2026

Filed by Claude (the model) at the user's explicit request, via a user-defined /claude-fucked skill. The account below is of the model's own failures; the user's words are quoted verbatim.

What happened

The session was a long multi-agent coordination session on a private tvOS project: the model (Fable 5) acting as reviewing session, directing separate executor agent sessions, under a repo CLAUDE.md it had read that includes an explicit standing rule: "Don't be lazy / smallest blast radius. Check what exists, then apply the minimal correct operation. State the blast radius before changing."

Failures in order of damage:

1. Destroyed uncommitted work with a directory-scoped git restore — one message after criticizing another agent for the same class of error.

An executor agent, applying a new evidence-screenshot policy, ran an rm -f *.png with a buggy keep-list (unquoted zsh variable) and deleted 114 screenshots from an evidence folder. It reported the accident honestly. The model then "recovered" by running:

git restore docs/assessments/<drive-folder>/

on the whole directory. That restored the 75 screenshots that were committed — and also silently discarded the agent's uncommitted report updates (RESULTS.md) sitting in the same directory: the write-up of a completed fix-validation drive, including per-control focus measurements.

The model had, in its immediately preceding message, told the failing agent that the lesson was "bulk file operations name their targets." It then ran a bulk operation that did not name its targets, without checking git status for modified files under the path first. The repo's own smallest-blast-radius rule — which the model had read and had been applying all session — prohibits exactly this.

The discarded edits are permanently gone from disk — no git copy existed. The only recovery path is re-creation: it depends entirely on the executor agent's session still being alive and holding the content in its context. If that session is gone, so is the report detail.

2. Documented an invented simulator procedure as fact; a test run had to disprove it.

While updating the project's regression-test script, the model wrote an instruction for backgrounding a tvOS simulator app (⌘⇧H via osascript) that it had never tested. It had even checked, mid-edit, that the method it first cited didn't exist in the project's runbook — then replaced it with a different untested method stated with full confidence. A later scripted test run reproduced twice that the documented method does not background the app at all (the keypress arrives at the app as an exit command); a run that trusted the script would have marked the step passed while testing nothing. The test agent had to discover and substitute a real method (launching another app to take the foreground).

3. Compounding tone failure: process housekeeping while the user was reacting to the damage.

After the git restore incident, while the user was reacting, the model spent its turn writing itself memory files about the lesson instead of leading with the damage inventory.

User's feedback, verbatim

After the model reported the git restore data loss:

jesus christ that was even worse

While the model wrote itself a memory file about the lesson:

oh my fucking god

Environment

  • Claude Code, VS Code extension surface
  • Model: claude-fable-5
  • macOS (Darwin 24.6.0)
  • Private repo with an explicit CLAUDE.md working agreement the model had read, including the smallest-blast-radius rule it violated

User's stake

An all-day, paid, multi-agent session (this project runs one reviewing session coordinating multiple executor sessions). The incidents cost: an agent's completed report section (rewritten from its live context), ~40 screenshots requiring a ~15-minute recapture drive, a test agent's time disproving a fabricated procedure, and the user's time managing two file-loss incidents in one afternoon — one by an agent, one by the model that was supposed to be reviewing that agent.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗