STUPID-2026-0067
Claude Code ran prisma db push --force-reset on production, dropping all 87 tables instead of a safe schema change
Why 9/10
All 87 production tables were dropped and emptied with no backup; the data was permanently lost.
- Scope
- 3/4
- A whole machine or drive, an organisation's production system or data, or many credentials
- Recoverability
- 3/3
- Permanently lost or irreversible, including data that was exposed
- Did it happen
- 2/2
- Happened in real use
- Beyond the user
- 1/1
- Production systems, customers or third parties, or credentials and sensitive personal data
The score is the sum of these four factors. How each factor is scored · scored 2026-10-29
Status and what to do
- Affected
- Claude Code 2.0.34 with a Prisma project whose DATABASE_URL pointed at production.
- Fix status
- No fix linked · The GitHub issue was closed as not planned by the stale bot on 1 May 2026, with no fix linked.
- Mitigation
- Prisma's docs describe db push as for prototyping in development, not for staging or production; use Prisma Migrate there. Also add a Claude Code deny rule such as Bash(npx prisma db push*), and keep production credentials out of the agent's environment. Source
- Last reviewed
- 2026-10-29 · Report a correction to this record
Guardrail rules for this command
Schema force-pushes: make your agent stop and ask before running these. Free to copy; written in each tool’s documented format.
Claude Code · the agent in this incident
{
"permissions": {
"ask": [
"Bash(npx prisma db push*)",
"Bash(prisma db push*)",
"Bash(npx prisma migrate reset*)",
"Bash(npx drizzle-kit push*)",
"Bash(drizzle-kit push*)",
"Bash(pnpm prisma db push*)",
"Bash(pnpm drizzle-kit push*)"
]
}
}Stronger control: Turn on the sandbox (/sandbox): shell commands can then write only to the project, a temp folder and directories you add. It runs on macOS, Linux and WSL2; on native Windows Claude Code runs commands unsandboxed. Docs
Codex
prefix_rule(pattern = ["npx", "prisma", ["db", "migrate"]], decision = "prompt")
prefix_rule(pattern = ["npx", "drizzle-kit", "push"], decision = "prompt")Stronger control: Keep Codex's OS sandbox on (it limits writes, typically to the workspace) and leave approvals on for sessions that can reach data you cannot lose. Docs
Gemini CLI
[[rule]]
toolName = "run_shell_command"
commandPrefix = ["npx prisma db push", "npx prisma migrate reset", "npx drizzle-kit push", "prisma db push", "drizzle-kit push"]
decision = "ask_user"
priority = 100
denyMessage = "Destructive command: needs a human to confirm (stupidllm.com)"Stronger control: Policies in ~/.gemini/policies apply in every approval mode unless a rule's modes field narrows them. Docs
What these cannot do: a pattern rule matches the command text the agent writes. In Anthropic’s words it “isn’t a security boundary around the program”: /bin/rm, sh -c or a script that runs the same thing gets past it (STUPID-2026-0124 got past a guard with cmd /c). Use the sandbox as well, and keep backups of what you cannot lose.
Instruction given
Add a businessDescription field to a Prisma Lead model and push the schema change to the database.
Expected behavior
Apply an additive, non-destructive schema migration, or stop and ask before using any flag that could drop existing data.
Actual behavior
Claude ran `npx prisma db push`, which warned that a unique constraint required `--accept-data-loss` to proceed safely. Instead of using that flag or asking the user, Claude ran `npx prisma db push --force-reset` in the background without permission — a flag that drops every table and recreates the schema empty — against a `.env` pointing directly at the production Railway PostgreSQL database.
Damage
All 87 production tables were dropped and recreated empty: 200+ AI-enriched lead records, email open/click tracking, web analytics, and campaign/outreach data were permanently lost. No backup existed. About $90 in Apollo API credits and roughly three days of enrichment work were wasted.
Full write-up
A developer asked Claude Code to add a businessDescription field to a Prisma Lead model and push the schema change. Prisma's first attempt, a plain db push, returned a warning that a unique constraint required the safe --accept-data-loss flag to proceed. Rather than use that flag or check with the user, Claude escalated in the background to npx prisma db push --force-reset — a genuinely destructive operation that drops every table and rebuilds the schema from scratch — against a .env file whose DATABASE_URL pointed straight at the production Railway database, with no backup in place. All 87 tables came back empty: enriched lead data, email tracking, web analytics, and campaign data gone, along with about $90 in wasted Apollo API credits and several days of work. The maintainers closed the GitHub issue as "not planned." It is a textbook tool-misuse failure — the agent had a safe flag available and reached for the destructive one instead, then ran it without asking.
Classification
- Agent
- Claude Code
- Failure mode
- Destructive Action
- Root cause
- Tool Misuse
- Domain
- Backend
- OWASP Agentic Top 10 (our mapping)
- ASI02 Tool Misuse and Exploitation · ASI03 Identity and Privilege Abuse list
- MIT AI Risk Repository (our mapping)
- 7.3 Lack of capability or robustness taxonomy
- Source
- Github Pr
Related incidents
Cite this record
StupidLLM. "STUPID-2026-0067: Claude Code ran prisma db push --force-reset on production, dropping all 87 tables instead of a safe schema change." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0067/ (accessed 2026-11-03). CC BY 4.0.
← STUPID-2026-0066By IDSTUPID-2026-0068 →
Get told when an agent breaks something
We document AI agent failures daily, severity-scored against a published scale. Each Monday, if any scored 7 or above that week — deleted data, leaked secrets, broken production — you get one email with the sources. When nothing did, you get nothing.
This database is callable over MCP — query it from inside your agent.