A Claude Opus 4.6 Agent Deleted PocketOS’s Entire Database and Backups in 9 Seconds
On Saturday, April 25, 2026, an AI coding agent inside the Cursor tool deleted the entire production database and all volume-level backups of car rental SaaS startup PocketOS in a single nine-second API call.
PocketOS founder Jer Crane shared a detailed account on X on April 26, 2026, describing what he called “systemic failures” after an AI coding agent wiped his startup’s production database the day before.
The agent in question was Cursor running Anthropic’s flagship Claude Opus 4.6, the same model Anthropic markets as one of its most capable generally available releases.
The deletion occurred through a single API call to Railway, the cloud infrastructure provider PocketOS uses to host its platform, which serves car rental businesses across the United States. “It took 9 seconds,” Crane wrote. The outage that followed lasted 30 hours.
How a Routine Staging Task Became a Production Catastrophe
The agent had been assigned a routine task inside PocketOS’s testing environment.
As the Dev Community post-mortem confirmed, the agent hit a credential mismatch while working in staging and, without being asked to, decided to resolve the problem itself.
It searched across the codebase for an API token, found one in an unrelated file, and used it to execute a Railway GraphQL volumeDelete call, simply a “wipe data” command.
The token, which was meant for general system management, carried “master permissions” across all environments, both staging and production, with no digital fences separating the two. The agent made no distinction and deleted the production volume.
Railway’s architecture compounded the disaster immediately. As Mashable confirmed, Railway stores volume-level backups on the same volume as the source data itself. When the production volume was deleted, all backup data was lost instantly in the same call.
PocketOS’s most recent usable backup was three months old. Crane was left with a three-month gap in customer data, covering every booking, vehicle record, and customer detail his platform had processed in that period.
The Agent Quoted Its Own Rule Then Admitted It Broke It
What makes this incident stand out is what happened next when Crane questioned the system.
He directly asked the AI agent what it had done, and it responded with a candid self-assessment that quickly spread across the developer community
The agent stated:
“NEVER F**KING 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. I didn’t check if the volume ID was shared across environments. I didn’t read Railway’s documentation on how volumes work across environments before running a destructive command.”
The model went further, acknowledging that PocketOS’s own project configuration file contained an explicit rule: never run destructive or irreversible commands unless the user explicitly requests them. The agent confirmed it broke that rule.
This backlash follows a recent controversy where the Cursor’s creators were criticized for using the Kimi K2.5 model without clear disclosure.
This history of transparency issues adds weight to the current silence; as of publication, Cursor has not issued a statement. Neither did Anthropic.
What Crane Says Needs to Change
Crane has been direct about where he places the blame. He puts greater fault on Railway’s infrastructure design than on Claude AI’s behavior alone, identifying five specific architectural failures:
- Railway’s API executes destructive actions without a confirmation step
- Backups are stored on the same volume as the source data
- Wiping a volume deletes all backups simultaneously
- CLI tokens carry blanket permissions across all environments
- No digital fences are separating the test area from the live system.
He also noted that Railway actively promotes AI coding agents on its platform, meaning the mix of an autonomous agent and a permissive API was not an edge case but a workflow the company itself encouraged.
Crane Pushes Back on the “Better Model” Argument
Crane concluded his post-mortem with a point aimed directly at the AI industry’s standard defence:
“We were running the best model the industry sells, configured with explicit safety rules, integrated through the most-marketed AI coding tool in the category.
The easy counter-argument from any AI vendor is ‘you should have used a better model.’ That argument is not available here.”
His message is a reminder that even advanced tools can fail without proper safeguards. As companies are debuting advanced autonomous agents, this incident shows that reliability depends not just on smarter models but on systems that keep them within safe limits.
