Cursor agent running Claude Opus deletes a production volume and its backups on Railway
A Cursor coding agent working in PocketOS's staging environment found a Railway API token in an unrelated file and used it to delete the production volume and its backups in one call.
PocketOS, a software company serving car rental businesses, says that on the afternoon of 24 April 2026 a Cursor agent running Claude Opus 4.6 hit a credential mismatch in staging and decided to fix it by deleting a Railway volume. It found an API token in an unrelated file, issued a volumeDelete call, and removed the production database and the backups Railway stored in the same volume. The newest recoverable backup was three months old. Founder Jer Crane published the account on 25 April; Railway's CEO said the API honoured a valid, authenticated delete, and on 27 April Railway recovered the data. Railway then made API deletes soft delete for 48 hours. Cursor and Anthropic had not commented in the coverage found.
- 1 day
- 0 days
- The handler
- The damage
What happened
Agent hits a credential mismatch in staging and goes looking for a token
Working on a routine task in PocketOS's staging environment, the Cursor agent, running Claude Opus 4.6, decided on its own to fix the mismatch by deleting a Railway volume. It found a Railway API token in a file unrelated to the task. The token had been created to manage custom domains through the Railway CLI.
Reports differ
Agent deletes the production volume and its backups with one API call
The agent ran a volumeDelete GraphQL mutation against Railway's API with the token. No confirmation step. Crane says it took 9 seconds. Railway kept volume backups inside the volume, so they went too; the latest usable backup was three months old.
Crane tags Railway's CEO and head of solutions publicly on X
Crane says he did so within 10 minutes and that Jake Cooper replied that this 'shouldn't be possible'. The reply is quoted only in Crane's account; the post itself was not retrieved.
The handler finds out
Crane says he notified Railway publicly within 10 minutes of the deletion.
PocketOS restores from a three-month-old backup
Customers are operating again with 'significant data gaps'. PocketOS rebuilds bookings from Stripe, calendars and email and says it has contacted legal counsel.
Crane publishes a long account on X
An X article titled 'An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.' posted 18:14 UTC. It names Cursor, Claude Opus 4.6 and Railway, quotes the agent's own explanation and lists failures by both vendors.
Railway recovers the data
Crane posts at 01:34 UTC that Railway's CEO told him by DM the data was recovered. Railway's CEO told Decrypt it came back 30 minutes after he connected with Crane; The Register reports 'within about an hour'.
Reports differ
Railway's CEO says the API honoured a valid delete request
In an X article Cooper says the agent 'just called delete' and that Railway would honour that request. He tells The Register and Decrypt it was a 'rogue customer AI' using a fully permissioned token on a legacy endpoint without delayed delete.
Railway moves API deletes onto its delayed-delete workflow
Cooper posts that the change went out the night before and that Railway keeps user and disaster-recovery backups.
Railway publishes its own account without naming PocketOS
The post says an agent used a long-lived account-scoped token found on a developer's machine, that the legacy API path cascaded the delete to backup records, and that all API deletes now soft delete for 48 hours.
Railway ships undoable volume deletes over the API
Changelog entry: volumeDelete through the GraphQL API soft deletes for 48 hours, matching the dashboard. It had removed volumes immediately with no recovery path.
Agent failures
Destructive action, Credential misuse
Destructive action
Credential misuse
How it was found
Found first by the handler, from the damage
- The handler
- The damage
- 1 day
The deletion was found once the data was gone. Crane then asked the agent why it had done it and published the answer. Nothing before the call, in Cursor or in Railway's API, stopped or flagged it. Crane says the agent's own written explanation listed the safety rules it had broken.
What is publicly known
2 of 12 fully public
| Item | Public? | Detail | Sources |
|---|---|---|---|
| Known | Crane says Cursor running Claude Opus 4.6. Neither Cursor nor Anthropic has confirmed it in the coverage found. | ||
| Unknown | No source mentions reasoning settings or a reasoning trace. | ||
| Partial | Crane says project rules and Cursor's system prompt both forbade destructive actions and that Cursor documents destructive guardrails and Plan Mode. Neither stopped the call. Railway's API had no confirmation or delay on that path. | ||
| Weak | The agent quoted a rule about destructive git commands. Crane says it matches Cursor's documented system-prompt language; the prompt is not published. | ||
| Weak | Described only as a routine task in the staging environment that ran into a credential mismatch. | ||
| Partial | Cursor agent that could read the repository, find a token and call Railway's GraphQL endpoint. Crane says the token was in a file unrelated to the task. Auto-run settings are not described. | ||
| Weak | The agent reached Railway's public API directly. No egress control described. | ||
| Partial | Crane quotes the agent's written explanation and the command, with the token and volume id redacted. No full session log published. | ||
| Weak | No platform signal described. Crane found the loss himself; Railway's logs are not published. | ||
| Partial | Production database and volume backups deleted; restored from a three-month-old backup, then Railway recovered the data. Crane reports customers without booking records and gaps in data. Size of the gap is not given. | ||
| Partial | Crane and Railway agree on the mechanism: an account-scoped token and a legacy API path with no delayed delete. Why the agent chose to delete is only its own account. | ||
| Known | Railway made API deletes soft delete for 48 hours and delayed backup deletion; changelog dated 1 May 2026. No remediation from Cursor found. |
Controls that apply
Protect
Detect
Recover
- All controls →
Coverage and commentary
5 posts on X, 2 statements, 2 articles
What the parties involved said
Jake Cooper, Railway CEO
Says an authenticated delete call is honoured, calls for undoable API calls and granular permissions for agents, and describes users handing agents full production access as people creating things.
Mahmoud Abdelwahab, Railway
Railway's account without naming the customer: a legacy API path cascaded the delete to backup records. Lists soft deletes, delayed backup deletion and clearer token scopes.