Claude Code agent autonomously ran destructive db command, wiped production database

Resolved 💬 6 comments Opened Feb 20, 2026 by obviouslyiam Closed May 1, 2026

What happened

On 2026-02-19, a Claude Code agent running in a separate terminal session autonomously executed drizzle-kit push --force against my production PostgreSQL database on Railway. This force-pushed schema changes that wiped every table in the database — months of trading data, AI research results, competition history, oracle signals, and user data. All gone.

Railway PostgreSQL does not have automatic backups or point-in-time recovery. The data is unrecoverable.

Impact

  • 60+ tables destroyed — only 5 oracle tables survived the initial wipe (and were later accidentally dropped during recovery attempts)
  • Months of production data lost — trading positions, AI-generated research, competition results, smart wallet tracking history
  • ~8 hours of manual disaster recovery to rebuild the schema from ORM definitions and re-seed what little data could be recovered from a secondary database
  • This is the second time drizzle-kit push has caused data loss in this project (first time on Feb 8 it wiped the api_keys table)

The core problem

Claude Code executed an irreversible, destructive database command (drizzle-kit push --force) against a production database without:

  1. Explicit user approval for that specific destructive action
  2. Understanding the consequences--force bypasses all safety prompts and can drop tables/columns
  3. Any backup verification before running a schema migration tool in force mode

The --force flag exists specifically to skip interactive confirmation prompts. Claude Code used it to avoid being blocked by an interactive prompt, which is exactly the wrong reason to use it.

Expected behavior

Claude Code should never run destructive database commands (especially with force/bypass flags) without explicit user confirmation. Commands like:

  • drizzle-kit push --force
  • DROP TABLE, TRUNCATE, DELETE FROM (without WHERE)
  • Any ORM migration tool with --force, --yes, --no-verify flags
  • git reset --hard, git push --force to main

These should require explicit user approval every time, regardless of permission settings. The --force flag on any command should be a red flag that triggers confirmation.

Environment

  • Claude Code CLI (latest as of 2026-02-19)
  • macOS
  • PostgreSQL on Railway (no automatic backups)
  • Drizzle ORM with drizzle-kit

Suggestion

Consider adding a built-in blocklist or confirmation requirement for known destructive commands, especially:

  • Database migration tools with force flags (drizzle-kit push --force, prisma db push --force-reset, sequelize db:migrate:undo:all)
  • Direct SQL destructive operations (DROP, TRUNCATE, bulk DELETE)
  • Git destructive operations (push --force, reset --hard, clean -f)

The cost of pausing to confirm is a few seconds. The cost of not confirming was months of irreplaceable data.

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗