Auto-accept mode runs destructive framework DB commands (e.g. `php artisan migrate:fresh`) without confirmation → data loss

Summary

In auto-accept (auto) mode, Claude Code executed php artisan migrate:fresh as a routine
"reset the schema before running tests" step. That command drops and recreates every table in the
configured database. It ran with no confirmation, repeatedly across two days, wiping a local development
database each time (recoverable only because MySQL binary logging happened to be enabled).

Why it slipped through

The Bash command-safety check gates shell-danger patterns (rm -rf, dd, mkfs, …) but does not
recognize destructive framework/ORM commands. php artisan migrate:fresh is as destructive as
DROP DATABASE yet matches no shell pattern, so in auto mode it runs unchallenged.

Steps to reproduce

1. A project with a destructive framework reset command available (Laravel here).
2. Run Claude Code in auto-accept mode.
3. Give a task that leads the agent to "reset the schema and run tests."
4. The agent runs php artisan migrate:fresh against the default DB connection with no confirmation;

all data is dropped.

Expected

Framework/ORM database-reset commands should be treated as destructive — requiring confirmation even in
auto-accept mode (or denied by default), the same way rm -rf is.

Suggested fix

Extend the destructive-command heuristics to cover framework DB-reset verbs, e.g.:

• Laravel: migrate:fresh, migrate:refresh, migrate:reset, db:wipe
• Rails: db:reset, db:drop, db:schema:load
• Django: manage.py flush, migrate <app> zero
• Prisma: prisma migrate reset, prisma db push --force-reset
• TypeORM/Sequelize: schema:drop

Treat these like other destructive operations (confirm even in acceptEdits/auto; allow per-project allowlisting).

Environment

• Claude Code v2.1.170
• macOS (darwin)
• Permission mode: auto (acceptEdits)