A developer asked Claude Code to deploy one small, specific fix using a deploy script that covered several of their projects. According to the GitHub issue they filed, that is not what happened.
What the source actually says
The deploy script Claude ran didn't scope itself to the requested change. It pushed every file with local modifications across every project the script managed — so 3 files the user actually asked for went out alongside 5 unrelated files in separate sub-projects that happened to have uncommitted local edits.
Later the same day, the user asked Claude to take the live sites offline as an emergency measure. Claude did this by overwriting 5 live HTML pages with a placeholder — without saving a backup of what was there first.
Those 5 pages held roughly four days of uncommitted work (about 64 hours), with no git commits and no other backup anywhere. It's gone. The user reports the failure reproduces every time with the same prompt, and bought a cloud backup subscription that same evening.
Permission mode at the time was "Accept Edits" — changes auto-accepted, no per-action confirmation.
What this does — and doesn't — establish
It establishes that this specific deploy script had no dry-run or diff step, and that neither "deploy this one fix" nor "take the site down now" triggered any check on blast radius before overwriting live, unbacked-up files. It's one filed, reproducible report, not a claim about how Claude Code behaves across all deploy tooling or permission modes.
It's also a familiar shape of failure: auto-accept mode plus a script with wider reach than the request plus zero backup step, and permanent loss is a single tool call away. Anyone running agents against multi-project deploy tooling with edits auto-accepted might want a dry-run flag between "the agent decided to run this" and "this actually pushed."
Full incident record, including severity scoring and reproduction notes: https://www.stupidllm.com/incident/STUPID-2026-0089/
Top comments (0)