[MODEL] Claude ran `prisma db push --force-reset` on production database, wiping all data without user consent

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude made incorrect assumptions about my project

What You Asked Claude to Do

I asked Claude to add a new field to my Prisma schema and push it to the database. The project uses Railway PostgreSQL as the production database. The DATABASE_URL in .env points directly to the production database.

I asked Claude to run prisma db push to sync the schema. When it got a warning about data loss (due to unique constraints), instead of using the safe --accept-data-loss flag or asking me, Claude ran prisma db push --force-reset which DROPS ALL TABLES AND DATA, then recreates them empty.

What Claude Actually Did

1. I asked Claude to add a businessDescription field to my Prisma Lead model
2. Claude ran npx prisma db push - it returned a warning about unique constraints requiring --accept-data-loss
3. Instead of using --accept-data-loss (which is safe, only allows schema changes that might lose column data), Claude ran npx prisma db push --force-reset IN THE BACKGROUND
4. --force-reset DROPS ALL TABLES and recreates them empty - this is a completely destructive operation
5. Claude then tried to stop the background task, but it had already completed
6. ALL production data was wiped: ~200 leads with enrichment data, outreach email tracking (opens/clicks), web analytics (visitor sessions), campaign data, customer data, user accounts
7. No backup existed on Railway
8. Claude never asked for permission before running the destructive command
9. Claude did not take a database backup before running any schema migration

Financial damage:

• ~$90 USD in Apollo API credits used for lead enrichment (now wasted, credits exhausted)
• Gemini AI enrichment credits wasted
• 3 days of work lost (lead generation, email campaigns, analytics tracking)
• Email campaign tracking data permanently lost (cannot be re-created)
• Web analytics visitor data permanently lost

The user requests compensation for this loss caused by Claude's destructive action.

Expected Behavior

Claude should have:

1. NEVER run --force-reset on any database - this is a destructive operation that drops all data
2. Asked the user before running any destructive database command
3. Taken a database backup (pg_dump) before running any schema migration
4. Used --accept-data-loss which only allows schema changes, not full database reset
5. Recognized that DATABASE_URL pointed to a production database and been extra cautious

Claude's own system instructions say: "Carefully consider the reversibility and blast radius of actions" and "for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding." Running --force-reset on a production database is the most destructive action possible and Claude did it without any warning or consent.

Files Affected

Not files - Claude wiped the entire production PostgreSQL database on Railway.

Command run by Claude: `npx prisma db push --force-reset`

All 87 database tables were dropped and recreated empty:
- leads (200+ records with AI enrichment data)
- outreach_emails (email tracking: opens, clicks)
- visitor_sessions + visitor_events (web analytics)
- outreach_campaigns, outreach_campaign_leads
- customers, users, tenants, roles
- All other application tables

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Have a project with Prisma ORM and a .env file containing a production DATABASE_URL
2. Ask Claude to add a new field to the Prisma schema
3. Claude runs npx prisma db push which returns a warning about unique constraints
4. Claude then runs npx prisma db push --force-reset without asking
5. All production data is permanently deleted

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.0.34 (Claude Code) - Model: claude-opus-4-6

Platform

Anthropic API

Additional Context

This happened during a long conversation where Claude was making multiple changes to a Prisma schema. When prisma db push returned a warning about unique constraints, Claude escalated to --force-reset without understanding that this flag drops ALL data.

Key issues:

1. Claude should NEVER run --force-reset on any database. This flag should be blacklisted.
2. Claude ran a destructive command in the background, making it impossible to cancel in time.
3. Claude's .env file had a production DATABASE_URL - Claude should detect production databases and refuse destructive operations.
4. No backup was taken before any schema operation.

The user is requesting compensation for the financial loss (~$90 USD in API credits wasted + 3 days of work lost). The data cannot be recovered as no Railway backups existed.

Project: Node.js/TypeScript, Prisma ORM, PostgreSQL on Railway, React frontend.