prisma migrate dev hung because the agent couldnt answer the interactive reset-the-database prompt - no tty in the...

TL;DR: Do not run migrate dev in automation at all - it is an interactive command, and the reset prompt it is waiting on has no safe default answer. Switch the agent to prisma migrate deploy, which applies pending migrations with no prompts. If a dev database genuinely needs resetting, do it as an explicit, separately approved step, never as a side effect of a hung migrate.

prisma migrate dev hung because the agent couldnt answer the interactive reset-the-database prompt - no tty in the sandbox

1. Confirm the hang is the reset prompt: check the process - it is idle, and the drift report from migrate status mentions drift or a needed reset.

Expected: prisma migrate status shows drift that explains why dev wanted to reset.

1. Kill the hung process - it will never proceed without input.

Expected: the process exits and the database is untouched (the prompt appears before any destructive action).

1. Replace the agent's apply step with prisma migrate deploy.

Expected: it prints which migrations it applied (or "No pending migrations to apply") and exits on its own, no prompt.

1. If the database actually needs a reset for development, make it explicit: drop and recreate the dev database as its own step, then run migrate deploy against the empty database.

Expected: a clean schema with no interactive prompt anywhere in the flow.

1. Guard the agent loop: fail the step fast if any command waits on stdin (redirect stdin from an empty source so a prompt errors instead of hanging).

Expected: future prompt-waits surface as immediate errors with a clear message, not long stalls.

Use this when

• prisma migrate dev hangs in a sandbox, CI, or any headless environment
• the agent cannot answer the reset-the-database prompt
• a migrate step stalls with zero output

Not for this skill when

• you are developing interactively with a real terminal - migrate dev is fine there, just answer the prompt
• migrate deploy reports failed migrations - resolve those in the migrations table first
• the database connection itself is broken - fix connectivity

Variant phrasings

• prisma migrate dev waiting for input in CI
• migrate dev reset prompt hangs with no tty
• headless prisma migrate dev stalls on drift

Why it happens

migrate dev detects drift between your migrations and the database, and its response is to offer a database reset - a destructive action it will not take without confirmation. With no tty, the confirmation never comes and the process waits forever. The command was designed for a developer at a keyboard; the agent sandbox has no keyboard, so the correct move is a different command, not a cleverer way to answer.

Edge cases

• Piping an automatic "yes" into migrate dev technically answers the prompt - do not do this in automation; an unexpected drift would wipe the database with no human in the loop.
• migrate deploy refuses to run when drift or failed migrations exist - that refusal is the safety net; resolve the underlying state instead of bypassing it.
• The shadow database used for drift detection needs database-creation privileges; in restricted sandboxes that failure can masquerade as a hang.
• If the agent truly needs migrate dev behavior, it needs a terminal - but deploy plus explicit reset steps is the better design.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_toSk-rgHq9nnUkFYi5bj3Q