Claude Code's /rewind Won't Bring Back What Bash Deleted

Disclosure: I work at Eon, on the content side, and we sell cloud data protection, which is what the last two sections are about. Everything before them is Anthropic's and Huawei's own docs, four open-source READMEs and three public GitHub issues, all linked.

What Claude Code checkpointing tracks, and the 5 things it skips

As of September 14, 2026, the checkpointing page at code.claude.com says Claude Code captures a checkpoint before each user prompt and tracks changes made through its file editing tools. The Agent SDK page names them: Write, Edit, and NotebookEdit. /rewind (or Esc twice on an empty prompt) restores code, conversation, or both, from the 100 most recent checkpoints in a session.

The limitations section is short and worth reading in full. Its first line: "Checkpointing does not track files modified by bash commands." The docs list these examples:

rm file.txt
mv old.txt new.txt
cp source.txt dest.txt

The SDK page adds echo > file.txt and sed -i. Redirects, in-place edits, moves, and any script the agent wrote 30 seconds earlier all sit outside the checkpoint.

Four more limits follow. Rewind doesn't restore edits made by subagents, and the docs point you to git for those. A restore skips symlinked and hard-linked files and prints Restored the code, but skipped N files. It doesn't track edits made outside the session, by hand or by another process. And the snapshots expire: a retention sweep deletes a session's file snapshots about 30 days after the last save, after which rewinding to one of them fails with No files were restored.

The page ends on a heading Anthropic wrote itself: checkpoints are not a replacement for version control.

Try it in 60 seconds

In a scratch repo:

1. Ask Claude Code to create a.txt with its editor.
2. Ask it to create b.txt through the shell:

echo hi > b.txt

1. Ask it to add a line to each, the same way it created them.
2. Run /rewind and restore to the first checkpoint.

Per the docs, a.txt comes back, and b.txt stays exactly as the shell left it.

Where /rewind is the right tool

The limits don't make checkpointing useless. Most of what a coding agent does, most of the time, is edit source files through its own tools, and every one of those edits is restorable in a keystroke. For a refactor that went sideways, or a failing test the agent "fixed" by deleting the assertion, /rewind is the right tool and a good one.

"Just use git" doesn't cover it either. Git holds committed state, untracked files vanish under git clean, and the agent has the same shell you do, so git checkout . is one tool call away. (git-safepoint exists for exactly that reason.)

What falls outside the checkpoint is a short list of commands, and most of them delete or overwrite files. An agent that decides a directory is stale runs rm -rf, and a migration runs through a shell; neither goes anywhere near the Edit tool. Both can remove data that nothing else on the machine recorded.

4 open-source tools that cover the bash channel

Engineers hit this often enough that 4 open-source projects now exist to cover it.

• bashward (Rust, v0.1.1) hooks Claude Code's PreToolUse event for the Bash tool and parses each command. Before it runs, bashward snapshots the paths that rm, mv, cp, dd, sed -i and shell redirects are about to touch, using APFS clones on macOS.
• git-safepoint (Python, v0.0.1, June 23, 2026) captures tracked and untracked files before every destructive command using git plumbing, so you can restore a single file without touching HEAD.
• stepback (PyPI, v0.1.2) wraps any agent, watches the filesystem instead of one tool's hooks, and can rewind the agent's on-disk conversation transcript along with the files.
• doover (Rust, v0.2.3, September 2026) journals every shell action, classifies commands against a registry of 152 reversibility rules, and snapshots affected paths anywhere on disk, including outside the project.

All four are pre-1.0, and git-safepoint is at v0.0.1, so try them in a scratch repo before you put one in front of work you can't lose.

The ask reached Anthropic directly too. On January 9, 2026, a user opened issue #16976 on the Claude Code repository, asking Anthropic to expose checkpoint restore programmatically and calling the current feature "effectively UI-only." Its status: closed as not planned.

The patch tools are candid about their own ceiling. Doover's README has a section titled "What doover is not" that flags DROP TABLE, kubectl delete and force-pushes as unrecoverable, because no local snapshot can bring back remote state. By default, it keeps 7 days and 5 GiB of history on the same disk as the files it protects. The README's advice on that point comes down to 3 words: "Keep real backups."

Nor is the limit Anthropic's alone. Huawei's CodeArts Agent documentation (updated July 29, 2026) draws the same line. Checkpoints there don't track file changes made through bash commands or external editors, and they expire after 15 days. Two vendors document the same limit, for the same architectural reason. A checkpoint is a copy of the files the agent's own tools touched. It can't see what a shell did.

When the checkpoint restore itself deletes files

The sharpest version of the problem is a report where the undo did the damage. On February 25, 2026, a user of GitHub's Copilot CLI filed issue #1675 about what happened when they chose "restore to checkpoint." Per the report, the rollback ran git clean -fd on the repository root and deleted roughly a gigabyte of untracked evaluation output that no checkpoint had ever covered. It remains open as of September 9, 2026. It is a single user's account, with no confirmed root cause from GitHub in the public thread, and the mechanism is the same. The restore was itself a shell command, and nothing was checkpointing the shell.

A related bug report on the Claude Code repository (#34368, March 14, 2026) describes the rewind option appearing on a turn where the agent had deleted a file. Selecting it did nothing to restore the file. Read it as a UI question, not a scandal. The docs say the code-restore options appear only when a checkpoint has tracked changes to revert, and a checkpoint can have tracked edits without holding the file you want back.

Checkpoint vs recovery copy, side by side

A checkpoint answers one question: what did the agent change in my working tree since the last prompt. A recovery copy of a database or bucket (what most teams still call a backup) answers a different one: what did this row, object, or file look like at 02:13, before the agent's UPDATE ran. The first lives on the agent's machine for a bounded time. The second lives in a separate account under separate credentials, and you restore it to a point in time, regardless of which tool or person made the change.

Layer	File-tool edits	Shell changes	Rows and objects	Undo window
Claude Code checkpoints	Yes	No	No	Last 100 checkpoints
Huawei CodeArts checkpoints	Yes	No	No	15 days
git	Committed only	Committed only	No	Until history is rewritten
Shell-hook tools	Varies by tool	Yes, local disk	No	Bounded, same disk
Recovery copies, separate account	Not the job	Not the job	Yes	Set by retention policy

Two notes on that table. Claude Code's snapshots get swept about 30 days after the last save (docs read September 14, 2026), and Huawei's expire at 15 days (docs updated July 29, 2026). Git protects committed state only, and the agent can run git clean or git checkout . itself. Doover flags row and object operations as unrecoverable outright, and defaults to 7 days and 5 GiB on the same disk as the files it protects.

The same shell reaches your production database

On a developer machine, the worst outcome is a lost afternoon. The same shell channel the checkpoint can't see is also how an agent reaches everything that isn't a source file: psql, aws s3 rm, a migration script, kubectl. Anthropic's March 25, 2026 engineering post on auto mode lists, from its own internal incident log, an agent "attempting migrations against a production database." The only thing that changes is what the command can reach.

Managed databases add a twist. A nightly snapshot tells you what the table looked like at 02:00. It doesn't tell you which rows the agent touched at 02:14, or which writes since then were legitimate. And if the recovery copies sit in the same account, and the agent's credentials can delete them, they inherit the agent's mistakes. Eon's August 5, 2026 post on agent-driven data loss walks through the public incidents where they did.

What a real undo has to do at the data layer

Set the bar for an undo the way you'd set it for a restore, because it is one. It records the data state at the moment of the operation, so nobody has to reconstruct it from logs afterward. Only what changed comes back: a file, an object, or a row, in place (the rest of the system never notices). The copy lives outside the credentials that made the change, and the restore finishes in minutes.

Checkpoints in coding agents were never built for that, and their docs say so. Before the next agent session:

• Start from a clean commit, ideally in a fresh worktree or container, so rm -rf has a small blast radius.
• Put a shell hook in front of the Bash tool (bashward or doover), and treat it as local-disk protection only.
• Give the agent its own database credentials, so the database's own logs name the agent and not you when something needs unwinding.
• Time how long it takes to get 1 row back from your managed database's recovery copies. If the answer is "restore the instance to a side environment and export," write that number down.
• Keep recovery copies in a separate account, with credentials the agent never holds.

(Eon, where I work, sells the last two as a managed service. Recovery copies land in isolated vaults, logically air-gapped and immutable, held in a separate account from your production environment, so they sit outside the blast radius of compromised production credentials. A restore comes back at the level of a single file, object or row, in minutes. You can build the same property without us. Replicate into an account whose credentials your production roles and your agents never hold. Turn on S3 Object Lock in compliance mode, or an AWS Backup vault lock, so the copies stay immutable for the retention period. Give the agent its own database user. Then rehearse one restore, so the recovery time is a number you have measured.)

Frequently asked questions

Can Claude Code's /rewind undo bash commands?

No. Anthropic's checkpointing documentation (read September 14, 2026) states that checkpointing does not track files modified by bash commands, with rm, mv, and cp as the listed examples. Rewind restores only edits made through Claude Code's file editing tools.

What does Claude Code checkpointing not track?

Files changed by bash commands, edits made by subagents, and edits made outside the session by hand or by another process. A restore also skips symlinked and hard-linked files, and file snapshots expire about 30 days after the session last saved one.

How do you undo changes an AI agent made outside the editor?

Open-source shell-hook tools snapshot files before destructive commands run: bashward and doover hook Claude Code's PreToolUse event, git-safepoint uses git plumbing to capture untracked files, and stepback watches the filesystem for any agent. All of them work on the local disk only.

Can you recover data an AI agent deleted from a database?

Only from a recovery copy of the database that lives outside the agent's credentials. Coding-agent checkpoints cover files on the agent's machine, and shell-hook tools such as doover flag DROP TABLE and other remote operations as unrecoverable.

What is the difference between agent checkpointing and a backup?

A checkpoint is a bounded, same-machine copy of files an agent's own tools edited during a session. A backup, or recovery copy, is a copy of the data itself, held in a separate account under separate credentials. You can restore it to a point in time, regardless of which tool or person made the change.

---

We're running a hands-on version of this on October 8 in New York, 4 to 7pm at LOFT39. You break an environment with an agent, then recover it, in a sandbox you don't have to clean up afterwards. Details are on the workshop page.

I'll answer what I can in the comments. If you're running one of these four on something real, I'd rather hear how the retention defaults held up than hear that they work, and if the 60-second test behaves differently on your setup than the docs describe, say so and I'll correct the post.