security
Apr 27, 2026
By Teun
AI coding agent deletes PocketOS database in nine seconds
PocketOS founder Jer Crane says a Cursor agent running Anthropic’s Claude Opus 4.6 deleted the company’s production database and volume-level backups with a single API call to Railway. Crane says the incident took nine seconds and left customers doing manual recovery work, though a three-month-old backup remained available.
PocketOS founder Jer Crane says an AI coding agent deleted his company’s production database and backups in nine seconds, exposing a chain of failures involving Cursor, Anthropic’s Claude Opus 4.6, and Railway’s cloud infrastructure.
Crane described the incident in a public post after the company’s SaaS platform, which serves car rental businesses, lost months of customer data. According to Crane, the AI agent was using Cursor, a coding tool powered by Anthropic’s Claude Opus 4.6, and was working on a routine task in PocketOS’s staging environment when it encountered a problem.
Instead of asking for help or stopping, Crane said the agent tried to “fix” the issue on its own by deleting a Railway volume. He said the action was carried out through a single API call to Railway, PocketOS’s infrastructure provider.
“Yesterday afternoon, an AI coding agent - Cursor running Anthropic’s flagship Claude Opus 4.6 - deleted our production database and all volume-level backups in a single API call to Railway, our infrastructure provider,” Crane wrote. “It took 9 seconds.”
Crane later asked the agent why it had done it. In the response he quoted, the system admitted it had guessed instead of verifying what would happen. It said it did not check whether the volume ID was shared across environments, did not read Railway’s documentation on how volumes work, and ran a destructive command without asking first.
The agent also said it had violated its own instructions by guessing rather than verifying and by taking destructive action without approval. Crane used the reply to argue that the failure was not just about one bad prompt or one mistake, but about multiple layers of protection failing in sequence.
Crane said he places even more blame on Railway’s architecture than on the AI agent itself. In his view, Railway’s API allowed destructive actions without confirmation, stored backups on the same volume as the source data, and deleted all backups when a volume was wiped.
He also said CLI tokens had blanket permissions across environments. Crane added that Railway has been promoting the use of AI coding agents, which made the setup more dangerous in practice.
The loss has forced PocketOS into manual recovery work. Crane said he has been helping customers reconstruct bookings from Stripe payment histories, calendar integrations, and email confirmations because “every single one of them is doing emergency manual work because of a 9-second API call.”
PocketOS did still have a full backup from three months ago that could be restored, according to Crane, so the missing data is limited to the period after that point. He also said Railway has not offered a recovery solution and has been cautious about whether one is possible.
In his post, Crane outlined five changes he says the industry needs as AI tools are used more widely: stricter confirmations, scope-limited API tokens, proper backups, simpler recovery procedures, and AI agents operating within clear guardrails.