You had two hours of uncommitted edits in src/billing.ts — debug logging, a half-finished refactor, a TODO comment with your reasoning. You ran Claude Code on a “quick fix” task. The new diff replaced the whole file. Your edits are gone from the working tree, and you never committed them.
Fastest fix first: if the file was overwritten inside the still-open Claude Code session, run /rewind (or press Esc twice at an empty prompt), pick the first checkpoint of the session, and choose Restore code. Claude Code captures the state of every file before it edits it, so the pre-agent contents are usually still there. If that session is closed, jump to editor local history (Step 2) — it recovers most of the rest.
This is recoverable far more often than it feels. Claude Code keeps per-session checkpoints, editors keep local history, git keeps the reflog, and even a fully overwritten file often survives in an editor buffer, a swap file, or a backup snapshot. Below: how to recover in the next 10 minutes, then the layered “this won’t happen again” setup.
Which bucket are you in?
| Symptom | Most likely cause | Go to |
|---|---|---|
| Overwrite happened in the session that’s still open | Claude rewrote the file; checkpoint exists | Step 1 (/rewind) |
| Session closed, editor still open | Buffer / local history still holds your edits | Step 2-3 |
| Agent auto-committed after the overwrite | Commit captured post-overwrite state | Step 2 + Step 4 (reflog) |
| You stashed before switching branches | Stash on wrong branch or never popped | Step 4 (git stash list) |
| Two agents (or Claude + Cursor) edited the same file | Last writer won | Step 2, then Step 6 (worktrees) to prevent |
Common causes
Ordered by hit rate, highest first.
1. Working tree was dirty when the agent started
The agent’s Read of the file captured your dirty state, and its subsequent Write replaced the whole file with its own version of the edits. Your uncommitted changes never made it into the diff because the agent didn’t preserve them. This is far more common when the session is in acceptEdits mode (edits auto-apply without a prompt), which is also when you’re least likely to have noticed the full-file write.
How to spot it: look at the agent’s tool calls. If it used Write (not Edit) and replaced the whole file, your uncommitted edits were silently overwritten.
2. Multiple agents touched the same file in parallel
Two Claude Code sessions, or one Claude plus one Cursor, edit the same file. The later writer wins; the earlier writer’s changes vanish.
How to spot it: git log src/billing.ts shows nothing unusual, but the file content matches only one agent’s intent. The other agent’s work is gone.
3. Agent used a full-file write instead of an Edit/patch
For large changes, agents sometimes rewrite the whole file. Your inline debug logs sit inside the file Claude rewrote — they aren’t preserved unless Claude treated them as part of the task.
How to spot it: the diff shows the entire file changed (every line touched) rather than localized hunks. That’s a full rewrite.
4. You closed the editor buffer thinking the file was saved
Your edits were in an unsaved editor buffer. Closing or restarting the editor discarded the buffer, and the agent’s saved version is what’s on disk.
How to spot it: you don’t remember pressing Cmd+S before the agent ran. The change is missing from disk but may be in editor recovery.
5. Agent committed a “checkpoint” that included its overwrite
Claude was prompted to commit after the work. Its commit captured the post-overwrite state. Your edits never made it into git — but they may still be in a /rewind checkpoint or editor local history.
How to spot it: git log -1 --stat shows a recent agent commit, and your edits aren’t in any commit.
6. Stash was applied wrong or popped on a different branch
You stashed your edits, switched branches for the agent task, and the stash got popped onto the wrong branch — or never popped at all.
How to spot it: git stash list shows stashes you didn’t realize were still pending, or your branch is missing the changes you remember stashing.
Shortest path to fix
Ordered by urgency. Don’t close the Claude Code session or the editor until you’ve checked checkpoints and local history.
Step 1: Try Claude Code’s /rewind first (if the session is still open)
Since late 2025, Claude Code automatically checkpoints your code. As stated in the official checkpointing docs, it “captures the state of your code before each edit,” every prompt creates a checkpoint, and checkpoints persist across sessions and are cleaned up after 30 days. Because the agent edited the same file your uncommitted work lived in, that pre-edit content is usually inside the first checkpoint.
1. In the Claude Code session, run /rewind
(or press Esc twice when the prompt input is empty)
2. The menu lists every prompt you sent this session — pick the
point BEFORE the overwriting task
3. Choose "Restore code" (reverts files, keeps the conversation)
- "Restore code and conversation" also rolls the chat back
- "Restore conversation" keeps current code — NOT what you want hereTwo important limits, straight from the docs:
- Bash changes aren’t tracked. If Claude overwrote the file by running
mv,cp, or a redirect (> file) rather than its file-edit tool,/rewindcan’t undo it. Use Step 2-4. - External edits aren’t tracked unless they touched the same files the session edited. Your manual pre-agent edits to
src/billing.tsqualify only because Claude later edited that same file. A file you changed but Claude never touched won’t be in a checkpoint.
If /rewind shows the wrong content or the session is already closed, continue below. Checkpoints are local undo, not a substitute for git.
Step 2: Check editor local history
Every modern editor keeps file history independent of git, and this is the highest-yield recovery when the Claude session is gone:
VS Code / Cursor / Windsurf:
Right-click the file in Explorer -> Open Timeline
Or: View -> TimelineYou’ll see entries like “Saved 15 min ago” — click one to diff or restore. (VS Code’s Timeline aggregates the built-in Local History provider; entries persist even after the file is overwritten on disk.)
JetBrains (IntelliJ, WebStorm, PyCharm):
Right-click the file -> Local History -> Show HistorySublime Text: install the “Local History” package; there is no built-in equivalent.
This recovers the majority of “agent overwrote my edits” cases. Try it before anything destructive.
Step 3: Check the unsaved buffer with Cmd+Z
If the file is still open in the editor and you didn’t restart it, the buffer’s undo history may still hold your edits:
1. Open the affected file in your editor
2. Click in the file to focus the buffer
3. Press Cmd+Z (or Ctrl+Z) repeatedly — watch the diff revert toward your edits
4. Stop when your changes are restored
5. Save (Cmd+S) immediatelyIf Cmd+Z jumps past your edits, or the undo history was cleared by a reload, fall back to local history (Step 2).
Step 4: Check git reflog, stashes, and backup files
Even if your edits were never formally committed, a checkpoint commit or backup may exist:
# Find lost commits, including Claude Code's auto-commits
git reflog --all | head -30
# Find any stashes (across all branches)
git stash list
# Editor swap/backup files (vim, emacs) and merge backups
ls -la .*.sw[opq] 2>/dev/null
find . -name "*.orig" -o -name "*~" 2>/dev/nullIf a reflog entry has your edits, recover just that file without disturbing the rest of your tree:
git checkout <hash> -- src/billing.tsStep 5: If truly lost, rewrite and adopt commit-before-agent
If you’ve exhausted every recovery path, rewrite the edits, then institute the prevention so it never recurs:
# Pre-agent ritual
git status # confirm what's uncommitted
git add -A && git commit -m "wip" # checkpoint everything
# now run the agentA “wip” commit you’ll squash later is far cheaper than two hours of lost work.
Step 6: For multi-agent or parallel work, use git worktrees
If you frequently run agents while editing in parallel, give each its own working tree so writes can’t collide:
# Create a worktree on its own branch for agent work
git worktree add ../project-agent -b agent-task
# Or let Claude Code create/manage one for you:
claude -wNow edit in project/ and run the agent in project-agent/. Each has its own working tree, so an agent write can never clobber your manual edits. As of mid-2026, teams routinely run 4-8 concurrent worktrees per developer. When the agent finishes, merge its branch back on your schedule.
How to confirm it’s fixed
After recovering, verify before you keep working:
git diff src/billing.ts # your edits are back in the working tree
git status # confirm the file is staged/modified as expectedOpen the file and spot-check the markers you remember (the TODO comment, the debug log line). Then make a wip commit immediately so the recovered work is captured in git, not just on disk.
Prevention
-
“Commit before agent” is a hard rule. Never run an agent with a dirty working tree you care about.
-
For exploratory wip you don’t want to commit, use
git stashand verify afterward withgit stash list. -
Use git worktrees (or
claude -w) for parallel agent + manual editing — separate working trees can’t collide. -
Use Plan Mode for risky tasks. Start the session in the
planpermission mode (Shift+Tab to cycle modes, or--permission-mode plan); Claude explores and proposes a plan but does not edit source files until you approve. -
Protect specific files with a deny rule instead of just asking nicely in the prompt. In
.claude/settings.json, deny rules follow the gitignore spec and are enforced by Claude Code, not the model:\{ "permissions": \{ "deny": ["Edit(/src/billing.ts)"] \} \}Edit(...)rules cover all of Claude’s file-editing tools (and recognized Bash file commands likesed). For arbitrary scripts, pair this with a PreToolUse “block edits to protected files” hook or the OS sandbox. -
In agent prompts, also name files Claude must not touch: “do not edit
src/billing.ts; it has uncommitted work.” (This shapes intent but does not enforce a boundary — use a deny rule for that.) -
Enable editor auto-save with a short debounce so unsaved-buffer states are rare.
-
In
CLAUDE.md, ask Claude to preferEdit-style patches over full-fileWrites when the change is localized.
FAQ
Does /rewind undo changes the agent made by running shell commands?
No. Checkpointing only tracks files edited through Claude’s file-editing tools. Anything modified by a Bash command — rm, mv, cp, a redirect, or a script — is not captured and can’t be reverted by /rewind. Fall back to git reflog, local history, or backups.
My session is closed. Can I still use a checkpoint?
Checkpoints persist across sessions for 30 days, so resuming the same session (claude --resume) can bring the rewind menu back. But if the working tree has moved on since, restoring may overwrite newer work — diff first. When in doubt, recover from editor local history (Step 2) instead.
Why did Claude do a full-file Write instead of an Edit?
For large or structural changes, agents sometimes rewrite a file wholesale rather than patching hunks. That’s expected behavior, not a bug — but it’s why uncommitted edits inside that file get wiped if they weren’t part of the task. Committing first, or denying Edit on that path, prevents it.
Will committing first really stop this?
Yes. A clean commit means the worst case is git restore or git checkout back to that commit — your work is permanently in git history, not just the working tree. This is the single highest-leverage habit, and it’s why checkpoints “complement but don’t replace” version control.
The deny rule didn’t block the edit. What happened?
Check that the path anchor is right: /src/billing.ts is relative to the project root, while //src/billing.ts is an absolute filesystem path. Confirm the rule loaded with /permissions. Deny rules cover Claude’s built-in tools and recognized Bash file commands, but not a custom script that opens the file itself — use the sandbox for OS-level enforcement there.