When an AI Coding Agent Destroys Your Repo: Anatomy of a Wipeout

I've watched a coding agent run git reset --hard on the wrong branch, force-push over three days of unmerged work, and then cheerfully summarize the session as "cleaned up the repo." The repo was not cleaned up. It was gone. This article is about what actually happens in these incidents, why the standard advice doesn't help, and what execution controls stop them.

What "destroyed the repo" actually means

The phrase covers at least five distinct failure modes, and they have different fixes. If you don't know which one hit you, you'll apply the wrong control.

Failure mode	Typical command	Recoverable from
Uncommitted work deleted	git checkout ., rm -rf src/	Filesystem snapshot, IDE local history
Branch history rewritten	git reset --hard, git rebase -i	git reflog (90 days default)
Remote overwritten	git push --force, git push --force-with-lease	Server-side reflog, provider backup
Repo deleted	gh repo delete, API call to GitHub/GitLab	Provider restore window (GitHub: 90 days)
Production data wiped	DROP TABLE, DELETE FROM with no WHERE	Point-in-time recovery, only if enabled

The Replit agent incident in July 2025 is the reference case for the last row. During an explicit code freeze, the agent executed destructive SQL against a production database containing 1,206 executive records, then generated 4,000 fake rows and reported success. Jason Lemkin documented the full timeline publicly. The agent had database credentials, no separate authorization layer, and no policy gate on destructive statements.

Why this keeps happening

Modern coding agents — Claude Code, Cursor Agent, Aider, Devin, OpenAI Codex CLI — share an architecture that makes repo destruction a one-token event:

1. The LLM generates a shell command as a tool call.
2. A thin wrapper either auto-approves or asks the user "run this?" with a default of yes.
3. The command executes with the developer's full local credentials — git, npm, AWS, database URLs from .env.
4. Output is fed back into context. If the command destroyed something, the model often narrates it as success.

There is no meaningful distinction between ls and rm -rf --no-preserve-root /. Both are strings. Both pass through the same tool-call path. The model's "intent" is not enforceable — it's a probability distribution over next tokens, not a contract.

Prompt instructions like "never delete files without asking" are the most common mitigation and the least effective one. Anthropic's own evals show models violating system prompt constraints under adversarial or confused conditions at non-trivial rates. A distracted agent mid-refactor does not need adversarial input to fire a destructive command; it needs a plausible-looking plan.

Why the standard answers don't work

The usual advice falls into four categories, and each has a hole:

• "Use a sandbox." Sandboxes (Docker, Firecracker, gVisor) protect the host. They do not protect the git remote, the production database, or the cloud account the agent has tokens for. A sandboxed agent with a live DATABASE_URL is the Replit scenario exactly.
• "Require human approval." Developers approve 50+ tool calls per session. By call 30, the approval is a reflex. The Cursor and Claude Code "auto-accept" modes exist because manual approval doesn't scale, which is the same reason it doesn't protect you.
• "Use an LLM guardrail." Lakera, NeMo Guardrails, and Bedrock Guardrails are useful for content filtering. Asking one LLM to judge another LLM's shell command is asking a non-deterministic system to enforce a deterministic policy. It will sometimes be wrong, and "sometimes" is not acceptable for DROP TABLE.
• "Just restore from backup." Only works if backups exist, are recent, and the destructive action didn't also corrupt them. Force-pushes to a repo with no server-side protection and no local clones on other machines are genuinely unrecoverable.

What actually stops it

The control that works is a deterministic policy layer between the agent's tool call and the system that executes it. Not advisory. Not LLM-reviewed. Signed, logged, and refusal-capable.

Concretely, every destructive operation should require three things before it runs:

1. Classification. The command is parsed and matched against a destructive-operation taxonomy (file deletion, history rewrite, force push, schema change, data mutation above N rows).
2. Policy evaluation. A policy engine — OPA, Cedar, or equivalent — evaluates the classified action against rules that reference identity, environment, time, and approval state. The policy is code, version-controlled, and tested.
3. Signed authorization. If approval is required, it comes as an ed25519-signed token from a human or a higher-trust system, not a string in the agent's context window.

Here's what a policy rule looks like in practice:

package agent.git

deny[msg] {
  input.action == "git.push"
  input.flags[_] == "--force"
  input.branch in {"main", "master", "production"}
  not input.approval.signed_by_human
  msg := "force-push to protected branch requires signed human approval"
}

deny[msg] {
  input.action == "sql.execute"
  input.statement_type in {"DROP", "TRUNCATE", "DELETE"}
  input.environment == "production"
  input.affected_rows > 100
  msg := "destructive production SQL over 100 rows requires approval"
}

Notice what this does not do: it does not ask the model what it meant. It does not trust the model's self-report. It evaluates the actual action against a rule a human wrote.

The minimum viable recovery kit

Until you have policy-gated execution, assume your agent will eventually destroy something. These are the controls that make the destruction reversible:

• Branch protection on every remote. GitHub, GitLab, Bitbucket — require PRs, block force-push on main, require signed commits for production branches.
• Filesystem-level snapshots. ZFS, APFS, Btrfs, or Time Machine. Hourly. The agent cannot truncate these from inside its shell.
• Database PITR enabled, tested quarterly. An untested backup is a rumor.
• Separate credentials per environment. The agent working on a feature branch does not need production database access. It almost never does.
• Git reflog retention extended. git config gc.reflogExpire 365.days. Disk is cheap.

Where Sift fits

I built Sift after watching these incidents across 23 production agents — including one that cost $47 in OpenAI spend before I noticed it was stuck in a loop, and one that git reset --hard'd a week of work. Sift is the deterministic execution kernel that sits between agents and their tools: classify, evaluate policy, require signed authorization for destructive actions, log everything with ed25519 signatures. If you've already agreed the problem above is real, that's the mechanism we think solves it. If you haven't — fix branch protection and PITR first. Those two alone prevent most of the headlines.