What /rewind and /restore actually put back in Gemini CLI

A checkpoint in Gemini CLI is a commit in a shadow Git repository under ~/.gemini/history/<project-id>, taken before a file-editing tool call that is waiting for your approval, together with the conversation at that moment. A shadow repository is a separate Git repository Gemini CLI creates for itself, so its snapshots never touch your own .git. /restore puts the launch directory and the conversation back to that checkpoint.

/rewind is the other undo. It moves the conversation to an earlier turn and can reverse the agent's edits recorded from that point onward, without any checkpoint setting. The two commands are close enough in name that people use them interchangeably, but one is a snapshot of the launch directory and the other is a conversation rollback with a best-effort file revert. Neither is git reset.

Run gemini --version first. This page describes v0.65.0 (20 October 2026); the checkpoint and rewind surfaces have changed across the 0.6x releases.

Checked against Gemini CLI's documentation on 27 October 2026.

Status, 27 October 2026: /restore can delete or revert files that Git ignores through .git/info/exclude or an explicitly set core.excludesFile; rules in the project's .gitignore are honored. The report is open (#29654, updated 23 October 2026). Copy files protected only by those exclude sources out of the tree before a restore. Unpaid-tier and Google One users were moved to Antigravity CLI on 18 June 2026, so this page applies to paid, API-key, Vertex AI and enterprise installs; the Gemini CLI hub has the details.

/rewind: the conversation's own undo#

Type /rewind, or press Esc twice. Gemini CLI lists the user turns in the current session, newest at the bottom, with a preview of the prompt and the number of files changed in that step. Select a turn, then choose one of the actions:

• Rewind conversation and revert code changes — both.
• Rewind conversation — drop the later turns, keep the files.
• Revert code changes — keep the conversation, put the files back.
• Do nothing — cancel.

If no code changed from that point on, the file options are hidden.

What it does to the conversation#

The conversation is cut back to just before the selected prompt, and that prompt is put back in the input box so you can edit it and send it again. The model loses the turns that were removed; if you only reverted the code, it still believes the old edits exist, so tell it what changed before the next request.

What it does to the files#

For every agent edit recorded from the selected prompt to the end of the conversation, /rewind reads the before and after content stored with that tool call. If the file on disk still matches the "after" content, it writes the "before" content back, or deletes the file if the edit created it. If the file has changed since, it builds a reverse patch and applies it. If the patch does not apply, it warns that the smart revert failed and leaves the file alone (rewindFileOps.ts).

That is why /rewind is best effort rather than a snapshot restore. It only knows the edit tools: replace and write_file. It does not undo your own edits, changes made through the shell tool (!), or a commit the agent ran. It also cannot reverse an external effect such as a migration, an API call, or a publish.

/rewind does not need checkpointing. It works in a plain directory and across compression (Gemini CLI's replacement of older turns with a summary when the context window fills), because it reconstructs the conversation from the recorded session data (rewind docs). The doc's warning is the one to remember: when you rewind the conversation, the model forgets the removed turns; when you only revert code, you have to tell it that the files changed.

The list can be stale after a load#

There is a known gap. /resume resume <tag> and /restore load history through the load_history action, which replaces the client history but does not reinitialize the recorder that /rewind reads. The rewind list can therefore show turns from before the load instead of the conversation now on screen (#25646, closed as not planned 6 June 2026; the handler still does the same at v0.65.0).

The session browser and --resume take a different path and do reinitialize the recorder, so their rewind list matches the loaded session. If the list after a /restore or a tagged resume does not match what you see, restart and resume through /resume rather than rewinding blind.

/restore: the checkpoint path#

Checkpointing is off by default. Add this to ~/.gemini/settings.json and restart Gemini CLI:

{
  "general": {
    "checkpointing": {
      "enabled": true
    }
  }
}

The old --checkpointing command-line flag was removed in 0.11.0. At v0.65.0 the setting is not in the /settings dialog, so edit the file. If /restore is not in the slash-command menu, checkpointing is off; the command is only registered when the setting is enabled (restoreCommand.ts).

Checkpointing needs the git binary, but not a Git repository of yours. The shadow repository is created under ~/.gemini/history/<project-id>, and its work tree is the directory where you launched Gemini (gitService.ts). Files outside that directory are not in the snapshot.

When a checkpoint is created#

When an edit tool is waiting for approval, Gemini CLI commits the whole working tree to the shadow repository, records the conversation and the specific tool call, and writes a JSON file in ~/.gemini/tmp/<project-id>/checkpoints. The commit is the project state; the JSON is the conversation and the pending tool call.

The list is project-wide, not session-wide. /restore with no argument shows every checkpoint file for the project, oldest and newest together, named with the timestamp, the file, and the tool (2025-06-22T10-00-00_000Z-my-file.txt-write_file). /restore <name> accepts the name from that list; the command appends .json if you leave it off (checkpointing docs).

What it puts back, and what it takes with it#

/restore <name> reloads the conversation from the checkpoint and restores the working tree: git restore --source <commit>. in the shadow repository, then git clean -f -d to remove untracked files created since the snapshot. The original tool call is then re-proposed, so you can run it, change it, or ignore it.

That is a whole-tree operation. If you edited a different file inside the launch directory after the checkpoint, created a new untracked file there, or changed something outside the agent's edit, the restore puts it back to the snapshot or deletes it. It restores before it re-proposes the tool call, and the docs describe the change as immediate; treat /restore as a rollback of the launch directory, not as "undo this one edit".

Two specific traps:

Ignored files. The shadow repository copies the project's .gitignore but not .git/info/exclude or an explicitly set core.excludesFile, and it uses its own global Git config. A file protected only by those two sources can be deleted if it was created after the checkpoint, or reverted if it existed before. The open report describes a local notes file being deleted and a .env file being rolled back (#29654). Copy those files out before a restore.

Auto-accept modes. The checkpoint writer only acts on edit tool calls in AwaitingApproval (useGeminiStream.ts). In auto-edit mode (edits run without a confirmation prompt), ordinary edit tools are approved before that state; in YOLO mode (auto-approve everything), the policy allows them without a dialog. No checkpoint file is written for that edit, so /restore may have nothing newer to offer and can report "No restorable tool calls found." A January 2026 report of exactly this was closed as completed in February 2026 (#15786), but the AwaitingApproval filter is still in v0.65.0. Test /restore after an auto-approved edit before relying on it; the permissions guide explains the modes.

A checkpoint is not a backup#

The shadow repository is not your repository. git log, git reflog, and git gc in your project do not see it, and a clone or a fresh checkout does not carry it. The checkpoints live under ~/.gemini, so clearing that directory, uninstalling with data removal, or moving to another machine loses them. If the shadow commit is missing, /restore reports that the commit cannot be found and cannot restore that checkpoint.

Keep the useful ones outside the tool: commit the work, or copy ~/.gemini/tmp/<project-id>/checkpoints and ~/.gemini/history/<project-id> with the rest of the session files. The session resume guide covers that backup.

Which one to use#

• Undo the last agent edit and the turns after it: /rewind, both options. This is the common case and needs no setup.
• Drop the later turns but keep the code: /rewind, conversation only.
• Keep the conversation but put the agent's edits back: /rewind, code only, then tell the model the files changed.
• Go back to before one specific tool call, whole tree: /restore <name>. Read the checkpoint timestamp first; old checkpoints are listed too.
• Restore a conversation you tagged: /resume resume <tag> (the tag was saved with /resume save <tag>). This moves no files. If /resume list says "No saved conversation checkpoints found", you have no tags; that is not a session problem.
• Undo a shell command or one of your own edits: git restore -- <path> for a tracked file (it reads your Git index or the commit you name), or your editor's local history. /rewind will not touch it; /restore will revert the whole tree, which is broader than you want.
• Undo a commit: git revert or git reset in your own repository. Neither Gemini command rewrites Git history.
• Undo an external effect: nothing here. A migration, an API call, a deploy, or a publish is outside both tools.

Check what happened#

Before a restore, read the state you are about to lose:

git status --short
git diff --stat

Then confirm that checkpoints exist and where they are:

ls ~/.gemini/tmp/<project-id>/checkpoints
ls ~/.gemini/history/<project-id>

Inside Gemini, /restore with no argument lists the checkpoint names, or says "No restorable tool calls found." That message means the list is empty, not that the files are safe.

After a rewind or restore, run git status and git diff again and open the file that mattered. The conversation can say the edit is gone while the disk still has it, and the reverse. Do not ask the model whether the undo worked; read the file and the diff. If the session was compressed, context compaction explains why the model's account of the earlier turns may be a summary rather than the record.

Where to go next#

• Gemini CLI guides — the hub for this set.
• Where did my Gemini CLI session go? — finding, resuming, and backing up the transcript.
• Why Gemini CLI keeps asking for permission — auto-edit, YOLO, and the approval that creates a checkpoint.
• Context compaction — what the model keeps after a long session.
• Does Gemini CLI read AGENTS.md? — if the rules you are trying to restore live in a context file.