Why AI coding agents need an undo button for the whole machine

01What have coding agents actually deleted?

This is not hypothetical. Three publicly reported cases from 2025 show the range of what goes wrong when an agent has a shell and real data within reach.

In July 2025, SaaStr founder Jason Lemkin was running a public experiment with Replit's agent. Fortune reported that during a declared code freeze the agent deleted a live production database holding records for more than 1,200 executives and over 1,190 companies. The agent first told him a rollback would not work. Ars Technica later quoted Lemkin saying the rollback did work after all. Replit's CEO Amjad Masad called the deletion unacceptable and announced automatic separation of development and production databases, improved rollback and a planning-only mode.

The same month, a user asked Google's Gemini CLI to rename a folder and move its contents (GitHub issue 4586, Gemini CLI v0.1.13 on Windows). Ars Technica's reconstruction: the agent's mkdir apparently failed, the agent carried on as if it had worked, and it ran move commands into a directory that did not exist. On Windows that renames each file to the destination name, so every move overwrote the one before.

In October 2025, a Claude Code user on WSL2 filed GitHub issue 10077 reporting that the agent ran a recursive delete starting at the root of the filesystem. System files survived only because the user lacked permission to remove them. Everything the user owned, including project directories, was gone before they could interrupt it.

02The pattern: one wrong command, outside anything versioned

None of these needed an attacker. Each was an ordinary task where the agent misread its own state: a failed mkdir, a delete aimed at the wrong path, a production database sitting next to the development one. Agents also report their own results with confidence, so the first account of what happened can be wrong, as the Replit rollback episode showed.

The common thread is blast radius. The agent could reach more than the task needed, and nothing captured the state before the destructive step. Approval prompts help, but an agent that asks before every command quickly trains people to click yes, and that is the problem an undo point solves differently.

03What does git not cover?

Git is the first answer most engineers give, and it is a good answer for committed source code. It was never meant to snapshot a working machine. The git documentation itself spells out the edges.

git stash by default records tracked changes only; untracked files need --include-untracked, and ignored files need --all. git clean -x removes ignored files along with untracked ones, which is exactly the class of files that hold local secrets and data. Tool-level checkpoints have edges too: Claude Code's checkpointing docs say a file changed only by Bash commands is not tracked, and point you to version control for those.

• Uncommitted and untracked work: anything the agent wrote or you edited since the last commit.
• Ignored files: .env, local SQLite or Postgres data directories, caches, build output, downloaded models.
• Everything outside the repository: your home folder, other projects, SSH and cloud config.
• The repository itself: a deleted .git directory or a force-pushed branch takes the history with it.
• Running state: a dev database with open connections, a half-applied migration, a long build, a server mid-request.

04How does a whole-machine checkpoint work?

Run the agent inside a virtual machine and snapshot the machine, not the files. A checkpoint captures the disk, typically as a copy-on-write clone so it is cheap, plus the guest's memory and CPU state. A rewind restores both, so processes resume exactly where they were: the database still holds its connections, the dev server is still listening, the shell history is intact.

Because the snapshot covers the whole guest, it does not matter whether the damage came from a file-edit tool, a shell command, a package install script or a subagent. Anything inside the machine goes back. That is the property git and per-tool checkpoints cannot give you.

A few design choices decide whether this is usable. Checkpoints must be fast, or nobody takes them before risky steps. They need labels, because the reason for a restore point is the useful half of the record. They need a limit, because an agent that checkpoints every step will fill the disk. And a rewind should discard later checkpoints, since they describe a future that no longer happened.

05What a machine snapshot cannot undo

A snapshot reaches only state inside the machine. The Replit database lived on a hosted service; a VM checkpoint on a laptop would not have brought it back. Pushed commits, sent emails, API calls, cloud resources and rows in a remote production database are outside it.

So the undo button works best paired with two other controls: a closed network with an allow-list, so the agent cannot reach production in the first place, and human approval for the few actions that leave the machine and matter. Keep separate credentials and databases for development and production, which is the same lesson Replit drew. And rewinding is itself destructive, so take a fresh checkpoint first if you might want the current state back.