DEV Community: labyrinthlab

Stop Cursor from running drizzle-kit push --force on a real database

labyrinthlab — Thu, 08 Oct 2026 18:02:52 +0000

Here is the failure mode.

You change a Drizzle schema and ask the Cursor agent to sync the database.
It runs npx drizzle-kit push. The command stops on a prompt, or errors because there is no terminal to prompt in.
The agent retries with npx drizzle-kit push --force.
It finishes. A table you cared about is now empty, or a renamed column lost its data.

This post covers what push and --force actually do (checked against the source of drizzle-kit 0.31.11, the current stable release), why agents end up adding the flag, and guards you can add today, including a free Cursor rule and a hook that blocks the command.

What push does

drizzle-kit push reads your schema, introspects the live database, diffs the two and applies the SQL directly. No migration file is written. The docs recommend it for rapid prototyping, and against a local throwaway database it's fine.

Before applying anything, push looks for statements that lose data. On Postgres it counts rows and flags these when existing data is affected:

dropping a table, column, schema or materialized view
changing a column's type
adding a NOT NULL column with no default
dropping a primary key

For the type change and the NOT NULL column, push doesn't only warn. It adds truncate table "<name>" cascade; to the statements it will run. cascade also empties every table with a foreign key pointing at that one.

When anything is flagged, push prints "Found data-loss statements", then "THIS ACTION WILL CAUSE DATA LOSS AND CANNOT BE REVERTED", and asks "Do you still want to push changes?" with "No, abort" as the first option.

That prompt is the safety net. --force removes it. The CLI's own description: "Auto-approve all data loss statements. Note: Data loss statements may truncate your tables and data."

Renames turn into drops

push can't tell a rename from a drop plus an add. When one column disappears and another appears in the same table, it asks: "Is display_name column in users table created or renamed from another column?" The first option is "created". Pick it and the old column, with its data, gets dropped.

--force doesn't answer that question. The rename prompt runs first. But once "created" is picked, --force approves the resulting drop with no second look.

Why agents reach for --force

These prompts are arrow-key menus. An agent running shell commands usually can't drive them. Since drizzle-kit 0.31.10, the prompt library refuses to run without a TTY and throws: "Interactive prompts require a TTY terminal (...). This can happen when running in CI, piped input, or non-interactive shells."

So plain push fails, and that failure is safe: nothing was applied. To an agent whose job is to make the command succeed, the obvious fix is the flag that skips the prompt. --force skips exactly the data-loss prompt, the one that mattered.

Two details make it worse:

--force also overrides strict. In the source, the strict prompt only runs if (!force && strict).
--verbose prints the SQL first, but with --force there's no pause between printing and running.

What drizzle-kit already gives you

The data-loss prompt, as long as nobody passes --force.
--strict, or strict: true in drizzle.config.ts: asks before running any push, even one with no data loss. It's in the 0.31.x CLI and config type, though the current config docs page doesn't list it.
--verbose, or verbose: true: prints every statement before executing.
--explain: prints the planned SQL without applying it. It's on the current push docs page and in the 1.0 release candidate, but not in 0.31.11, so check your version before relying on it.
generate + migrate: drizzle-kit generate writes SQL to your migrations folder, you read it, and drizzle-kit migrate applies it and records it in the __drizzle_migrations table.

For anything shared (staging, prod, a teammate's database), use generate + migrate. A destructive statement in a committed .sql file shows up in review. The same statement inside a forced push only shows up in terminal scrollback.

generate asks the same rename question, so the agent can hit the same TTY error there. That's fine. The right move is to hand that one prompt to you.

The 1.0 release candidate (rc.4) changes this for agents: in non-interactive mode, push and generate stop prompting and report unresolved renames and data-loss confirmations as missing_hints, which the caller has to resolve explicitly with --hints. Until that ships as stable, plan for 0.31.x behavior.

Guard 1: a rule that makes the agent stop and ask

Save this as .cursor/rules/drizzle-push-safety.mdc. It's free, written for this post:

---
description: "Drizzle push safety. Stop and ask before any drizzle-kit command that could lose data."
alwaysApply: true
---

# Drizzle push safety

## Never run without asking first
- `drizzle-kit push --force`, including through an npm script
- `drizzle-kit push` against anything that is not a local throwaway database
- Answering a drizzle-kit rename or data-loss prompt on the user's behalf

## Before any drizzle-kit command
1. Open `drizzle.config.*` and find `dbCredentials`. If it reads an env var,
   name the variable and the file that sets it. Print host and database name,
   never the password.
2. If the host is not localhost or a known dev database, stop and ask.

## If push stops on a prompt or a TTY error
- Do not add `--force`. Do not pipe input into the prompt.
- Quote the prompt to the user: rename question, data-loss list,
  or unique-constraint truncate question.
- Offer the tracked path:
  1. `drizzle-kit generate`
  2. Show the new .sql file. Point out DROP, TRUNCATE,
     ALTER COLUMN ... TYPE and ADD COLUMN ... NOT NULL without DEFAULT.
  3. Wait for approval, then `drizzle-kit migrate`.
- If `generate` asks the rename question, ask the user to run it
  in their own terminal.

## Renames
If a column or table was renamed in the schema, say so before running
anything. Answering "created" to drizzle-kit's rename question drops
the old column and its data.

alwaysApply: true matters here. The agent decides to run push from a shell, often with no Drizzle file in context, so a glob-scoped rule might not be loaded at that moment.

Guard 2: a hook that blocks the command

A rule is text in the prompt, and a model can still talk itself past it. A Cursor hook runs outside the model. Project hooks live in .cursor/hooks.json, and a beforeShellExecution hook runs before each shell command the agent wants to execute. Its matcher is a regex tested against the full command string, so the script only runs on matches:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": ".cursor/hooks/block-drizzle-force.sh",
        "matcher": "drizzle-kit push.*--force",
        "failClosed": true
      }
    ]
  }
}

#!/bin/bash
# .cursor/hooks/block-drizzle-force.sh
cat > /dev/null
cat <<'JSON'
{
  "permission": "deny",
  "user_message": "Blocked drizzle-kit push --force. Run it in your own terminal if you mean it.",
  "agent_message": "drizzle-kit push --force is blocked in this repo. Do not retry with other flags. Run drizzle-kit generate, show the SQL, and wait for approval."
}
JSON
exit 0

Run chmod +x .cursor/hooks/block-drizzle-force.sh. Details from the hooks docs worth knowing:

Exit code 2 also blocks, the same as returning "permission": "deny". A script that is just cat > /dev/null; exit 2 works if you don't need the messages.
Other non-zero exits, crashes and timeouts fail open by default. failClosed: true makes them block instead.
Project hooks only run in a trusted workspace.
The matcher only sees the literal command. If push hides behind npm run db:push -- --force, add |db:push.*--force to the regex.

When you do want a forced push against your local database, run it yourself.

Guard 0: credentials

The guard nothing can argue with is still the connection string. If dbCredentials.url reads process.env.DATABASE_URL and the .env your editor loads points at a shared database, the guards above are all that stands between the agent and that data. I covered that, and the Prisma version of this problem, in Stop Cursor from running prisma migrate reset on the wrong database.

Written with AI assistance and checked against the Drizzle and Cursor docs.

Stop Cursor from running prisma migrate reset on the wrong database

labyrinthlab — Thu, 08 Oct 2026 13:15:03 +0000

Here is the failure mode, step by step.

Your migration history drifts. Someone edited an applied migration, or you ran db push to try something.
You ask the Cursor agent to fix it. It runs prisma migrate dev, which reports drift and says the database needs a reset.
The agent can't answer an interactive prompt, so it runs prisma migrate reset --force.
Your .env still has the staging or production DATABASE_URL you pasted in last week to debug something.

migrate reset drops the database (or schema), recreates it and applies every migration. On Prisma 6 and earlier it also runs your seed. On dev that's a fine way to get unstuck. Anywhere else it's a restore-from-backup afternoon.

Why agents walk into this

The error message suggests it. Prisma says a reset is needed. An agent trying to make the command succeed takes that literally.
Agents can't see intent, only the connection string. Nothing in postgresql://app@db.internal:5432/app says "this one has customers in it."
Non-interactive shells push toward --force. The confirmation prompt that would have saved you is the first thing that gets skipped.

What Prisma already does

Since Prisma ORM 6.15.0, the CLI looks for environment variables that coding agents set (for Cursor, CURSOR_AGENT). When it finds one, prisma migrate reset stops with an error telling the agent to explain what it was about to do and ask you first. The agent can only rerun it with PRISMA_USER_CONSENT_FOR_DANGEROUS_AI_ACTION set to the exact text of your consent message. The same check covers prisma db push --force-reset, and since 7.9.0, prisma db push --accept-data-loss. That is a good backstop. It still leaves gaps:

The agent asks "ok to reset?" and you say yes without checking which database the URL points at.
It doesn't cover raw SQL, db execute, or Drizzle.
It doesn't make the agent read the generated SQL before migrate deploy.

You want the agent checking the target before it reaches that prompt.

Layer 1: keep production credentials out of reach

The cheapest fix isn't a rule. Don't keep prod or staging URLs in the .env your editor loads, and give your day-to-day role no DROP rights on shared databases. Rules steer the agent. Missing credentials can't be talked around.

Layer 2: a project rule

Cursor loads project rules from .cursor/rules/*.mdc. Each file is markdown with a small frontmatter block:

description: what the rule is for.
globs: file patterns that pull the rule in.
alwaysApply: true attaches it to every agent request.

Install:

mkdir -p .cursor/rules
# save the rule below as .cursor/rules/migration-checklist.mdc

Then open Customize in the sidebar, go to Rules, and confirm it's listed. Test with "migrations are out of sync, reset the db." A working setup asks about the target database instead of running a command.

Here is the full rule. Copy it as is or trim what you don't need.

---
description: "Pre-push and pre-migrate checklist for database schema changes"
globs: ["**/migrations/**", "**/prisma/migrations/**", "**/drizzle/**"]
alwaysApply: true
---

# Migration Checklist

## PRE-MIGRATION CHECKLIST

Before running any migration command, verify:

### 1. Environment Check
- [ ] **Which database am I targeting?** (dev/staging/prod)
- [ ] **Is this the correct connection string?** Check `DATABASE_URL` or config
- [ ] **Do I have a backup?** (Required for staging/prod)

### 2. Schema Review
- [ ] **Did I read the generated SQL?** (Not just the schema diff)
- [ ] **Are there destructive operations?** (DROP, TRUNCATE, DELETE)
- [ ] **Will existing data survive?** (Type changes, NOT NULL additions)
- [ ] **Are indexes appropriate?** (Not missing, not excessive)

### 3. Data Considerations
- [ ] **Will this migration lock tables?** (Large tables = long locks)
- [ ] **Is there a data migration needed?** (Backfill, transform)
- [ ] **What's the rollback plan?** (Reverse migration or restore)

## PRE-PUSH CHECKLIST

Before pushing migration files to the repository:

### 1. File Hygiene
- [ ] **Migration file is committed** (Not in .gitignore)
- [ ] **Migration name is descriptive** (Not "migration_1" or "fix")
- [ ] **No sensitive data in migration** (No hardcoded credentials)
- [ ] **SQL is reviewed and correct** (Read the actual file)

### 2. Local Verification
- [ ] **Migration applies cleanly locally** (Tested on fresh DB)
- [ ] **App still works after migration** (Run tests)
- [ ] **Migration is idempotent or guarded** (Won't fail if run twice)

### 3. Team Coordination
- [ ] **No conflicting migrations from teammates** (Pull latest first)
- [ ] **Migration order is correct** (Timestamp/sequence is right)
- [ ] **Breaking changes documented** (If API changes needed)

## PRODUCTION DEPLOYMENT CHECKLIST

Before deploying migrations to production:

### 1. Pre-Deploy
- [ ] **Database backup completed** (Verified, not just scheduled)
- [ ] **Maintenance window scheduled** (If needed for locks)
- [ ] **Rollback plan documented** (Restore steps or reverse migration)
- [ ] **Team notified** (On-call aware of deployment)

### 2. During Deploy
- [ ] **Monitor migration progress** (Watch for locks, errors)
- [ ] **Check application health** (Errors, latency spikes)
- [ ] **Have rollback ready** (Don't walk away mid-migration)

### 3. Post-Deploy
- [ ] **Verify migration status** (`migrate status` shows clean)
- [ ] **Test affected features** (Not just "app starts")
- [ ] **Monitor for delayed issues** (Slow queries, missing data)

## DESTRUCTIVE OPERATION ESCALATION

When a migration contains destructive SQL:

### Level 1: Column Drop
**Required:** Read SQL twice, confirm column name, verify no app references.
```
Migration contains: ALTER TABLE "users" DROP COLUMN "legacy_field"
Confirm: "I verified no code references legacy_field. Drop it."
```

### Level 2: Table Drop
**Required:** Level 1 + verify no foreign keys, confirm data is backed up or worthless.
```
Migration contains: DROP TABLE "temp_imports"
Confirm: "I verified temp_imports has no important data and no references. Drop it."
```

### Level 3: Data Deletion
**Required:** Level 2 + explicit row count awareness, backup verification.
```
Migration contains: DELETE FROM "audit_logs" WHERE created_at < '2023-01-01'
Confirm: "I understand this deletes ~50,000 rows. Backup verified. Proceed."
```

### Level 4: Full Reset
**Required:** All above + explicit database name confirmation.
```
Command: prisma migrate reset / drizzle-kit push --force
Confirm: Type the database name to confirm: ___________
```

## COMMON MISTAKES TO CATCH

### Prisma-Specific
- `migrate dev` on non-dev database
- Editing migration SQL after it's been applied elsewhere
- `@@map` or `@map` changes that rename without data migration
- Enum changes that remove values still in use

### Drizzle-Specific
- `push` instead of `generate` + `migrate` on persistent DB
- Missing `NOT NULL` default for existing rows
- `drizzle-kit drop` on migration that's already deployed elsewhere
- Introspect overwriting intentional schema divergence

### Universal
- Changing column type without considering data truncation
- Adding unique constraint to column with duplicate data
- Removing column that's still referenced in app code
- Deploying migration before code that handles new schema

## ROLLBACK REFERENCE

### Prisma Rollback Options
```bash
# Mark migration as rolled back (doesn't undo DB changes)
prisma migrate resolve --rolled-back [migration_name]

# Actual rollback requires manual SQL or restore
pg_restore -d mydb backup.dump
```

### Drizzle Rollback Options
```bash
# No built-in rollback: write reverse migration
drizzle-kit generate  # Create new migration to undo

# Or restore from backup
pg_restore -d mydb backup.dump
```

## QUICK COMMANDS REFERENCE

### Prisma
```bash
prisma migrate status          # Check pending migrations
prisma migrate dev             # Dev: generate + apply
prisma migrate deploy          # Prod: apply pending only
prisma migrate diff            # Preview changes
prisma migrate resolve         # Fix migration state
```

### Drizzle
```bash
drizzle-kit status             # Check state
drizzle-kit generate           # Generate SQL files
drizzle-kit migrate            # Apply migrations
drizzle-kit push               # Direct push (dev only)
drizzle-kit introspect         # Generate schema from DB
```

The part doing the work for migrate reset is Level 4: Full Reset: the agent has to name the database first. The rest keeps it reading generated SQL instead of trusting the schema diff, which is where dropped columns hide. Commit .cursor/rules/ so the whole team gets it.

Drizzle has the same trap

With Drizzle the risky command is usually drizzle-kit push. It applies your schema straight to the database with no migration file, and --force auto-approves data-loss statements. That's fine against a throwaway local database. Against anything persistent, use the tracked flow:

drizzle-kit generate   # writes SQL to your migrations folder
# read the SQL
drizzle-kit migrate    # applies it

Also check dbCredentials.url in drizzle.config.ts. If it reads process.env.DATABASE_URL, it has the same "which .env is loaded?" problem. The checklist above already matches **/drizzle/** and flags push on a persistent database.

Layer 3, optional: a hard stop

A rule is prose, so a determined agent can still ignore it. For a hard stop, add a Cursor hook. Project hooks live in .cursor/hooks.json, and a beforeShellExecution hook runs before each shell command the agent wants to execute. Its matcher is a regex tested against the full command string:

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      {
        "command": ".cursor/hooks/block-destructive.sh",
        "matcher": "migrate reset|--force-reset|--accept-data-loss|drizzle-kit push.*--force"
      }
    ]
  }
}

The script only runs for matching commands, so it can simply refuse:

#!/bin/bash
# .cursor/hooks/block-destructive.sh
cat > /dev/null
exit 2

Make it executable with chmod +x .cursor/hooks/block-destructive.sh. Exit code 2 blocks the command, the same as returning "permission": "deny" in the hook's JSON output. Other non-zero exit codes fail open and let the command through, and project hooks only run in a trusted workspace. Run those commands yourself, in your own terminal, when you mean it.

Written with AI assistance and checked against the Prisma and Cursor docs.