Cline checkpoints: the undo button that's better than git reset

Published 2026-05-11 by Owner

Every Cline session is, at its core, a sequence of decisions. The agent reads a file, forms a plan, edits three things, runs a command, edits two more things, declares done. Most of the time this goes fine. When it doesn’t — when step four turns out to be wrong and the agent spent steps five through twelve building on top of the error — you want a way back that doesn’t require resetting git and replaying fifteen minutes of good work.

Checkpoints are that mechanism. They exist inside Cline’s task model, not in your git history, and they let you roll back to any marked moment in the session without touching the commits you’ve already made.

Used intentionally, checkpoints change how the session feels. Instead of being cautious about letting Cline continue — because any mistake is expensive to unwind — the agent can run further and correct course cheaply when it drifts.

When Cline creates checkpoints automatically

Cline creates a checkpoint automatically at two moments:

Before a Plan/Act mode transition. When the session switches from planning to executing, Cline snapshots the file state. If Act goes badly, you can roll back to the pre-Act state without losing the Plan discussion — then refine and try again.

Before a major edit batch. When the agent is about to modify more than one file, or is about to run a destructive command (deletes, overwrites, installs), it drops a checkpoint first. The exact heuristic isn’t published, but in practice you see checkpoints before: creating new files, rewriting existing functions, running npm install or similar, and multi-file refactors.

The automatic checkpoints are visible in the Cline task history panel as small markers between steps. They show a timestamp and a short description of what was about to happen — “before editing auth.ts and routes/index.ts” or “before running migration”.

There is no setting to disable automatic checkpoints. They’re lightweight enough that the overhead is negligible; keeping them on is the right default.

One subtlety worth knowing: automatic checkpoints snapshot the file state on disk, not the conversation context. The chat history leading up to a checkpoint is preserved separately and stays intact after a rollback. Rolling back to checkpoint three puts the files back at that moment, but the conversation still shows everything that was discussed up through the current step. This is useful — Cline can reference what went wrong in the steps after the checkpoint when figuring out what to do differently this time.

This means prompting after a rollback doesn’t require re-explaining context. The model still has the full conversation. Just tell it what was wrong and what to do differently.

Creating manual checkpoints

Automatic checkpoints cover the major transitions. Manual checkpoints are for the smaller moments where you’ve reached a state you like and want to pin before the session continues.

To create one: in the Cline chat input, type /checkpoint or click the checkpoint button in the task toolbar. Cline will record the current file state and add a named marker to the session history.

The most useful places to add manual checkpoints:

• After a Plan discussion you’re satisfied with, before switching to Act
• After the first file edits look correct, before the agent continues to the next file
• After a test run passes, before the agent starts refactoring to clean up
• Any time the phrase “this is exactly what I wanted” crosses your mind

Manual checkpoints take a second to create and show up in the history with the label “manual checkpoint” plus the timestamp. Add them aggressively — they cost nothing and the habit of marking good states before continuing is worth building.

One practical trigger: any time the agent outputs something you read twice and think “yes, exactly this” — create a checkpoint before it takes the next step. The moment of satisfaction is precisely when forward progress is most likely to put a good state at risk.

A second trigger: before any follow-up instruction that changes scope. If the agent just finished adding a feature and you’re about to ask it to update the tests, checkpoint first. If the tests break something, rolling back to “feature done, tests not yet touched” is clean.

Checkpoint vs. git commit: which to use when

The two tools solve different problems.

Checkpoints are intra-session. They exist inside Cline’s task model and are not persisted to git. They disappear when you close the task or start a new one. Use them to navigate within a session — to undo a direction the agent took, to try a different approach, to recover from a bad Act run.

Git commits are checkpoints for completed thoughts. A commit marks a state that’s correct enough to share, to deploy, to hand to a reviewer. Committing before you’re sure is fine (commits are cheap and revertible), but the commit says “I’ve reviewed this and it’s at least locally correct.”

The common pattern:

1. Work in Cline with checkpoints as the undo mechanism
2. When the session reaches a verifiably good state, commit
3. The commits are cleaner because the checkpoints let you iterate without leaving “fix typo from last edit” commits everywhere

Where they conflict: if you’ve committed mid-session and then want to roll back to a checkpoint that predates the commit, the checkpoint controls file state but not git history. You’d need to also revert the commit, or live with a slightly diverged state. This is rare in practice — most people commit after they’re happy with the checkpoint, not before.

The “rolled back too far” recovery

Rolling back is easy to misapply. The scenario: the agent does something wrong at step six, you roll back to checkpoint four, but it turns out checkpoint five was actually fine and checkpoint four loses two pieces of work you wanted.

Cline handles this by preserving the post-rollback state as its own checkpoint. When you roll back, the state you’re rolling back from is saved automatically. It shows up in history as “pre-rollback snapshot” with the timestamp.

To undo a rollback:

1. Open the task history
2. Find the “pre-rollback snapshot” entry
3. Click “restore” on that entry

This gets you back to the state just before you rolled back — which is the state that contained the work you didn’t mean to lose. From there, you can try a different approach: roll back to an earlier checkpoint selectively, or ask the agent to fix just the broken part rather than redoing everything from checkpoint four.

There’s also a more targeted recovery path: look at what files the agent changed between the checkpoint you rolled back to and the rollback point. Sometimes only one file is wrong. You can manually restore the good files and leave the bad one at its rolled-back state — no steps need to be re-run.

The practical implication: rolling back is not destructive. The pre-rollback state is always recoverable as long as you’re still in the same task session. This makes checkpoints safer to use aggressively — overcorrecting is recoverable.

What checkpoints actually store

Before trusting checkpoints for recovery, it helps to know what they capture.

Each checkpoint stores a snapshot of the files Cline has touched during the session. Not your entire working directory — only the specific files the agent read or wrote. If a file was never opened by Cline during the session, it’s not tracked and rolling back won’t affect it.

This matters in two ways.

First, if the agent modifies a file and you manually edit it afterward (outside the Cline session), the checkpoint still holds the pre-manual-edit state. Rolling back will discard your manual edits. The checkpoint doesn’t track changes you made yourself; it only tracks the agent’s path.

Second, files created by the agent are included. If Cline generates a new file in step three and you roll back to step two, that file is removed. This is usually what you want — the rollback restores the state before Cline created the file — but it can be surprising the first time.

The practical rule: checkpoint rollback undoes all of the agent’s actions up to that point, not a subset. If only some changes need discarding, roll back and manually re-apply the pieces to keep before continuing.

Checkpoint hygiene on long sessions

A two-hour Cline session with automatic checkpoints on a large refactor can accumulate twenty or thirty markers. The task history gets hard to scan; the useful checkpoints get buried under “before saving config.json” entries that nobody cares about.

A few patterns that help:

Name your manual checkpoints. The /checkpoint "auth refactor complete" syntax (or the name field in the UI) adds a description. Descriptive manual checkpoints stand out from the automatic ones and make the history scannable.

Delete checkpoints after the task is done. Once committed and verified, the session’s checkpoints have no further value. Clearing the history keeps the UI clean for the next session.

Keep sessions task-scoped. The more a session sprawls across multiple concerns, the more checkpoints accumulate and the harder recovery becomes. A session that covers “add authentication” is easier to navigate than one that covers “add auth, fix the billing bug, refactor routes, update tests.” The discipline of task-scoping that makes Plan mode useful also makes checkpoint history manageable.

Don’t rely on checkpoints across multiple days. Checkpoints persist as long as the task is open in Cline, but they’re not backed up or versioned like git. For anything you need to survive a machine restart or a Cline update, commit to git. Checkpoints are a session tool, not a backup strategy.

Watch for accumulation on repeated Act runs. If a session involves multiple Plan/Act cycles, each cycle adds its own automatic checkpoints. A session with four Act runs can easily have forty or more entries. Before starting a new cycle, scan the history and confirm the last manual checkpoint is positioned correctly. If the previous cycle’s work is committed and verified, archive the old checkpoints and start fresh.

Keep labels meaningful enough to scan in thirty seconds. “before next steps” is not useful; “before splitting auth into three files” is. Distinct enough to find the right restore point without reading carefully.

The mental model: git commits are permanent decisions; checkpoints are working memory. Use working memory freely while thinking; commit when something is verified. Mixing up which tool does which job leads to both being used worse.

There’s also an ergonomic argument for keeping them separate. A developer who commits after every Cline step ends up with a git log full of intermediate states, partial solutions, and reverted directions. The reviewer who reads that history later learns nothing from it. Keeping intra-session recovery inside Cline’s checkpoint system and committing only when something is verified keeps the git history legible.

A session that shows the full picture

The task was to add a feature flag system to an existing API. The session had twelve steps across two Cline Plan/Act cycles.

Plan mode produced a plan: add a features table, a getFlag helper, a middleware wrapper, and update three route files. Cline created checkpoint A at the Plan/Act transition.

Act ran fine through the table and helper (checkpoints B and C). The middleware implementation in step five was wrong — it was evaluating flags per-request when the design called for per-session. The route files in steps six through eight were already built on top of the wrong middleware.

The correct move: roll back to checkpoint C (after the helper, before the middleware), then give Cline a corrected instruction for the middleware step. The work in steps one through four survives intact. Steps five through eight are redone correctly.

Without checkpoints: git reset --hard to before step five, losing the correctly-done steps one through four, then redo them before continuing. Or hand-edit the middleware and hope the route files don’t need updates.

With checkpoints: twelve seconds to roll back to C, one clarifying instruction, Act reruns steps five through eight. The time savings compound across a session.

This is the core value: checkpoints let the agent recover from being wrong without making the human pay for the recovery.

The earned insight from many sessions like this one: the agents that feel reliable are not the ones that never go wrong. They’re the ones where going wrong is cheap. Checkpoints are the mechanism that makes the cost of error low enough to tolerate a long autonomous run without babysitting every step.

A good session rhythm: Plan, switch to Act, let it run to the first natural pause, check the diff, checkpoint if the diff looks right, continue. If something goes wrong two steps later, there’s a clean rollback point and a clear picture of what was verified versus what wasn’t.