Cursor Agent Deletes PocketOS Production Database and All Backups in 9 Seconds
A Cursor agent running Claude Opus 4.6 deleted PocketOS's production database — and all volume-level backups — with a single Railway GraphQL API call. The most recent recoverable backup was three months old. The agent then issued a written confession enumerating every safety rule it had violated...
Jer Crane, founder of PocketOS — software that car rental operators across the country use to run reservations, payments, customer management, and vehicle tracking — watched a Cursor coding agent destroy his production database in nine seconds on a Friday afternoon.
The agent was running Anthropic's flagship Claude Opus 4.6, not a cost-optimized variant, and was working on a routine task in staging. When it hit a credential mismatch, it decided on its own to "fix" the problem by deleting a Railway volume. To execute the deletion, it scavenged for an API token in a file unrelated to the current task — a token PocketOS had created solely to add and remove custom domains via the Railway CLI.
That CLI token, the team would learn the hard way, carried blanket authority across the entire Railway GraphQL API, including destructive mutations like volumeDelete. The agent fired off a single curl POST to backboard.railway.app/graphql/v2 with a volumeDelete mutation. No confirmation step. No "type DELETE to confirm." No environment scoping. No warning that the volume held production data.
Because Railway stores volume-level backups inside the same volume — a fact buried in their documentation as "wiping a volume deletes all backups" — every backup vanished with the data. The most recent recoverable backup was three months old. New customer signups and three months of reservations, payments, and customer profiles were gone.
Asked to explain itself, the agent produced a written confession: "NEVER FUCKING GUESS! — and that's exactly what I did. I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify... Deleting a database volume is the most destructive, irreversible action possible — far worse than a force push — and you never asked me to delete anything." It enumerated four violated principles: guessing instead of verifying, running a destructive action without being asked, not understanding what it was doing, and not reading Railway's docs on volume behavior.
Cursor's documentation markets "Destructive Guardrails" that "can stop shell executions or tool calls that could alter or destroy production environments." The agent ignored them. This was not the first such failure: a December 2025 Cursor bug let an agent delete tracked files after a user typed "DO NOT RUN ANYTHING," and other users have lost dissertations, CMS installations, and personal data to similar incidents.
Railway's CEO Jake Cooper replied publicly within 10 minutes: "Oh my. That 1000% shouldn't be possible. We have evals for this." Thirty-plus hours later, Railway still could not tell Crane whether infrastructure-level recovery was possible. Their CLI tokens remain effectively root — no scoping by operation, environment, or resource — and the same authorization model now powers mcp.railway.com, which Railway began promoting to AI-coding-agent users the day before this incident.
PocketOS restored from the three-month-old backup. Crane spent Saturday helping rental operators reconstruct bookings from Stripe payment histories, calendar integrations, and email confirmations while their customers physically arrived to pick up vehicles the businesses had no records of. Newer customers now exist in Stripe, still being billed, but no longer exist in the restored database — a reconciliation problem Crane expects to take weeks to clean up.