How to Undo Changes Made by an AI Coding Agent

To undo changes an AI coding agent made, use git. If you committed before the agent started, git restore . discards its edits to tracked files, git clean -fd removes the new files it created, git reset --hard <sha> returns your branch to a known-good commit, and git reflog finds commits you thought were lost. Built-in checkpoints, such as Claude Code's /rewind and Cursor's Restore Checkpoint, are faster for undoing the last turn or two, but they only track the agent's own file edits and both tools say they are not a replacement for version control. The habit that makes every rollback easy is simple: create a restore point before every agent turn.

This guide walks through that habit, the git commands to reach for in order from smallest to largest, how to recover work that seems gone, and where the tools’ own checkpoints fit.

Why agent changes are harder to undo than your own

When you edit code by hand, you change one file at a time and your editor’s undo stack is usually enough. An agent works differently. A single prompt can touch a dozen files, and the agent does more than edit text. It runs commands, and those commands have side effects your editor never sees.

• Edits to tracked files, often spread across many directories.
• New untracked files: components, tests, scripts, config.
• Deleted or renamed files.
• Side effects of shell commands: lockfile changes from a package install, output from codegen or formatters, database migrations.
• Changes to git itself, if the agent is allowed to commit, check out branches, or reset.

Editor undo cannot reverse a package install, and per-file undo across twelve files is guesswork. Git sees the whole working tree, which is why it is the right tool for the job, as long as there is a commit to go back to.

Step 1: Create a restore point before every agent turn

Before you send a prompt that will change code, make sure the current state is saved somewhere git can find it. A throwaway commit is the most reliable option. If you do not want extra commits, a stash works too.

# Option A: a work-in-progress commit
git add -A
git commit -m "wip: before agent: add rate limiting"

# Option B: snapshot with stash, then put your changes straight back
git stash push -u -m "before agent: add rate limiting"
git stash apply
# the stash stays in `git stash list` as a backup

Option B is handy when you are mid-change and want the agent to keep working on top of your edits. -u includes untracked files, and apply (unlike pop) leaves the stash in place so you can return to it.

WIP commits pile up quickly, so tidy them before you open a pull request. git reset --soft <base-sha> keeps all changes staged and lets you write one clean commit, or you can squash with an interactive rebase.

Step 2: Isolate the agent on a branch or worktree

A branch gives the experiment a name and makes throwing it away a one-liner. A git worktree goes further: it is a second checkout of the same repository in its own directory, so the agent can work there while your main checkout stays untouched. It also lets you run two agents in parallel without them editing the same files.

# a branch for the experiment
git switch -c agent/rate-limit

# or a separate working directory for the agent
git worktree add ../myapp-agent -b agent/rate-limit
cd ../myapp-agent   # run the agent here

# didn't work out? throw the whole thing away
cd ../myapp
git worktree remove --force ../myapp-agent
git branch -D agent/rate-limit

If the experiment works, merge the branch like any other. If it does not, you delete it and your main branch never knew it existed.

Step 3: Roll back, from the smallest hammer to the largest

Start by looking. git status lists every file that changed or appeared, and git diff --stat shows how much. Then pick the smallest command that fixes the problem:

• Undo one file: git restore path/to/file. To take a file back to a specific commit, use git restore --source=<sha> path/to/file.
• Undo all uncommitted edits to tracked files: git restore . from the repository root. New files the agent created are not touched.
• Remove new untracked files: run git clean -n first to see what would be deleted, then git clean -fd. Ignored files are left alone unless you add -x.
• Undo commits the agent made but keep the changes to inspect: git reset --soft <sha> (changes stay staged) or git reset <sha> (changes stay in the working tree).
• Throw away everything since a known-good commit: git reset --hard <sha>. This discards uncommitted work, so be sure you have a restore point.
• Undo a commit that has already been pushed and shared: git revert <sha>. It adds a new commit that reverses the change instead of rewriting history your teammates already have.

Keeping some of the agent’s work is often better than keeping none of it. git restore -p and git add -p let you walk through the changes hunk by hunk and keep only the parts you want.

Step 4: Use git reflog when something seems lost

If a reset or a rebase went wrong, or the agent ran a git command you did not expect, the reflog is how you get back. According to the git documentation, reflogs record when the tips of branches and other references were updated in your local repository, and the HEAD reflog also records branch switching. By default, reachable entries are kept for 90 days and unreachable ones for 30 days (the gc.reflogExpire and gc.reflogExpireUnreachable settings).

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# 9f8e7d6 HEAD@{1}: commit: agent: refactor auth middleware
# 4c1a2b0 HEAD@{2}: commit: wip: before agent

# put a branch on the commit you want back
git branch rescue 9f8e7d6

Dropped stashes and commits that no reference points to anymore can sometimes be found with git fsck --lost-found, which writes dangling objects into .git/lost-found. There is one hard limit: work that was never committed or stashed is not in the reflog. Git cannot recover what it never saw, which is the whole point of Step 1.

Step 5: Use the tool’s own checkpoints for quick, recent undo

Most agentic coding tools keep their own snapshots. They are the fastest way to undo the last few turns, and they work even if you forgot to commit. They are also narrower than git, so know their limits.

Claude Code creates a checkpoint before each prompt you send. Run /rewind, or press Esc twice with an empty prompt, to open the rewind menu, pick a prompt, and choose to restore the code, the conversation, or both. Its documentation says it keeps file snapshots for the 100 most recent checkpoints in a session, saves checkpoints with the conversation so /rewind still works after you resume, and deletes snapshots in its retention sweep, by default about 30 days later. The documented limits matter: files changed only by Bash commands are not tracked, edits made by most subagents are not restored, and changes you or another session made outside the current session are normally not captured. The docs point you to git for all of those.

Cursor’s Agent creates checkpoints automatically before significant changes. You can click a checkpoint in the chat timeline to preview files at that point and restore them, or use the Restore Checkpoint button on a previous request. Restoring reverts files only; it does not remove messages from the conversation. Cursor’s docs describe checkpoints as stored locally and separate from Git, and say to use them only for undoing Agent changes and to use Git for permanent version control.

“Checkpoints are an undo button. Git is the history. You want both.”

Keep the prompt when you roll back the code

Rolling back fixes the symptom but throws away the most useful information: what the agent was asked to do and how it interpreted that. Without it, your next attempt tends to repeat the same mistake. At minimum, paste the prompt into the commit message of your WIP commit, or into the revert commit, so the reasoning lives next to the change.

This is the gap VibeHub fills. vb is a git superset: vb commit stages, commits, and captures the LLM transcript that produced the change, and any command vb does not know falls through to plain git, so everything above (restore, reset, reflog, worktree) works unchanged. When you need to roll back, you can see what each commit was built from before you choose a target.

vb log              # recent commits with conversation message counts
vb show 9f8e7d6     # message, diffstat, and the conversation transcript
vb checkout 4c1a2b0 # restore the working tree to a recorded commit

The vb CLI is free; a transcript-captured commit costs 1 credit. Whichever tools you use, this checklist covers almost every rollback:

• Commit or stash before every agent turn.
• Give risky work its own branch or worktree.
• Look first with git status and git diff --stat, then use the smallest command that fixes it.
• Use git revert for anything already pushed.
• Reach for git reflog before assuming work is lost.
• Use built-in checkpoints for the last few turns, and git for everything else.
• Keep the prompt with the commit so the next attempt starts smarter.