Recovering From a Cleanup Gone Wrong: Checkpoints, Bash, and Git
A developer, working in Accept Edits mode, asks Claude Code to "clean
up the src/utils/ folder — remove dead code and anything that's no
longer imported anywhere." Claude investigates, then:
- Uses Edit to remove a handful of unused functions from three files.
- Runs Bash:
rm -rf src/utils/legacyto delete an entire subdirectory it determined was unreferenced. - Reports the cleanup is done.
The developer later realizes src/utils/legacy actually contained a
script a teammate relies on for a quarterly data export, and it was
only "unreferenced" because nothing in the main codebase imports it —
it's invoked manually. The directory had never been committed to git
(it was added recently and is still untracked).
- Can the developer use
/rewind→ "Restore code" to bring backsrc/utils/legacy? Explain why or why not, tracing your answer to the specific mechanic of how checkpointing tracks changes. - Given that the directory was never committed, what are the developer's actual recovery options at this point, and how good are they realistically?
- What habit, if adopted before this session, would have prevented this from being a real loss — and why does it not require avoiding Accept Edits mode or distrusting Claude Code's cleanup ability?
1. Why /rewind can't bring back src/utils/legacy:
No — checkpointing only tracks changes made through Claude Code's own
file-editing tools (Edit and Write). The three functions removed with
Edit in step 1 are tracked and could be restored with /rewind →
"Restore code." But the deletion of src/utils/legacy happened via
Bash (rm -rf), and checkpointing explicitly does not track files
modified or removed by Bash commands — rm, mv, and cp are named
directly as untracked in how checkpointing works. From checkpointing's
point of view, that directory simply isn't part of any snapshot it
took; there is nothing for /rewind to restore it from, no matter which
restore option is picked.
2. Actual recovery options, realistically:
Because the directory was untracked in git — never added, never
committed — there is no git history to check out either;
git checkout, git reflog, and similar all operate on git's object
database, which never had a copy of these files to begin with. At this
point the realistic options are: check whether the developer's editor
or OS keeps its own local history/trash that might still have a stale
copy (not guaranteed, and typically short-lived); check whether the
teammate who relies on the script has their own local copy or a copy
on another machine; or, in the worst case, accept the files are gone
and reconstruct the script from memory or from wherever the teammate
originally got it. None of these are as reliable as a real version-
control recovery — this is a case where the loss is likely permanent
or at least costly to reverse, which is precisely the scenario the
"checkpoints are not a replacement for git" limitation warns about.
3. The habit that would have prevented this:
Committing new, untracked files to git — even on a scratch branch,
even before they're "finished" — as a matter of routine, rather than
only committing once work feels complete. Had src/utils/legacy been
committed (even in an early, rough state) before this session, rm -rf
would still have deleted it from the working directory, but git checkout or git reflog would have been able to bring it straight
back, regardless of what checkpointing did or didn't track. This
doesn't require avoiding Accept Edits mode or distrusting Claude's
judgment about what's safe to clean up — Accept Edits controls how
often Claude stops to ask before acting, and checkpointing is a
session-level convenience layered on top of that; neither is a
substitute for git actually holding a copy of your files. The fix is
squarely a version-control habit, independent of which permission mode
or which safety net you're relying on for any given task.
Share this question