Your agent's rewind does not fully cover the shell

Coding agents now come with a rewind. In Claude Code you can press Escape twice, or run /rewind, pick an earlier point in the conversation, and roll the code back. It feels like a time machine. For a lot of mistakes, it is enough.

But look closely at what it tracks. Claude Code's checkpoints record edits made through its own file editing tools. Its documentation says plainly: "A file that only Bash commands changed isn't tracked and stays as it is." If the agent runs rm, mv, cp, a migration, a code generator or git reset in the shell on files it never edited, the rewind does not know it happened. Eon wrote up this gap in detail.

That matters, because the shell is where agents make their biggest moves.

Where the big changes happen

An edit tool changes one file at a time, with a diff you can read. A shell command can change a thousand files in one line. Think about what an agent runs on a normal day:

• npm install, which rewrites the lockfile and node_modules
• a formatter or a linter with --fix, across the whole project
• rm -rf on a build folder, or on a folder it thinks is a build folder
• git checkout, git reset --hard or git clean -f
• a database migration or a seed script

None of these is an edit tool call. Every one of them can break a project that worked a minute ago.

Public incidents show the pattern. A Cursor user reported that an agent permanently deleted a production resource folder. A Gemini CLI user lost files while the agent tried to reorganize them. Replit's agent wiped a production database during a code freeze. These were not typos in one file. They were commands.

Undo is not the same as a way back

Editor undo goes back one edit. An agent rewind goes back through the agent's own edits. Git goes back to a commit, if you made one. Each of these answers the question "what did the files look like?"

None of them answers the question you actually have after a bad session: which version still works?

That second question is harder than it sounds. You might have six candidate states. Some broke at the edit you can see. Some broke because of a dependency the agent added three steps later. Checking each one by hand, in your real folder, is slow. It also puts the state you are in right now at risk.

What Time Machine does instead

Time Machine does not try to watch every file write. It saves the whole project at the moments that matter, stores it outside the project, and then checks the result.

With the Claude Code hooks installed, using tm hook install, it saves:

• before each prompt, if anything changed
• before risky shell commands, like rm -rf, git reset --hard, git clean -f, DROP TABLE and similar
• at the end of each turn, and then it runs your check

If the check passed before and fails now, the hook tells Claude which save point last worked. The agent hears it in the same session, while the context is still fresh.

A save point holds your code, including uncommitted changes, files not in Git yet, config key names, and dependency and environment fingerprints. It lives in ~/.timemachine with a Git bundle, so an rm -rf on the project does not take the save points with it.

When something breaks, tm find-good rebuilds save points in a separate Git worktree, newest first, and runs your check on each one until one passes:

$ tm find-good
  cp-0006   FAIL       The check failed with exit code 1.
  cp-0005   FAIL       The check failed with exit code 1.
  cp-0004   FAIL       The check failed with exit code 1.
  cp-0003   PASS       The check passed.
PASS  cp-0003 is the newest version that works.

Then tm recover cp-0003 puts that version on a new branch, tm/recover/cp-0003, with a recovery copy next to your project. Your folder and current branch are not touched. Nothing is pushed, merged or deployed.

What it still cannot do

A save point covers your project folder. It does not cover a database the migration changed, a deploy that already went out, or an email that was sent. The Replit case would still need a database backup. Time Machine says so on every save point and every recovery report, under "Not restored".

It also never stores the values in config files like .env, only key names. After a recovery you set keys like STRIPE_SECRET_KEY again by hand, and the report lists each one.

The short version

Use your agent's rewind. It is good at what it covers. But know where it stops. If your agent can run shell commands, you want a save point the shell cannot reach, and a check that tells you which one works.

Sources

1. Eon: Claude Code rewind and Bash changes
2. Anthropic: Claude Code checkpointing documentation
3. Cursor forum: agent permanently deleted entire production resource folder
4. AI Incident Database: Gemini CLI deleted a user's files
5. Fortune: AI coding tool Replit wiped a database and called it a catastrophic failure