My AI agent deleted my code. Here is how to get it back.

The short answer

Stop touching the repo, then work through three checks in order: the reflog for lost commits, the working tree for deleted-but-tracked files, and git fsck for orphaned objects.

# 1. Was the work committed? Find it in the reflog.
git reflog

# 2. Were tracked files deleted but not committed? Restore them.
git restore .

# 3. Was staged work lost? Look for orphaned objects.
git fsck --lost-found

Which one applies depends on how far the agent got. The sections below explain each so you run the right one instead of guessing.

First: do no more harm

The single most damaging thing you can do right now is keep working. Do not let the agent continue. Do not run git gc, git commit, or another reset. Recovery relies on old objects still existing in .git, and every new operation can overwrite the working tree or prune what you need. If you can, copy the whole project folder somewhere safe before you start, so you always have the current state to fall back to.

Case 1: the agent committed then reset or rebased

This is the common one. The agent committed your work, then ran git reset --hard, a rebase, or a checkout that moved the branch, and the commits vanished from the log. The reflog still has them.

$ git reflog
4d3a1f8 HEAD@{0}: reset: moving to origin/main
9b7c4e2 HEAD@{1}: commit: implement invoice export
a1b2c3d HEAD@{2}: commit: add invoice model

# Confirm the commit holds your work
$ git show HEAD@{1}

# Rescue it into a branch you cannot lose
$ git branch rescue-work HEAD@{1}

From that rescue branch you can cherry-pick, merge, or reset your real branch onto it. There is a dedicated guide to the reset case linked at the bottom.

Case 2: the agent deleted tracked files but did not commit

If the files were part of the last commit and the agent only removed them from disk (or from the index), Git can rewrite them straight from the last commit. Nothing was lost because the committed version is intact.

# See what is deleted or modified
git status

# Restore a single file to its last committed state
git restore path/to/file.ts

# Or restore everything that was tracked
git restore .

# If the deletion was already staged, restore the index too
git restore --staged --worktree path/to/file.ts

On older Git versions the equivalent is git checkout -- path/to/file.ts. Both pull the file back from HEAD.

Case 3: staged work that was never committed

This is the hardest case, and the honest one to be clear about. If the agent edited files, staged them with git add, and then a hard reset or checkout wiped them before any commit, the content is not in the reflog because it was never a commit. But staging writes the file content into the object database as a loose blob, and git fsck can find those dangling blobs.

# List dangling and unreachable objects
git fsck --lost-found

# fsck writes dangling blobs to .git/lost-found/other/
# and dangling commits to .git/lost-found/commit/
# Inspect a candidate blob by its SHA
git show <blob-sha>

# When you find the right one, write it back to a file
git show <blob-sha> > recovered-file.ts

Dangling blobs have no filenames, so you may have to inspect several. It is tedious, but the content is often right there. If the work was only ever edited in the working tree and never staged or committed, Git never saw it, and no Git command can bring it back. That is the boundary worth knowing before you spend an hour searching.

Case 4: a deleted branch

If the agent deleted a whole branch, the commits are usually still reachable through your HEAD reflog, and you can recreate the branch at the last known SHA. That has its own walkthrough: how to recover a deleted Git branch.

The real fix: the agent should never have held the delete

Recovery is a fire drill. The better outcome is that the destructive command never runs unreviewed. Most agent setups give the model a shell and hope, which means a hallucinated rm -rf, a bad reset, or prompt injection from a malicious README becomes a real, immediate write to your repository. You find out afterward.

The alternative is a capability rule: the agent can read everything and propose a write, but it never holds the ability to execute one. A human sees the exact diff, the risk, and the restore point that will be captured, and approves or rejects before anything touches the repo. A delete you can see coming is a delete you can stop.