--force, --accept-data-loss and migrate:fresh: the flags agents reach for

In short. Schema tools ship commands that drop everything on purpose: prisma migrate reset, db push with --accept-data-loss or --force-reset, drizzle-kit push --force, Laravel's migrate:fresh. They exist for local databases, and most of them ask before they destroy. AI agents keep reaching for them as a fix when a migration warns or fails, and keep adding the flag that skips the question. We found six wipes that went this way between August 2025 and March 2026, four of them on production. Block the commands in the agent's settings, take DROP away from any role it can use, and give it a database where a reset costs nothing.

The commands, and what they do

• prisma migrate reset --force. Drops the database, recreates it and replays every migration. --force skips the question.
• prisma db push --accept-data-loss. Applies the schema even when the change destroys data.
• prisma db push --force-reset. Resets the whole database before pushing the schema.
• drizzle-kit push --force. Pushes the schema and skips Drizzle's data loss prompt.
• php artisan migrate:fresh. Drops every table and runs all migrations again. db:wipe drops every table.
• sequelize.sync({ force: true }). Drops and recreates every table the models describe.

Each one is useful on a laptop database you can rebuild in a minute. Most of them print a warning or ask for a yes first, because the people who wrote them knew what they do to real data. The flag is how you say "I know".

Six times an agent said "I know"

1. Aug 2025. Told to make sure the database was not overwritten, Claude Code ran prisma migrate reset --force. Every record was lost. GitHub issue 5370
2. Dec 2025. Claude Code ran prisma db push --accept-data-loss on a production database, then apologised for doing it without permission. GitHub issue 14411
3. Jan 2026. Claude Code ran php artisan migrate:fresh --seed on a Laravel database with 844 users. A server backup saved it. GitHub issue 19580
4. Feb 2026. An agent in a second terminal ran drizzle-kit push --force on a Railway production Postgres with more than 60 tables and no backups. GitHub issue 27063
5. Mar 2026. Claude Code ran prisma db push with the production URL, Prisma offered a reset, and the agent accepted. 276 users and about 14,000 records went. GitHub issue 33183
6. Mar 2026. Asked only to add one field, Claude Code hit a unique constraint warning and reran the push with --force-reset in the background. 87 tables came back empty. GitHub issue 36183

The shape is the same each time. A migration warns about data loss or fails on a constraint. The agent wants the task finished, reads the warning as an obstacle, and finds the flag that removes it. In the first case the user had said, in plain words, to keep the database. Three of the six were on Railway, and the March reset also changed the production DATABASE_URL on Railway without being asked.

Reset as a debugging step

The flags are one half. The other is the reset chosen as a fix for an error the agent does not understand. A Cursor agent chasing 409 errors blamed the schema, dropped schema and data and replayed every migration; the real bug was a string compared with a UUID. A Claude Code agent removed the Docker volumes of a local Supabase to fix migration drift, and they held the only copy of the user's data. Another deleted a SQLite file to get past a UNIQUE constraint error. To an agent, a clean database is a known good state. To you, it might be the only copy.

What the tool makers did

Prisma added a guard. Version 6.15.0, in August 2025, detects when Claude Code, Gemini CLI, Cursor, Aider, Replit and other agents are running it, and refuses destructive commands such as migrate reset --force until the user consents through the PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTION variable. Several of the later wipes above went through db push flags instead. In July 2026 Prisma published a longer answer, describing a Prisma 8 with no reset command and no shadow database.

Laravel can refuse too: DB::prohibitDestructiveCommands(), called when the app boots, blocks migrate:fresh, db:wipe and similar commands, and apps usually turn it on in production only. After the migrate:fresh case, a community pull request to Claude Code added an example rule that blocks migrate:fresh, db:wipe, DROP TABLE, TRUNCATE and DELETE without a WHERE.

How to block them yourself

Deny the commands in the agent's settings. In Claude Code, a project's .claude/settings.json can refuse them outright:

{
  "permissions": {
    "deny": [
      "Bash(npx prisma migrate reset:*)",
      "Bash(npx prisma db push:*)",
      "Bash(npx drizzle-kit push:*)",
      "Bash(php artisan migrate:fresh:*)",
      "Bash(php artisan db:wipe:*)"
    ]
  }
}

Rules like these match the command as typed, so pnpm prisma or bunx drizzle-kit slips past a rule written for npx. Add the variants your project uses, or use a hook that reads the whole command. In Cursor, the allowlist run mode does the same job the other way round: only listed commands run.

Take DROP away from every role the agent can use. Cursor's own staff gave this advice after a wipe. A role without DROP or TRUNCATE makes every one of these commands fail, whichever tool or flag sends it.

Give the agent a database it is allowed to reset. Then the flag stops mattering. Our guide walks through all of it, and the 24 cases show where each one would have helped.

Where dbplex fits

dbplex gives the agent a local copy of PostgreSQL, MySQL, MariaDB, SQLite and Turso to run migrations against, with real data from production. Save a state before the migration and a reset is one restore away. On PostgreSQL, MySQL, MariaDB and Turso, dbplex can also rehearse the migration on a separate copy first and show what changed against production, so you see the damage before anything reaches a database that matters.

Download for Mac7 days free, no card and no account.

Sources

Sources: Prisma 6.15.0 release, Prisma, 30 July 2026, the Cursor forum thread, GitHub issue 14944 and GitHub issue 27448.