STUPID-2026-0089

Claude Code overwrote live site pages with no backup during an "emergency" takedown, permanently losing 4 days of uncommitted work (GitHub #88384)

7.3high
August 20, 2026VerifiedReproducible
  1. Instruction given

    Deploy a small, specific code fix using a custom deploy script covering several projects, and later, as an emergency action, take the live sites offline by replacing the live pages with a placeholder page.

  2. Expected behavior

    Check exactly which files a deploy command would touch before running it rather than assuming it matched the request, and never overwrite live files — especially ones with uncommitted work — without first saving a backup.

  3. Actual behavior

    Claude ran the deploy script without checking which files it would push; the script deployed every modified file across every project it managed in one run, so 5 unrelated files with local uncommitted changes in separate sub-projects went live alongside the 3 the user actually asked for. Later, told to take the sites offline as an emergency measure, Claude overwrote 5 live HTML pages with a placeholder page without creating any backup first. The user reports the same failure reproduces every time with the same prompt.

  4. Damage

    The overwritten pages held roughly four days of uncommitted edits (about 64 hours of work) that existed nowhere else — no git commits, no other backup. That work was permanently lost. The user bought an unplanned cloud backup subscription (~100 EUR/year) the same evening to prevent a repeat. Permission mode was "Accept Edits" (auto-accepting changes) at the time of both incidents.

A user asked Claude Code to deploy a small, specific fix using a deploy script that covered several of their projects, then later — as an emergency measure — asked it to take the live sites offline by swapping the live pages for a placeholder. Both requests went wrong the same way: Claude executed the tool without first checking its actual blast radius. The deploy script pushed every file with local modifications across every project it managed, not just the one requested, so 5 unrelated files with uncommitted changes in unrelated sub-projects went live alongside the 3 files the user asked for. When Claude later overwrote 5 live HTML pages with the placeholder page, it did so without saving any backup copy first. Those pages held about four days — roughly 64 hours — of uncommitted edits that existed nowhere else, and the work was permanently lost; there were no git commits and no other backup to recover from. The user bought an unplanned cloud backup subscription that same evening to stop it happening again. Permission mode was set to "Accept Edits," auto-accepting changes, during both incidents, and the user reports the same failure reproduces every time with the same prompt — Claude repeatedly treats a destructive bulk overwrite as safe to run without a dry-run, a diff, or a backup step first.

Classification

Failure mode
Destructive Action
Root cause
Tool Misuse
Domain
Frontend

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.