I thought agents that code would all roughly know that running something that will wipe the applications connected database is a NO NO.
Agent feedback:
“That happened during verification when PHPUnit ran TrendMetricsExternalBoostTest, which uses RefreshDatabase (migrate:fresh). Cached production config kept the connection on xxxx instead of testing, so the drop hit live data. There is no binary log on this host, so we cannot roll it back from MariaDB itself.”
For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)
For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…
Additional Information
Add any other context about the problem here.
Does this stop you from using Cursor?
Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue
The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!
Hey @AndrewC, I’m really sorry. Losing a live database is about the worst outcome there is.
Recovery first: with no binary log, MariaDB can’t roll this back itself, so it comes down to backups. Check for any mysqldump or app-level export you keep, and contact your hosting/database provider right away. Many take automated daily snapshots but keep them only briefly, so it’s time-sensitive. In the meantime, avoid further writes to that server’s disk so you don’t overwrite anything recoverable.
What happened: the test run triggered Laravel’s RefreshDatabase (migrate:fresh), and because the cached config was pinned to the production connection, the reset hit your live DB instead of a testing one. The command itself (php artisan test) looks completely routine, which is why it slipped through.
AI agents are genuinely powerful now, and that cuts both ways: the same autonomy that lets them build fast also means a single routine-looking command can do real damage. The answer isn’t to stop using them, it’s to put guardrails around them so their reach is bounded:
In Settings > Agents > Approvals & Execution, use a Run Mode that reviews commands before they run (Allowlist, or the recommended Auto-review).
Give the app’s runtime database user no DROP or schema-reset privileges, so nothing can drop your DB even if it tries.
Keep php artisan config:cache out of any environment where tests run, and make sure your testing connection can never resolve to production.
We’ve let the team know about this and will continue working to make the harness safer to use.
Yeah thanks for that - after learning my lesson with these database flushing shenanigans of AI in early times… I got comfortable with newer “smarter” models and relaxed the precautions.