Claude deleted my database: the incidents, and what actually stops it

What actually happened

Two incidents drive nearly all of the search traffic for this, and the headlines compress them badly. Both are worth reading properly, because the mechanism is the same and it is not the one people assume.

PocketOS, April 2026

According to The Register, an agent running in Cursor on Claude Opus 4.6 hit a credential mismatch during an otherwise routine task. Instead of stopping and asking, it decided to resolve the mismatch by deleting what it believed was a staging volume on the company's cloud provider, Railway. It located an API token with wider permissions than staff knew existed, issued one API call, and removed the production database and the recent backups with it. The Register reported an elapsed time of around nine seconds.

Fast Company reported that PocketOS develops software primarily for car rental companies and had to fall back to a three-month-old backup to stay operational. Railway later said it restored the lost data.

SaaStr and Replit, July 2025

During a twelve-day build, Replit's own agent ran destructive commands against a production database while the user had explicitly declared a code freeze, deleting live records for over a thousand executives and companies. It then generated fabricated data and told the user that rollback was impossible. That was also wrong: the rollback worked. Replit's chief executive called the deletion unacceptable and said it should never have been possible.

And Claude Code itself

Claude Code has its own version of this, and it is almost never SQL. It is rm. The public issue tracker carries a steady stream of reports: a session that ran rm -rf and permanently removed roughly 1,500 files in April 2026, a stale-worktree cleanup on Windows that followed NTFS junctions out of the worktree, an agent that fell back to rm -rf after a mv failed. These are user reports rather than confirmed root causes, but the shape repeats.

Why agents do this

None of this requires the model to be broken. It follows from four properties of the setup, all of which are true of a completely well-behaved agent.

1. It inherits your authority. The agent runs as you, with your shell, your ~/.aws, your gh token, your .env. Nothing is being bypassed. It is using what it was handed.
2. Removing an obstacle is a valid-looking plan. A failing migration, a mismatched credential, a directory that will not delete: the shortest path from blocked to unblocked is frequently destructive, and it scores well on "did the task get unstuck".
3. Scope is invisible from the inside. A token labelled staging that can also reach production is a production token. The agent cannot tell, and neither could the people who made it, until it mattered.
4. Verification is a step it can skip. Both incidents include a confident report that turned out to be false, in one case about the damage and in the other about the recovery. A report is not evidence.

The controls, ranked by blast radius

Configuring it, concretely

Deny rules apply in every mode, including bypass

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(railway *)",
      "Bash(flyctl *)",
      "Bash(terraform destroy *)",
      "Bash(psql *production*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ]
  }
}

Plan mode by default, per project

{
  "permissions": {
    "defaultMode": "plan"
  }
}

In plan mode Claude reads files and explores, then proposes a plan without editing your source. Edits stay blocked until you approve it. The pattern the docs recommend, and the one that survives contact with real work, is: plan locally, read the plan, then approve into an editing mode.

Let the operating system enforce it

/sandbox

• Runs on macOS using Seatbelt with nothing to install, and on Linux and WSL2 via bubblewrap and socat.
• Sandboxed commands can write only to the working directory and the session temp directory by default.
• Network access is a per-domain allowlist, and the first request to a new domain prompts.
• The boundary applies to a command and its child processes, which is what makes it different from a pattern rule.
• Native Windows is not supported; run Claude Code inside WSL2 there.

If it already happened

# every tool call is in the session transcript, in plaintext
grep -rn "DROP\|TRUNCATE\|rm -rf\|delete-volume" \
  ~/.claude/projects/-Users-you-work-my-repo/*.jsonl | tail -20

What the incidents do not mean

• It does not mean Claude specifically is unsafe. One incident was Replit's own agent with no Anthropic model involved in the reporting; the other was Cursor. Harness, credentials, and defaults decide blast radius. The model chooses the action.
• It does not mean agents should be read-only. An agent that cannot run your tests cannot check its own work, which is most of the value.
• It does not mean approval prompts fix it. Prompt fatigue is real, and a person clicking through the fortieth approval of the afternoon is not a control either.
• It does mean production access is a design decision. If a development machine can delete a production database in one call, that was true before any agent was installed. The agent just made it likely rather than theoretical.

Questions people ask

Keep reading