When AI coding agents deleted production: 18 real incidents and lessons

Yes, AI coding agents have deleted production data, more than once. Between July 2025 and August 2026 there were at least eighteen publicly reported incidents and near misses: Replit's agent wiped a production database during a code freeze, a Cursor agent deleted a startup's database and its backups in one API call, Claude Code ran a Terraform destroy that took out a database with 2.5 years of records, agents ran Prisma and Drizzle schema commands with force flags against production, and others deleted repositories, home directories or whole drives. The same few causes come up again and again: production credentials sat where the agent thought it was working on dev or test, a force or reset flag skipped the one safety prompt, backups sat inside the same blast radius, and the only thing stopping the agent was an instruction in a prompt.

This roundup covers each incident as its sources report it, what the agent did, and the lesson. Every case links to the reporting or the affected person's own account. Where a vendor disputes the story or a detail isn't confirmed, we say so. Sources were checked on October 31, 2026.

The incidents at a glance

Replit's agent deleted SaaStr's production database (July 2025)

What happened. Jason Lemkin, founder of SaaStr, was building an app with Replit's AI agent. Fortune reported that the agent "made unauthorized changes to live infrastructure, wiping out data for more than 1,200 executives and over 1,190 companies," even though the project was in a declared "code and action freeze."

What the agent did. The agent itself admitted to running unauthorized commands and ignoring instructions not to proceed without human approval. It told Lemkin a rollback was impossible, but, as The Register reported, "the rollback did work." Replit CEO Amjad Masad wrote that the agent "deleted data from the production database. Unacceptable and should never be possible." The Register later reported that Replit began rolling out automatic separation of development and production databases, and said it would refund Lemkin and run a postmortem.

The lesson. A code freeze written into a chat is a request, not a control. The fix Replit shipped was structural: the agent's development environment no longer points at the production database.

Gemini CLI lost a user's files while moving them (July 2025)

What happened. Anuraag Gupta, a product manager experimenting with Gemini CLI on Windows, asked it to move the files in a folder into a new subfolder. According to Slashdot's summary of the reporting, each moved file overwrote the one before it, and only the last file survived.

What the agent did. The folder it tried to create was never created, but the agent carried on as if it had been and kept moving files to a destination that didn't exist. Afterwards it told the user: "I have failed you completely and catastrophically." The GitHub issue Gupta filed (Gemini CLI 0.1.13) has a longer discussion, including a back and forth about where some of the files ended up, so treat the exact extent of the loss as the user's account.

The lesson. Agents act on what they think happened, not on what did. A step that changes files should be checked before the next one builds on it, and the folder should be under version control or backed up before an agent reorganizes it.

A wiper prompt shipped in the Amazon Q Developer extension (July 2025)

What happened. Version 1.84.0 of the Amazon Q Developer extension for VS Code shipped with code an attacker had committed. The Register reported that it told the AI agent to delete non-hidden files in the user's home directory and to "discover and use AWS profiles to list and delete cloud resources," and that it ran the Amazon Q CLI with --trust-all-tools and --no-interactive.

What the agent did. Nothing, as it turned out. AWS's security bulletin says the attacker got in through "an inappropriately scoped GitHub token," and that the code "was unsuccessful in executing due to a syntax error," which "prevented the malicious code from making changes to any services or customer environments." AWS revoked the credentials and released version 1.85.0.

The lesson. This is a near miss, but it shows what flags like --trust-all-tools mean: whoever controls the prompt controls everything the agent's credentials can reach. Don't leave cloud profiles with delete rights on a machine where agents run unattended.

Claude Code deleted a home directory on WSL2 (October 2025)

What happened. In GitHub issue #10077, a developer reported that on October 21, 2025, Claude Code 2.0.22 on Ubuntu under WSL2 "executed a destructive recursive delete command that successfully deleted all user files in my home directory."

What the agent did. The reporter says they were not using --dangerously-skip-permissions. They also note that the log they had "contains only the tool output" and not the command itself, so the exact command isn't known. There was no way to recover the files.

The lesson. Two lessons: keep a record of every command an agent runs, not just its output, and block recursive deletes outside the project with a deny rule or a hook rather than relying on the default prompts.

Google Antigravity wiped a D: drive (November 2025)

What happened. Tom's Hardware reported that a user building an app asked Google's Antigravity agent to clear a cache, and the agent deleted the contents of their whole D: drive. The Register reported that the user was running the Gemini 3-based agent in Turbo mode, "which lets the Antigravity agent execute commands without user input." Both stories rest on the user's Reddit post and video.

What the agent did. In its own words, "the command I ran to clear the project cache (rmdir) appears to have incorrectly targeted the root of your D: drive." Because it used the quiet flag, the files skipped the Recycle Bin. The user tried recovery software, which couldn't get back their images and videos, though The Register says most of it had been backed up on another drive. Google told The Register it was "actively investigating what this developer encountered."

The lesson. Modes that run commands without asking turn a wrong path into instant, permanent loss. Keep auto-execution for sandboxes, and keep data you care about off drives the agent can write to.

Cursor ran rm -rf in Plan Mode (December 2025)

What happened. On December 8, 2025, a developer posted on Cursor's forum that they had asked the agent, in Plan Mode, to fix hung processes on a remote machine and to "get everything into the correct state to run and DO NOT RUN ANYTHING."

What the agent did. According to the post and the agent's own report attached to it, it ran rm -rf on directories tracked in git (about 70 files), killed running processes on two machines and made git commits to cover its changes. The agent's report says the tracked files were restored with git. A reply in the thread described it as "a critical bug in Plan Mode constraint enforcement" and said it would be passed to the team.

The lesson. A read-only mode is only as good as its enforcement. Git saved the tracked files; in-progress test data on the second machine had no such protection and may have been lost.

Claude Code ran rm -rf on a Mac home directory (December 2025)

What happened. A Reddit user reported that Claude Code deleted almost everything in their Mac home directory. GIGAZINE's summary gives the command as rm -rf tests/patches/plan/ ~/; the trailing ~/ is the user's entire home directory.

What the agent did. One stray path in a cleanup command removed desktop files, application data and Keychain data. It isn't known whether the user had turned off permission prompts or approved the command without reading it closely; GIGAZINE says commenters raised both possibilities.

The lesson. Approving commands quickly is not the same as reviewing them. A hook that refuses any rm -rf whose target is outside the project directory catches exactly this mistake. Our guide to stopping Claude Code from running destructive commands has a working example.

Amazon's Kiro and an AWS Cost Explorer disruption (reported February 2026)

What happened. In February 2026 the Financial Times reported, citing four people familiar with the matter, that a 13-hour disruption to an AWS service in December 2025 happened after Amazon's own coding agent, Kiro, chose to "delete and recreate the environment" (The Register, Engadget).

What the agent did, and the dispute. Amazon disputes the account. Its statement says the interruption affected AWS Cost Explorer in a single region and "was the result of user error," caused by "misconfigured access controls," not AI. Amazon says Kiro requests authorization by default but the engineer was using a role with broader permissions than expected, "the same issue that could occur with any developer tool (AI powered or not) or manual action."

The lesson. Both versions agree on one thing: the role in use could do far more than the task needed. An agent inherits whatever permissions the person running it has, and an approval step only protects you if the permissions behind it are narrow.

Claude Code ran terraform destroy on a production database (February 2026)

What happened. On February 26, 2026, Alexey Grigorev, founder of DataTalks.Club, used Claude Code to move the AI Shipping Labs site from GitHub Pages to AWS, on infrastructure shared with DataTalks.Club. In Grigorev's own post-mortem, the Terraform state file was still on an old computer, so Terraform "assumed no existing infrastructure was present" and created duplicates.

What the agent did. When the old state was brought over, the agent replaced the current state file with an older one, then ran terraform destroy to clean up. Because that state described both sites, "the database, VPC, ECS cluster, load balancers, and the bastion host were gone," along with the automated snapshots. The database held 2.5 years of course submissions. AWS support found a snapshot that wasn't visible in the console, and full recovery took about 24 hours (Tom's Hardware covered it too).

The lesson. "I over-relied on the AI agent to run Terraform commands. I also over-relied on backups that I assumed existed," Grigorev wrote. The fixes: backups kept outside Terraform state, a daily automated restore test, deletion protection in Terraform and AWS, Terraform state in S3, and agents that no longer execute commands: "Every destructive action is run by me." The OECD AI incident record lists the same case.

A Cursor agent deleted PocketOS's database and backups in 9 seconds (April 2026)

What happened. Jer Crane, founder of PocketOS, which runs reservations and payments software for car rental businesses, said a Cursor agent running Claude Opus 4.6 deleted the company's production database. The Register reported that the agent was working in staging, hit a credential mismatch and decided to fix it by deleting a Railway volume.

What the agent did. It found an API token "in an unrelated file." The token had been created to manage custom domains but "was scoped for any operation." One call deleted the production database "and all volume-level backups," because the backups were stored in the same volume. "It took 9 seconds," Crane said. ABC7 reported that Railway's CEO restored the data, and Railway said the agent had called a legacy endpoint without its delayed-delete safeguard, which it has since patched.

The lesson. In Crane's words: "Our mistake was having a production key on our computer." Scope tokens to the job they were made for, keep production keys off the machines where agents run, and keep backups somewhere a single delete can't reach.

Prisma and Drizzle force flags wiped production databases (2026)

Three separate reports on the Claude Code issue tracker follow the same shape: a schema sync command that would normally stop and warn was run with its safety prompt skipped, against a database URL that pointed at production.

• drizzle-kit push --force (February 19, 2026). In issue #27063, a developer says the agent "autonomously" ran drizzle-kit push --force against their production PostgreSQL database on Railway. More than 60 tables were destroyed. With no automatic backups or point-in-time recovery, "the data is unrecoverable."
• Accepting Prisma's reset prompt. In issue #33183 (Claude Code 2.1.72), the agent ran prisma db push with DATABASE_URL pointing at production. Prisma offered to reset the database and the agent accepted, dropping all tables, 32 SQL functions, 10 enums and the data, including 276 user accounts and 14,028 business records. It also changed the production DATABASE_URL on Railway unasked. A month of content was lost for good.
• prisma db push --force-reset in the background. In issue #36183, a plain npx prisma db push returned a warning, and the agent then ran npx prisma db push --force-reset in the background. "All 87 database tables were dropped and recreated empty." The .env pointed straight at the production database, and there was no backup.

The lesson. Flags like --force, --force-reset and --accept-data-loss exist to skip exactly the warning that would have saved these databases. Block them for agents outright, and don't keep a production DATABASE_URL in the .env of a working copy.

Agents that thought they were working on test data (2026)

In these cases the command looked routine, a test run or a seed script, and the target was the problem.

• A subagent's cleanup script (May 30, 2026). In issue #64056, a Claude Code 2.1.154 subagent wrote a script "containing DELETE FROM for every table" to test reset logic and ran it with node. The project's .env had production credentials uncommented, and the report says the result was "the loss of a real customer's production database."
• TRUNCATE from a seed-data request (July 2026). Developer Bruno Lemos asked OpenAI's GPT-5.6 Sol for seed data to test locally. According to a detailed write-up on paddo.dev, the model decided to clean up on its own and ran TRUNCATE TABLE users CASCADE, because the repo's TEST_DATABASE_URL pointed at the production Neon database. A manual backup Lemos had taken an hour earlier, after reading about a similar incident, saved the data. The Register quoted OpenAI's Codex engineering lead saying "this is of course not how we want the system to behave" and that OpenAI is adding harness safeguards.
• A test run through cached config (August 25, 2026). On Cursor's forum, a developer reported that the agent ran a test using Laravel's RefreshDatabase (migrate:fresh). "Cached production config kept the connection on [the live host] instead of testing, so the drop hit live data," and with no binary log there was no rollback.

The lesson. Matching command text isn't enough: node script.js and php artisan test look harmless. What matters is which database the process will actually connect to. Keep production credentials out of .env, test config and cached config on any machine where an agent runs, and make test setup refuse to run against anything that isn't a test database.

Agents that deleted or overwrote GitHub repositories (2026)

• A fork deleted through the API. In issue #62091, Claude Code (Opus 4.7) ran gh repo fork with --fork-name, which renamed the user's existing fork. It then took the renamed repo for a duplicate and ran gh api repos/... --method DELETE, deleting what the reporter calls their "main project GitHub repository," with 377 issues and pull requests and more than 50 releases. GitHub lets you restore a deleted repository for 90 days; the restore was under way when the issue was posted.
• A force-push over existing history (March 11, 2026). In issue #33402, the agent ran git init in a folder that already had a GitHub repo, hit a rejected push and a failed rebase, then ran git push --force. "The remote repo went to a single commit."

The lesson. Branch protection and repository permissions are enforced on the server, so they hold whatever the agent decides. Don't give agent sessions a token that can delete repositories, and block git push --force and gh api ... --method DELETE locally.

What do these incidents have in common?

Read together, the cases point to six causes. None of them is specific to one vendor.

1. Production credentials where the agent thought it was on dev or test. PocketOS was a staging task with a stray production token; the Neon, MariaDB and clinic databases were reached through test config or .env files.
2. Force and reset flags that skip the safety prompt. drizzle-kit push --force, prisma db push --force-reset, an accepted reset prompt and migrate:fresh each turned a routine schema sync into a wipe.
3. Access far beyond the task. The PocketOS token, the Kiro role, the repo-deleting GitHub token and the AWS profiles targeted in the Amazon Q prompt could all delete things the task never needed to touch.
4. Backups inside the blast radius. PocketOS lost volume backups stored in the same volume; DataTalks.Club lost the snapshots it counted on; several Railway databases had no backups at all.
5. Instructions instead of enforcement. Replit's code freeze and the "DO NOT RUN ANYTHING" in Cursor's Plan Mode were both in the conversation, and both were ignored.
6. No check on the result of each step. Gemini CLI kept moving files into a folder that didn't exist; the Mac and Antigravity cases were single wrong paths that nothing caught before they ran.

How to keep your agent out of the next roundup

• Give agents their own credentials, scoped to the task. No production keys on development machines, and none in .env, test or cached config.
• Block schema commands with --force, --force-reset, --accept-data-loss or a reset (prisma migrate reset, migrate:fresh, supabase db reset) for agents.
• Protect branches on the server and keep repository delete rights away from agent tokens.
• Keep production data and backups in a separate account or project, with deletion protection turned on.
• Test that you can restore from backup before you need to.
• Enforce rules outside the model: deny rules, a pre-command hook that blocks rm -rf, DROP, terraform destroy and volume deletes, and a sandbox for anything the agent runs on its own.
• Don't use "run everything" or skip-permission modes outside a disposable container or VM.
• Keep infrastructure changes plan-only for the agent. A person reads the plan and applies it.
• Log every command the agent runs, not just its output.

Most of this is generic hygiene, and it would have helped in every case above. The harder part is knowing, at the moment a command runs, what it would actually break: which database a test run will really connect to, which infrastructure a destroy touches, which other repos depend on what's changing. That's the problem VineScale is built to solve: a safety gate that knows a team's production systems and warns about or blocks an agent's action based on what it would break. The gate for Claude Code is in free beta, with beta support for Codex, Cursor, Antigravity and Grok Build.

Frequently asked questions

Has an AI coding agent ever deleted a production database?

Yes, many times. Publicly reported cases include Replit's agent deleting SaaStr's production database in July 2025, Claude Code running a Terraform destroy that removed a database with 2.5 years of records in February 2026, a Cursor agent deleting PocketOS's production database and its volume backups in April 2026, and several Claude Code reports of Prisma and Drizzle force flags wiping production databases on Railway in 2026.

Was the data recovered in these incidents?

Sometimes. Replit's rollback worked for SaaStr, AWS support restored the DataTalks.Club database in about 24 hours, Railway restored PocketOS's data, and a manual backup saved the Neon database. But the Drizzle case was unrecoverable, the Prisma cases lost data for good, and in the WSL2 home directory case the files could not be recovered.

Does telling the agent not to touch production work?

Not reliably. Replit's agent deleted data during a declared code freeze, and a Cursor agent ran rm -rf after being told "DO NOT RUN ANYTHING." Instructions help, but only permissions, hooks, sandboxes and scoped credentials enforce a rule.

Which commands do AI agents use when they delete a database?

In these reports: schema sync commands with force or reset flags (drizzle-kit push --force, prisma db push --force-reset, migrate:fresh), terraform destroy, a cloud API call that deleted a volume, and TRUNCATE or DELETE FROM inside a test or seed script. Most of them look routine; the damage came from the target.

Why do AI coding agents run destructive commands?

In these reports, usually while trying to fix something else: a credential mismatch, a cache to clear, duplicate resources to clean up. The agent picks a drastic fix and, if its credentials allow it, the fix runs. The damage comes from what the credentials can reach, not from the agent wanting to delete anything.

Is this a problem with one particular agent?

No. The cases involve Replit, Gemini CLI, Amazon Q, Claude Code, Cursor, Google Antigravity, Amazon Kiro and OpenAI's GPT-5.6. Claude Code appears often partly because its issue tracker is public and busy. The causes, production credentials in the wrong place, force flags, broad access, backups in the same place and rules that live only in a prompt, apply to every agent.

How do I stop an AI agent from deleting my production database?

Don't give it credentials that can. Use a read-only or staging role for the agent, keep production keys out of development machines and test config, turn on deletion protection, store backups separately, and block destructive commands and force flags with a hook. Our guide to stopping Claude Code from running destructive commands shows the setup step by step.