Your coding agent ran git reset --hard. What you can get back

You asked your agent to "clean up the branch" or "start again from main", and it did: git reset --hard, git checkout -- ., or git branch -D. Now the change you spent the morning on is not in your files.

Before you rewrite it, check what git kept. Git stores every file it has ever been handed, even after nothing points at it any more, and keeps a log of where each branch has been. Some of your work is almost certainly still there. Some of it is not, and it helps to know which is which before you start digging.

We tested every command below on git 2.43 in a scratch repo, with the same kinds of mistakes an agent makes.

What survives and what doesn't#

We set up a repo with four kinds of work, then ran git reset --hard:

app.js      changed, then git add          (staged)
notes.md    changed, never added           (unstaged)
new.js      a new file, never added        (untracked)
two commits made after the last push       (committed)

After the reset:

• Committed work: always back. Commits stay in the repo for weeks after nothing points at them (30 days by default while they're in the reflog).
• Staged work: back, without its file name. git add stores the file's contents in the repo the moment you run it, and a reset doesn't delete them.
• Untracked files: untouched. git reset --hard leaves files git never knew about. git clean -fd deletes them, and then git can't help.
• Unstaged edits to tracked files: gone. Git never stored them. Look for an undo in your editor or a backup instead.

So the order to check is: reflog for commits, then lost blobs for staged files, then your editor.

Commits: the reflog#

Every time HEAD moves (a commit, a checkout, a reset), git writes a line in the reflog. Our agent reset two commits away:

git reset --hard HEAD~2
git reflog -5

829b090 HEAD@{0}: reset: moving to HEAD~2
70033f2 HEAD@{1}: commit: feature part 2
85a264b HEAD@{2}: commit: feature part 1
829b090 HEAD@{3}: reset: moving to HEAD
829b090 HEAD@{4}: commit (initial): init

The line before the reset is the state you want. Put a branch on it instead of resetting again, so nothing else moves:

git branch rescue HEAD@{1}
git log --oneline rescue

70033f2 feature part 2
85a264b feature part 1
829b090 init

Then look it over and merge or reset to rescue when you're sure.

A deleted branch#

git branch -D prints the last commit as it deletes the branch, so first scroll up in the agent's output:

Deleted branch feature (was e1a3cc4).

git branch feature e1a3cc4 brings it back. If the output is gone, the reflog still has the last commit you made on it:

git reflog | grep -m2 -E "feature|checkout"

829b090 HEAD@{0}: checkout: moving from feature to main
e1a3cc4 HEAD@{1}: commit: feature work

Staged files: lost blobs#

If the work was staged but never committed, it is in the repo as a "dangling blob": file contents with no name attached. Ask git to write them all out:

git fsck --lost-found

dangling blob 64fbbfe7f71842eba5ffa470a859ed5c9fe9d7ff

Each one is now a file in .git/lost-found/other/, named by its hash. There can be dozens, so search them for a line you remember from your change:

grep -l "function rate" .git/lost-found/other/*
git show a01fd8b4e67a033b248e0b69720a49fa187caae9 > rate.js

You get the contents back, but not the file name or folder, so you put it in place yourself.

A dropped stash#

Agents sometimes run git stash to get a clean tree, then git stash drop or git stash clear. A stash is a commit, so it shows up as a dangling commit:

git fsck --no-reflogs | grep "dangling commit"
git log -1 --format='%h %s' 046508e

046508e WIP on main: 829b090 init

git stash apply 046508e puts it back.

Agent checkpoints don't cover git#

Claude Code can rewind its own edits (/rewind, or Esc twice), but its checkpoints track changes made with its file edit tool, not what a shell command did. A git reset --hard that the agent ran through Bash is outside them, and so is anything you changed yourself. Treat checkpoints as an undo for the last few edits, not a backup.

Stop it happening again#

The cheapest fix is to give git a copy before you hand over a risky job:

• Commit or stage before a big request. git add -A is enough: staged contents survive a reset, as shown above. A wip: commit on a branch is better, because it keeps file names.
• Work on a branch, not main. Then "start again from main" means switching branches, not resetting yours.
• Ask for the plan first. "Tell me the git commands you'll run before running any" turns a surprise reset into a question you can answer.
• Block the commands that destroy work. A hook can stop git reset --hard, git checkout -- ., git clean -f and git branch -D and tell the agent to ask you instead. The same approach that stops commits on main works here; add these commands to the list it checks.

Where Joxo fits#

When a teammate's agent and yours share a project, a reset on one machine is easy to miss. Joxo shows you what every agent on the project is doing and asks you on your phone before the steps you've marked as needing you. Setup is one line pasted into your agent.

Frequently asked questions#

Can I undo git reset --hard?#

Committed work, yes: find the commit with git reflog and put a branch on it. Staged files come back with git fsck --lost-found. Unstaged edits to tracked files were never stored by git and can't be recovered from it.

How long does git keep commits that no branch points to?#

A commit that only the reflog still points to is kept for 30 days by default. Other loose objects, like staged files, are kept for about two weeks, until git gc prunes them. Recover early and don't run git gc while you're looking.

Does git clean delete files for good?#

Yes. git clean -f removes untracked files from the disk, and git never stored them, so look in your editor's local history or a backup.

Can a coding agent recover the work itself?#

Yes, if you give it the commands. Ask it to run git reflog and git fsck --lost-found, show you what it found, and wait before it resets or overwrites anything.