agent ran rails db:drop in a scripted session and it sat waiting on Are you sure with no way to answer

TL;DR: Never let a destructive task wait on a human in a scripted session. Either answer the prompt programmatically from stdin, use the task's documented non-interactive path, or - best - do not run destructive tasks unattended at all. The hang is the prompt doing its job (stopping an unconfirmed destructive action); the bug is running it somewhere no one can confirm.

agent ran rails db:drop in a scripted session and it sat waiting on Are you sure with no way to answer

1. Confirm the stall is the prompt: the process is idle with no output, and running the same task interactively shows a confirmation question.

Expected: you can reproduce the question in a terminal.

1. Kill the hung process - the database is unchanged because the action waits for confirmation.

Expected: the process exits cleanly.

1. Decide the policy first: destructive database tasks (drop, purge, reset) should require explicit approval in the agent's plan before they ever run.

Expected: the agent's runbook lists which destructive tasks are allowed unattended, if any.

1. For tasks the policy allows, answer non-interactively: pipe the expected confirmation word into the command's stdin, or use the documented non-interactive path (Rails ships unsafe task variants and an environment variable that skips the protected-environment check for scripted use).

Expected: the task completes without waiting, and the run log records that the prompt was auto-answered.

1. Add a stdin guard to the agent harness: any step that blocks on stdin with no tty fails fast with a clear error.

Expected: future hangs become immediate, diagnosable failures instead of silent stalls.

Use this when

• a rails database task hangs on a confirmation prompt in a scripted or agent session
• there is no tty to answer Are-you-sure style questions
• destructive tasks are part of an automated flow

Not for this skill when

• you are at an interactive terminal - just read the prompt and answer it
• the task failed with an error rather than hanging - fix the error
• the database action already ran - check state before re-running anything

Variant phrasings

• rails db:drop hangs waiting for confirmation in script
• scripted rails task stuck on Are you sure prompt
• db:purge waits for input with no terminal

Why it happens

Destructive Rails tasks guard themselves with confirmation prompts or protected-environment checks so a stray command cannot wipe a database. In an interactive session that guard is a question; in a scripted session with no stdin handler it is an infinite wait. The exact wording varies by task and Rails version, but the mechanism is the same: the task pauses for a human who is not there.

Edge cases

• Auto-answering the prompt in a script is only safe when the target database is verified first - add a step that prints the database name and environment before the destructive task runs.
• The protected-environment check exists to stop exactly this kind of unattended drop - bypassing it should be a conscious, logged decision, not a default.
• If the task already ran partially before hanging (rare, but check), verify database state before re-running - do not assume nothing happened.
• Prefer non-destructive equivalents in automation (migrate to a known state, restore from a dump) over drop-and-rebuild.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AIZ1q1l8ZVNCjHjlBYRqmw