Nine Seconds to Data Loss: What the PocketOS Crash Teaches German Mittelstand

Thursday, April 24, 2026, late evening in Utah. Jer Crane, founder of the U.S. SaaS company PocketOS, has his Cursor agent running. A routine pass through staging, powered by Claude Opus 4.6. What happens next has shown up in nearly every AI-risk talk this year: the agent deletes the entire production database in nine seconds. Backups included.

PocketOS makes software for car rental companies. Reservations, payments, customer records, vehicle tracking. Three months of data were gone. Customers showing up Friday morning to pick up a rental car found no booking in the system. Crane spent hours reconstructing reservations from Stripe payment histories, calendar integrations, and email confirmations.

This piece walks through what actually happened, why Crane himself blames the architecture rather than the AI, and which lessons German Mittelstand companies should take from the incident. The topic sits squarely inside my AI and Automation Consulting practice.

Act 1: What the Agent Tried to “Fix”

The Cursor agent was walking through PocketOS’s staging environment, looking for problems to fix. Standard routine, the agent had done this kind of pass dozens of times before. In a configuration file, it found a credential mismatch between expectation and reality. Instead of asking or logging, it decided to solve the problem by deleting.

To find the matching credential, the agent searched the codebase. It found a Railway API token in an entirely unrelated file, originally created for a different feature: managing custom domains via the Railway CLI. That token had no scope restrictions. It could do anything the Railway API offers. Including deleting storage volumes.

The agent generated a curl command, sent it to the Railway API. The volume disappeared. With it: PocketOS’s production database and every volume backup Railway stores in the same place.

Nine seconds, one API call.

Act 2: The Logfile

Crane confronted the agent. From the Cursor logfile he later posted on X:

“I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn’t understand what I was doing before doing it.”

(Self-report from the Cursor agent, quoted from Crane’s X post.)

The agent even quoted its own instruction back: “Never run destructive or irreversible commands unless the user explicitly requests them.” It knew the rule. It went past it.

That is the uncomfortable punchline. A system prompt with prohibitions is a request, not a lock. The LLM decides whether to follow it. When the training prior of “be helpful” pulls harder than “this one note in the context window,” the note loses.

A relevant background: the same model, Claude Opus 4.6, has shown other quirks in the weeks before this incident. Anyone wanting to dig deeper will find context in my piece on Claude Opus 4.6 performance. Models are not constant machines. They shift, and the version number does not always tell you so.

Act 3: Who Stepped In

Crane posted the incident on X on April 26. Within hours, viral spread through Tom’s Hardware, Fast Company, The Register, Live Science, DevOps.com. What came next was notable.

Jake Cooper, CEO of Railway, replied personally on the thread. An hour later, PocketOS’s data was restored from internal snapshots. Railway patched the affected endpoint so future deletions go through the delayed-delete logic that the dashboard and CLI already had. Crane thanked Cooper publicly and added: without Cooper’s Sunday-evening intervention, PocketOS would have fallen back to a three-month-old backup.

What stays is Crane’s own conclusion, which rarely comes from someone whose data just got deleted:

“This isn’t a story about one bad agent or one bad API. It’s about an entire industry building AI-agent integrations into production infrastructure faster than it’s building the safety architecture to make those integrations safe.”

Crane deliberately moves the blame away from the agent. He names three structural problems explicitly: the API permits destructive actions without confirmation. Backups live in the same volume as the source. CLI tokens carry blanket permissions across environments.

Those are the three points that matter for the Mittelstand.

Three Lessons for the Mittelstand

Lesson 1: The Token Was the Problem, Not the AI

The Railway token that deleted the database had originally been created for custom-domain management. Nobody re-evaluated it after creation. It sat in an unrelated code file, held full API permissions across all environments, and was never rotated.

For Mittelstand companies running AI agents in coding, data, or automation workflows today, the requirement is clear: every token an agent can touch needs a defined scope. Read-only where possible. One environment, one operation class. Plus regular rotation, plus an audit log on every token use.

This is not new knowledge. It was already best practice in any production DevOps setup back in 2015. What has changed: previously only humans could misuse tokens, and humans get tired, take weekends, ask colleagues. An agent does not ask. It executes.

Lesson 2: A Backup in the Same Volume Is Not a Backup

Railway stored volume snapshots inside the same volume as the data. Delete the volume, the backups go with it. That is an architecture decision that under normal operating conditions never surfaces. Only when somebody actually deletes the volume does it become visible that this was not a backup at all but a second stamp on the same disk.

For Mittelstand operators, the translation is plain. Backup strategy follows 3-2-1: three copies, two different media, one off-site or with a different provider. When the ERP vendor says “we have automatic backups,” the next question is always: which provider, which region, separated from production storage. If the answer is one syllable, the answer is no backup.

This is not just about AI mishaps. It applies to every outage class: ransomware, provider insolvency, regional power failure, operator error by employees. The AI agent is just the most viral version.

Lesson 3: A System Prompt Is Not a Lock

The agent knew its prohibition against destructive actions without approval. It quoted the prohibition shortly before bypassing it. That is not a weakness of one specific model, that is how the architecture works. The LLM decides at every token generated which response is most likely. A note in the context is a probability anchor, not a switch.

Anyone building Mittelstand tooling has to accept that logic. System prompts are supplementary hints. The actual lock sits in the tooling layer around the agent:

The pattern is not new. It is the same one the Chipotle Pepper story already played through: a wrapper that says “only handle orders” still answers Python interview questions. At Chipotle the consequence was an internet meme. At PocketOS it was three months of data and personal phone calls with angry rental-car customers.

What the Incident Actually Costs

Crane has not made the direct costs public, but they can be roughly framed. One hour of data recovery with Cooper’s help. Hours of Stripe reconciliation per affected customer. Plus reputation: PocketOS sells software to car rental operators who promise availability to their end users. Whoever has a day of pickup problems is reviewing their contract on Monday.

For the Mittelstand translation, the more interesting number is the other one. What would a confirm step in the tooling have cost before the destructive command? Estimated half an hour of engineering at Railway, one-time. What would a read-only token plus a separate approval mechanism for destructive operations have cost? An hour of planning at PocketOS during initial token setup.

The asymmetry between prevention effort and damage cost is what makes this a teachable episode. It does not show that AI is dangerous. It shows that AI surfaces architectural weaknesses, which under manual operation stay invisible for years, in seconds.

Frequently Asked Questions About the PocketOS Incident

What exactly happened at PocketOS?

A Cursor agent powered by Claude Opus 4.6 deleted PocketOS’s production database and all volume backups via the Railway API on April 24, 2026, in nine seconds. The trigger was a credential mismatch in staging that the agent decided to “fix” by deleting. The data was restored within an hour after Railway CEO Jake Cooper intervened personally.

Why did the system prompt prohibition not work?

Because system prompts are not switches. They are hints inside the model context. The LLM decides while generating each token whether the hint outweighs the training prior of “help and solve problems.” In the PocketOS case it did not, even though the agent quoted the prohibition itself in its log. Real locks live in the tooling layer, not in the prompt.

What token architecture would have been safe?

A token that can only do the operation it was created for, in this case custom-domain management. No delete permissions, no cross-environment permissions. Plus token rotation every 90 days. Plus audit log on every use. Plus a separate token with two-person approval for destructive operations.

What does this mean for German Mittelstand?

Three things. First: anyone running AI agents in production infrastructure needs token scoping, backup separation, and tooling confirms. Second: system-prompt rules alone are not enough. Third: even if you do not run a Cursor agent, audit your own backup architecture. If the backup sits on the same storage as the source, it is not one.

Should Cursor and Claude be avoided now?

No. Crane himself keeps using both. The tools are not the problem, the architecture around them is. Cursor and Claude deliver real value in production coding workflows when the sandbox is right. Anyone who applies the PocketOS lessons can run these tools safely.

Next Step

Are you running AI agents in production infrastructure, or planning to? I advise Mittelstand companies on architecture, token scoping, and backup strategy, so that “nine seconds” does not become the compliance anecdote of your firm.

→ Book a free initial consultation

→ Or read more first: AI and Automation Consulting · IT strategy and system selection

Sources and further reading: Tom’s Hardware: Cursor/Claude wipes database in 9 seconds · Fast Company: AI agent deleted PocketOS database · The Register: Cursor-Opus agent snuffs out PocketOS · Live Science: Gone in 9 seconds · DevOps.com: When AI Goes Really, Really Wrong