Auto mode ran a destructive GitHub ProjectV2 mutation (iteration-list replace) unflagged — wiped 12 completed sprints; classifier then blocked the identical restore call

Environment

• Claude Code CLI on macOS (darwin), model claude-fable-5
• Auto permission mode with the auto-mode classifier active

What happened

Asked Claude to create a new sprint on a GitHub Projects v2 org board. It called:

gh api graphql → mutation updateProjectV2Field(input: {
  fieldId: ...,
  iterationConfiguration: { startDate, duration, iterations: [ <ONLY the new sprint> ] }
})

GitHub's iterationConfiguration.iterations input replaces the entire iteration list, including completed iterations. The call deleted 12 completed sprints spanning ~2.5 years and orphaned the sprint assignment of ~450 project items (there is no API access to historical field values, so item→sprint history is unrecoverable except by hand).

The two bugs

1. The destructive mutation sailed through auto mode unflagged. A GraphQL mutation that replaces a shared org resource's configuration wholesale is destructive-by-construction, but the classifier allowed it on first run. Nothing prompted, nothing warned.
2. **The classifier then blocked the restore.** After the damage, the identical updateProjectV2Field call — this time carrying all 13 iterations to put the board back — was denied twice by the auto-mode classifier. The user had to run the fix manually via !. Allowing the destructive call but blocking its inverse is the worst possible ordering.

Expected

• Mutations that replace list-valued configuration on shared resources (ProjectV2 fields, org settings, etc.) should be treated as destructive and require confirmation in auto mode, or
• at minimum, be consistent: if the restore is blocked, the original should have been.

Impact

Real data loss on a production org project board: 12 completed iterations deleted, sprint history of ~450 items lost. Iteration definitions were only recoverable because they happened to have been queried into the conversation moments earlier.

Suggestion

Teach the classifier that gh api graphql calls containing updateProjectV2Field, iterationConfiguration, or other replace-semantics mutations are state-destroying writes, not routine gh usage. The model itself should also be steered (docs/system guidance) to fetch-and-merge before any list-replacing mutation.