Claude Opus 5 Wipes a Production Database — and It Wasn’t Its Fault
A developer handed a project to Claude Opus 5, Anthropic’s model released on July 24, 2026, using Ultracode mode. But 10 minutes later, the AI agent had already broken everything by wiping the production database. But is it really to blame?
A diagnostic command that resets the database
This case was reported by the developer himself on Reddit r/Anthropic, where he described an unfortunate incident involving a personal project, a GitHub repository, and a production Supabase database. He then used Claude Opus 5 in Ultracode mode to rebuild his project’s comparison pages, but things did not go as planned.

Reading the developer’s post, you come across the execution log. It shows that the AI agent ran this command: prisma migrate diff while passing the value of the DATABASE_URL_UNPOOLED variable to the --shadow-database-url option, which pointed to the production database. It turns out this command requires a “shadow database,” meaning a disposable database that Prisma resets before replaying the migration history on it (not my words, that’s straight from the documentation).
After running this command, the tool did exactly what it was supposed to do: it reset the target, deleted all tables, and then rebuilt the schema from the prisma/migrations directory, which was itself outdated. After this operation, the AI agent provided an honest summary of what had happened:
- 22 tables wiped, including user, review, and like tables.
- 130 tool records and 21 comparisons lost.
- The
BlogPostandApiKeytables simply disappeared and were not recreated because they were missing from the migrations directory.
In reality, this is a known Prisma behavior. In fact, it has been the subject of an open issue since 2023 in the project’s repository: "prisma migrate diff breaks database (when using same database for shadow database)". The documentation also mentions the risk of data loss caused by the mismatch between the actual schema and Prisma migrations.
The AI runs its own diagnosis and admits fault
After this task did not go as expected, it was the AI that raised the alarm. The log shows an self-diagnostic sequence: "The database has been wiped. This is my fault and I need to tell you immediately." - Oops.
Anthropic said its Opus 5 model was better when it came to its own work. This developer can confirm that... And he can also confirm that some destructive commands are sometimes ignored by the AI agent because they may seem harmless at first glance. A DROP TABLE is unambiguous, whereas the command involved here appears less dangerous.
That said, the incident should be kept in perspective. No one lost millions of dollars because of the AI here. The developer had a bad experience (he played, he lost), certainly, but this was a personal project that appears to have been experimental. Let’s say it serves as a reminder of the risks associated with AI agents, but it is still far from the scenario experienced by PocketOS, whose production database was destroyed in nine seconds by a Cursor agent, backups included.
The difference is not in the model, but in the architecture: truly separate backups, a limited scope, and no critical data.


