What Are Checkpoints in Coding Agents, and What Can They Actually Undo?

Published October 22, 2026 · by the AQ team

A checkpoint is a snapshot of your working files that a coding agent harness records before the agent changes them, so a session that goes wrong can be rolled back without touching your git history. As of October 2026 the major harnesses differ more here than almost anywhere else: Claude Code can restore code, conversation, or both from any prompt in the session; Cursor restores files but never the conversation; OpenCode keeps git-backed snapshots behind an /undo command; and Codex CLI and Google's Antigravity CLI document only conversation rollback, leaving file recovery to git. All of them agree on the limits: a checkpoint undoes the agent's own file edits, and nothing else.

What a checkpoint is

Mechanically, a checkpoint is the harness copying the state of the files the agent is about to touch (and remembering where the conversation stood) at a turn boundary, usually right before your prompt runs. It is not a git commit: no branch moves, nothing lands in your history, and the snapshot lives in the harness's own storage. That separation is the point. An agent makes dozens of edits per turn, far too many to commit individually, and a checkpoint gives you an undo that matches how agent work actually fails: not one bad line, but one bad turn.

The same mechanics define the blind spots. A checkpoint records what the harness's own editing tools wrote, so a file changed any other way (a shell command the agent ran, a script, your own editor) is usually invisible to it, and anything that happened outside the filesystem was never in the snapshot at all. Those gaps are where people get hurt, so they get their own section below.

Claude Code: rewind code, conversation, or both

Claude Code has the most complete checkpoint system of the current CLIs, per Anthropic's documentation as of October 2026. Every prompt that starts a turn creates a checkpoint automatically, and running /rewind (or pressing Esc twice on an empty prompt) opens a menu of the session's prompts. From any of them you can restore code and conversation together, the conversation while keeping the current code, or the code while keeping the conversation; the same menu can also summarize part of the conversation to free context window space. Checkpoints are saved with the conversation, so you can still rewind after resuming a session on a later day. Snapshots are kept for the 100 most recent checkpoints in a session and deleted about 30 days after the session last saved one, a window the cleanupPeriodDays setting extends.

The documented limitations are just as specific. Files modified by bash commands are not tracked: if the agent runs rm, mv, or cp, rewind cannot undo it. Most subagent edits are not captured, so a background task's changes survive a rewind; so do manual edits you make outside the session and edits from other concurrent sessions, and symlinked or hard-linked paths are skipped on restore with a warning. Anthropic's own summary is the right one: checkpoints are quick, session-level recovery, and git remains the permanent history.

Cursor: checkpoints restore files, never the conversation

Cursor's Agent automatically creates a checkpoint before making significant changes, capturing the state of the files it has modified, per Cursor's documentation as of October 2026. You restore from the chat timeline (or the Restore Checkpoint control on an earlier request), and the restore is the mirror image of Claude Code's: it reverts files only and does not remove messages from the conversation, so the chat keeps going with the code rolled back. Checkpoints are stored locally and separate from git, they track the agent's changes rather than your manual edits, and Cursor's docs say plainly that they are not a version control system: use them for undoing agent changes, and git for permanent history.

OpenCode: git-backed snapshots behind /undo and /redo

OpenCode (2.0 is current as of October 2026) takes snapshots around each model step and stores them in a separate internal git object database under its data directory, without creating commits or moving branches. Snapshots are on by default but require a git repository: outside one, /undo can roll back the conversation but has no file state to restore. Running /undo stages a rollback, restores the files the reverted steps changed (files they created are removed), and returns your prompt to the composer for editing; /redo cancels a staged rollback before you resubmit. The docs are explicit about scope: shell side effects such as processes, network calls, databases, and git state itself are not reversed, untracked files over 2 MiB are not captured, and snapshots are a convenience, not a backup.

Codex CLI and Antigravity: conversation rollback, git for files

OpenAI's Codex CLI has no checkpoint restore in its official command set as of October 2026: the slash-command reference documents /fork (copy a chat into a new chat or worktree) but no command that reverts file changes. An experimental /undo that restored file state from snapshots appeared in Codex CLI builds earlier in 2026 and was later removed, per the project's public repository, so the practical rollback story for Codex today is git: commit before risky turns, revert when one goes wrong.

Google's Antigravity CLI (binary agy, the successor to the Gemini CLI) documents /rewind, with /undo as an alias, as a conversation command: it rolls your conversation history back to a previous message. A /fork command clones the thread into a parallel session, and /diff opens a viewer over changes and commits, but the CLI reference documents no file-state restore as of October 2026, so file recovery is again git's job.

What each harness can restore

Checkpoints, git commits, and worktrees: three layers, not one

These three mechanisms get conflated because all of them "save your work", but they protect against different failures. A checkpoint is session-scoped undo: cheap, automatic, and ephemeral (Claude Code's expire in about 30 days, Cursor's are local to the machine, OpenCode's live outside your repo). A git commit is durable, shared history that survives the session, the harness, and, once pushed, the machine. A git worktree is isolation rather than undo: it keeps one agent's changes physically separate from another's, so a bad run never needed undoing in your main checkout in the first place.

The three compose into a simple discipline. Let the harness checkpoint every turn (it already does). Commit on the agent's branch whenever the work reaches a state worth keeping: that converts ephemeral undo into durable history and covers what checkpoints miss on the filesystem, including shell-command changes. And give each agent its own worktree or clone, so the blast radius of the turn you could not rewind is one directory. When the work is done, review and merge it like any other branch; verifying agent work covers what to check first.

What no checkpoint protects

Every harness's documentation says some version of the same sentence, and it deserves repeating in plain terms: a checkpoint restores file contents, and the world is mostly not file contents. Nothing above undoes a side effect that left the machine (an API call, an email, a deploy, a push, a published package) or state in a running system (a database migration, dropped rows, a service restarted with new config). OpenCode's docs name processes, network resources, databases, and git state explicitly; Claude Code's name bash file operations. If an action is irreversible, the protection has to come before it runs, not after: permission prompts, scoped credentials, and sandboxes, the layered approach in limiting what a coding agent can destroy. Checkpoints are the fast layer for the failures that are reversible, and a reason to be deliberate about the ones that are not.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. AQ runs the real CLIs unmodified in persistent tmux sessions on your team's VM, so every checkpoint behavior on this page works exactly as the vendor documents it, and session-local state like Claude Code's saved checkpoints lives on the machine where the session actually resumes, not on whichever laptop ran the task last. Underneath the harness layer, AQ supplies the other two layers by default: every workspace is its own isolated git worktree on a branch like ai/1234-fix-auth (with automatic dependency install and a one-click rebase onto main), so one agent's unrewindable turn never touches another's work, and agents commit, push, and open PRs with per-user GitHub auth. Sessions survive a closed laptop and resume from any device, and teammates can open the same workspace and watch the same live session. The Free plan is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit); the Team plan is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, rate locked for your first 12 months.