Claude Code's /rewind is great — but it can't see Bash

Claude Code’s built-in checkpoints deserve the praise they get: after each turn, the tool automatically snapshots the files it modified, and /rewind (or Esc Esc) rolls code back to any earlier point. For “the AI edited my file and broke the build,” it is exactly the right tool — fast, zero-setup, built in.

But the same official documentation that describes checkpointing also draws its boundary — and the boundary is worth reading carefully.

What checkpoints track — and what they don’t

Per the docs, the automatic capture covers file changes made through Claude Code’s built-in file tools — Write, Edit, NotebookEdit — each time a response completes, with a rolling cap per session.

What sits outside that boundary:

• Bash-modified files. Commands the agent runs through the shell — rm -rf, cleanup scripts, build tools that rewrite files, package managers, database migrations — do not flow through Write/Edit and are not captured. This is not a corner case: essentially every headline AI-deletion incident went through a shell command, not an edit tool. The September 2026 incident where a Claude Code cleanup followed 614 Windows junctions and deleted 48,218 live files in 103 seconds was a shell cleanup, not an Edit-tool mishap.
• Subagent modifications. File changes made inside subagent contexts are likewise outside the capture path.
• Everything outside the working session. Checkpoints are session-scoped with a rolling cap. Files elsewhere on the machine — user directories, shared caches, datasets, other projects — were never in scope.

Why the blind spot is structural, not a bug

Platform checkpoints can only snapshot what the platform sees. A shell command is, by design, an opaque boundary: the platform can see the command string, not reliably what it will touch. Any tool in that position faces the same wall — which is why Cursor’s local history, Replit’s snapshots, and other harness rollbacks all make the same scoping trade-off. This is not a criticism of any of them; it is the shape of the problem.

The layered answer

The industry-standard answer to “the tool that caused the damage can’t fully undo it” is old: keep the undo mechanism outside the blast radius, at a layer the agent cannot touch.

That’s what volume-level snapshots are. A VSS shadow copy is a point-in-time view of the whole volume taken at the storage layer — file deletions (including those issued through Bash, through junctions, or against files outside any project) cannot reach into shadow storage. unlose (free, Apache-2.0, Windows) builds exactly this layer: it detects 26+ agents, snapshots automatically when they start working — and its memory-file directives can make agents request a snapshot before risky shell operations — then gives you a timeline to restore file-level or whole-volume, verified byte-for-byte in tests.

Practical setup (two minutes)

1. Keep checkpoints on — they’re the right tool for in-session edit mistakes.
2. Add a full-disk snapshot layer that runs outside the agent’s reach (on Windows: unlose, or manual wbadmin/disk-shadow discipline if you enjoy scripts).
3. If you run command interceptors (DCG and friends) — keep them too. Defense in depth: block what’s blockable, snapshot everything else.

The checkpoint is the seatbelt. The volume snapshot is the airbag. You want both, because the accidents that total the car never happen through the steering wheel you’re holding.