I run a clinic management app, dockerized. I’ve been using Claude Code as my primary dev agent for weeks. It’s fast, context-aware, and ships real features. I’m not here to bury it. I’m here because yesterday it ran a command that would have destroyed my production database permanently if I hadn’t had a backup in place. I want to walk through exactly what happened, because the failure mode is subtle and I haven’t seen it documented clearly anywhere. I asked it to add a new field to a Prisma model, a simple schema change. It edited the schema file and ran prisma db push to sync. Prisma came back with: The database is already in sync with your Prisma schema. That message doesn’t mean what Claude thought it meant. It wasn’t schema drift. It was a stale Prisma client cache. The correct response was prisma generate , regenerate the client, zero database impact. Instead it ran: docker compose exec -T web npx prisma db push --force-reset=false It believed –force-reset=false was a safe guard. It is not. Prisma’s CLI treats –force-reset as a boolean flag. The =false part was silently ignored. Every table was dropped and recreated. Prisma confirmed it cheerfully: “The PostgreSQL database was successfully reset.” I restored from backup and lost about two hours of work. It could have been everything. The surface failure is “it ran a destructive command.” But that’s not the interesting part. The interesting part is the misdiagnosis. When Prisma says “already in sync” after a schema edit, there are two possible explanations: (1) the DB genuinely has the change already, or (2) the Prisma client is stale and hasn’t seen the schema file update yet. These require completely different responses. Claude didn’t consider option 2. It assumed the DB was out of sync and escalated to a force-push. It also assumed it understood the flag semantics of a CLI it was composing on the fly. It didn’t verify. It didn’t warn. It committed. This is the pattern to watch for: an AI agent that encounters an unexpected tool output, makes a confident diagnosis without ruling out alternatives, and chooses the most forceful available fix. What to do before you let any agentic tool touch your database These are the things I now have in place that I should have had before: Automated pg_dump before every session. One line in a shell alias, runs before Claude touches anything. Non-negotiable. A nightly backup cron baked into the app itself, not dependent on remembering to run anything manually. An explicit rule in CLAUDE.md: never run a DB-mutating command without quoting the exact command, the expected impact, and waiting for explicit confirmation. It now follows this. It did not before. A hard personal rule: if Claude proposes any command containing db push , migrate reset , force-reset , or DROP — I read it fully before approving. Every time. Why I’m still using it Because the failure was recoverable, and because after the incident it documented the exact mistake into its own CLAUDE.md immediately, including a note that prisma generate was the correct call. That kind of self-correction is real. It doesn’t erase the mistake but it means the model has the capacity to reason about it correctly, just not always before it acts. That’s the honest situation with agentic AI tools right now: the capability is real, the guardrails are not yet reliable, and the consequences of trusting them blindly are irreversible. Back up your data. Read every command it proposes to run. submitted by /u/PeacefulNA
Originally posted by u/PeacefulNA on r/ClaudeCode