Recovering When the Agent Trashed Your Repo

An agent went off-script, broke your build, and committed garbage. Learn the systematic recovery workflow — git, sanity checks, and the cultural habits that make recovery fast.

11 min · Reviewed 2026

First: Don't Panic

An agent has just made 47 edits across 12 files, run `git push --force` to your branch, and now nothing builds. This will happen to you at least once. Here is the recovery procedure that turns a five-hour disaster into a fifteen-minute lesson.

Stop everything (literally)

Hit Ctrl+C in the agent's terminal — interrupt any running command
Close the agent session (don't continue the conversation)
Note the time — useful for git reflog later
Do NOT pull, fetch, or check out anything yet — preserve current state for inspection

Inventory the damage

# What changed in the working tree (uncommitted)
git status --short

# What got committed during the session
git log --oneline -20

# What got pushed (if remote was touched)
git log origin/main..HEAD --oneline

# Files modified, sorted by churn
git diff --stat HEAD~10..HEAD | sort -k3 -n -r | head -20

# Reflog — the safety net for everything git
git reflog --date=iso | head -30Five commands that paint a complete picture before you touch anything.

git reflog is your time machine

Even if the agent ran `reset --hard`, `rebase`, or `push --force`, git reflog has the previous state for at least 30 days. Every commit your repo has ever pointed at is recoverable — as long as you don't run `git gc --prune=now` first.

# Find the commit hash from before the agent disaster
git reflog
# 7a3f2c8 HEAD@{0}: reset: moving to HEAD~5
# b9c1d4e HEAD@{1}: commit: agent: refactor everything (this is the chaos)
# 4f5a6b7 HEAD@{2}: checkout: moving from main to feature  <-- known good

# Recover to known good in a new branch (safer than overwriting)
git branch recovery 4f5a6b7
git checkout recovery

# Or, if you're sure: reset main
git checkout main
git reset --hard 4f5a6b7Reflog references survive reset, rebase, and force-push. They are the most underrated git feature.

Triage by blast radius

Scope	What it touched	Action
Working tree only	Uncommitted edits	`git stash` or `git restore .` — done in 5 seconds
Local commits, not pushed	1-N local commits	`git reset --hard <good-sha>` — minute or two
Pushed to feature branch	Force-pushed PR	Find via reflog, force-push the recovered tree
Pushed to main / production	Other people now have it	Coordinate with team, revert via PR (do not force-push main)

Sandbox setup that prevents 90% of incidents

# Future-proofing: never run an agent on main

1. Always work on a branch:
     git checkout -b agent/refactor-auth

2. Set Claude Code / Cursor permissions:
     - No git push
     - No `rm -rf` outside cwd
     - No edits in protected paths (.github/, secrets/, migrations/)

3. Use a worktree for risky agent runs:
     git worktree add ../experiment HEAD
     cd ../experiment
     # If it goes wrong: rm -rf ../experiment, no harm to main repo

4. CI must pass before merge — agent can't commit to main directlyThese four rules, applied at the team level, eliminate most agent disasters before they start.

Recovery, file by file, when reflog isn't enough

`git checkout HEAD~N -- path/to/file` — restore one file from N commits ago
`git diff HEAD~5 HEAD -- path/to/file | git apply -R` — undo the diff while keeping later changes
`git log -p path/to/file` — see every change, copy-paste the version you want back
Backups in your editor's local history (VS Code Timeline, JetBrains Local History) — sometimes saves you when git can't

After recovery: the postmortem

Once everything is green again, write a 5-minute blameless postmortem to yourself. What permission did the agent have that it shouldn't? What signal would have stopped you sooner? What do you change in your CLAUDE.md, .cursor/rules, or pre-commit hooks to prevent this exact failure? Save it. Read it next time you set up a new project.

The agents will mess up. Plan to recover, not to prevent.
— A platform engineer who has seen things

The big idea: agent disasters are inevitable; data loss is not. Branch, sandbox, and trust git reflog. When the agent goes off the rails, stop, inventory, recover from reflog, and turn the postmortem into a permission rule that prevents the exact failure. Recovery is a skill, not a panic.

End-of-lesson check

15 questions · take it digitally for instant feedback at tendril.neural-forge.io/learn/quiz/end-coding-debug-recovery-bad-agent-creators

What is the absolute FIRST action you should take when an AI agent makes dozens of edits across many files and the build suddenly breaks?
1. Immediately run git reset --hard to revert everything
2. Check the CI/CD pipeline logs for error messages
3. Interrupt the agent's terminal with Ctrl+C and close the session
4. Run git pull to get the latest version and see what changed
Why should you avoid running git pull, git fetch, or git checkout immediately after discovering an agent has damaged the repository?
1. Git automatically locks the repository after errors
2. These commands might introduce merge conflicts
3. Network connectivity is typically lost after errors
4. These commands could overwrite or destroy recoverable state in your working directory
What does git reflog actually store and preserve?
1. Every position that HEAD has pointed to in the repository's entire history
2. A log of all file contents, not just references
3. Only commits that have been successfully pushed to a remote repository
4. Only merge commits and tags, not regular commits
An agent runs `git reset --hard` to an old commit and then executes `git push --force`. Even after this destructive sequence, what provides a path to recover the lost commits?
1. Cloud backup services automatically restore repository state
2. The reflog still contains the previous HEAD positions and allows recovery
3. Git garbage collection has already removed the old commits
4. You must recreate all lost work manually
In the context of assessing damage from an out-of-control agent, what does 'blast radius' refer to?
1. The memory usage of the git process during the incident
2. The file size of the repository in megabytes
3. The number of developers who have cloned the repository
4. The extent of the damage - whether it affected working tree, local commits, or remote branches
When the damage is limited to uncommitted edits in the working tree only, what is the fastest recovery method?
1. git stash or git restore . to discard uncommitted changes
2. git reset --hard HEAD to roll back all changes
3. Create a new branch and cherry-pick commits
4. Re-clone the entire repository from scratch
If an agent created several local commits that have NOT yet been pushed to any remote, what is the recommended recovery approach?
1. Force-push anyway to see what happens
2. Delete the entire local repository
3. Wait to see if the agent fixes it automatically
4. Find the last known good commit SHA via reflog and run git reset --hard to it
Why is force-pushing to the main or production branch generally prohibited in team environments?
1. It automatically triggers a code review
2. Force-pushing main breaks other developers' local checkouts and creates coordination problems
3. The command was deprecated in modern Git versions
4. Git security settings block it by default
An agent has deployed broken code to a production environment. What is the correct recovery procedure?
1. Create a forward-rolling revert PR that undoes the bad changes without rewriting history
2. Delete the production server and start over
3. Wait for the agent to automatically detect and fix its mistake
4. Immediately force-push to main to overwrite the bad deployment
What git command restores a single specific file to its state from N commits ago?
1. git revert HEAD~N -- path/to/file
2. git restore --source=HEAD~N path/to/file
3. Both A and B work for this purpose
4. git checkout HEAD~N -- path/to/file
What additional recovery option do VS Code Timeline and JetBrains Local History provide beyond git?
1. Editor-level history of file changes that persists even when git history can't help
2. Cloud-based backup of all repository files
3. Automatic code review of all changes
4. Integration with CI/CD pipelines
According to the cultural practices described, when should a blameless postmortem be written?
1. Only when upper management requests it
2. Before starting any new work on the project
3. Once everything is green again after successful recovery
4. Immediately after the incident while emotions are high
What specific elements should a blameless postmortem identify to prevent future incidents?
1. The exact monetary cost of the incident
2. Which team member was responsible for the error
3. What permission the agent had that it shouldn't, what signal would have stopped it sooner, and what rules to update in CLAUDE.md or pre-commit hooks
4. How to restrict all AI agent usage going forward
The lesson quotes: 'The agents will mess up. Plan to recover, not to prevent.' What underlying principle does this express?
1. All mistakes should be ignored and forgotten
2. Focus on building robust recovery skills and processes rather than assuming agents won't make mistakes
3. Prevention measures are completely useless
4. AI agents should never be used in development
What does the lesson identify as the 'big idea' - the core principle that agent disasters are inevitable but data loss is not?
1. Never give agents any permissions
2. Git is perfect and never loses data
3. Always use version control for all files
4. Agent disasters are inevitable; data loss is not - branch wisely, sandbox aggressively, and trust git reflog for recovery

← Back to interactive lesson

Tendril · Creators · AI-Assisted Coding