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

The short answer

If an AI coding agent deleted code, stop the agent, close tools that may auto-save and copy the entire project folder, including the hidden .git directory, to a separate location. Do not begin with git restore .: it can replace unrelated tracked edits across the working tree. In the preserved copy, use git status --short to classify deleted, modified, staged and untracked paths. If a commit or branch moved, inspect git reflog --all and rescue the correct commit onto a new branch. If a tracked file was deleted, restore only that named path after reviewing its diff. If content was staged but never committed, inspect dangling objects with git fsck. Git cannot recover a file that was never committed, staged or otherwise written to its object database; check IDE local history, filesystem snapshots and backups for that case. If .git was also deleted, preserve the disk state and recover the repository from a remote or backup.

# Inspect first. These commands do not restore or overwrite files.
git status --short
git diff
git diff --cached
git reflog --all --date=iso

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 a new operation can overwrite the working tree or prune what you need. Copy the whole project folder, including hidden files, somewhere safe before you start. Work only on the copy and keep the original frozen.

Choose the recovery path from the state

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 restore the committed version of a named path. Inspect the path first so you do not erase a separate tracked edit.

# See what is deleted or modified
git status --short

# Review what restoring this path would replace
git diff -- path/to/file.ts

# Restore a single file to its last committed state
git restore --source=HEAD --worktree -- path/to/file.ts

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

The -- separates options from the path. Repeat this only for paths you verified. Avoid a repository-wide restore during triage: Git documents that restore replaces working-tree content from its selected source, so a broad pathspec can overwrite valid edits as well as recover deletions.

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.

Primary Git references

This procedure follows the official Git manuals for status inspection, reference logs, path-scoped restore and object recovery with fsck. Read the manual for your installed Git version before adapting a command to a repository with submodules, sparse checkout or an unfinished merge.

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 inside the Git integration: the agent can inspect and propose a write, but FluxGit exposes no direct Git mutation tool. A human sees an operation-specific preview, risk and available recovery context, then approves or rejects before FluxGit runs it. A separate shell granted by the agent host remains outside this boundary.