How checkpoints work
Cline maintains a shadow Git repository that is completely separate from your project’s own Git history. After each tool use — file edits, commands, and so on — Cline commits the current state of your files to this shadow repo. Your main Git repository stays untouched. This means:- Your Git history remains clean and under your control
- Checkpoints capture all files, including ones not tracked by Git
- You can restore to any point in a task without affecting commits you’ve already made
- Checkpoints persist across editor sessions
Enable or disable checkpoints
For very large repositories, checkpoints may use significant storage and slow down Cline slightly as it commits file snapshots after each tool use. Consider disabling them if you notice performance issues.
Viewing and comparing changes
After each tool use, a checkpoint indicator appears in your conversation — a bookmark icon labeled Checkpoint with Compare and Restore buttons. Click Compare to open a diff view showing exactly what changed at that checkpoint. This opens in your editor’s diff viewer, letting you see additions, deletions, and modifications across all affected files. This is useful when Cline makes changes you want to understand before deciding whether to keep them. Review the diff, then either continue or restore.Restoring checkpoints
Click Restore next to any step to open the restore menu. You have three options:| Option | What it does | When to use it |
|---|---|---|
| Restore Files | Reverts your project files to the snapshot at this checkpoint | Code changes broke something but the conversation is still productive |
| Restore Task Only | Deletes conversation messages after this point, does not touch files | Code changes are good but the conversation went off-track |
| Restore Files & Task | Reverts files and deletes messages after this point | Starting over completely from a known-good state |
Choosing the right restore option
The code broke but the conversation is useful
The code broke but the conversation is useful
Use Restore Files. Cline keeps all the context from your conversation and can try a different implementation approach without you needing to re-explain the goal.
The code is good but the conversation went off-track
The code is good but the conversation went off-track
Use Restore Task Only. Your file changes are preserved and you can guide the conversation in a different direction from that point.
Everything went wrong — start over
Everything went wrong — start over
Use Restore Files & Task. This resets both files and the conversation to the checkpoint, giving you a clean slate from a known-good state.
When to use checkpoints
| Scenario | Recommended action |
|---|---|
| Cline refactored code and broke something | Restore Files, ask for a different approach |
| Experimenting with multiple solutions | Compare each checkpoint, restore to the best one |
| Cline misunderstood your intent | Restore Files & Task, rephrase your request |
| You want to try a different prompt | Restore Task Only, keep the files, resubmit |
| Reviewing changes before committing to Git | Use Compare to inspect, then commit manually |
| Testing risky changes | Let Cline proceed, restore if it fails |
Checkpoints and auto-approve
Checkpoints make auto-approve practical. Without checkpoints, auto-approve feels risky because Cline can make many changes before you notice a problem. With checkpoints, you can let Cline work autonomously and roll back if needed.Review the final result
Inspect the outcome once Cline finishes. Use Compare on any checkpoint to review what changed.