“View Changes” feels like a normal diff. It isn’t. Under the hood, Cline is running a clean, task-scoped Git history in a hidden checkpoint repo — and it can be reproduced exactly.
The moment it stopped being “just a diff”
<img src="https://media.daily.dev/image/upload/s--2hZLwtKG--/f_auto/v1770497646/ugc/content_85f16040-9784-49fc-a05c-21e9f31e73b6?_a=BAMAMiiu0" alt="image">
<img src="https://media.daily.dev/image/upload/s--HZElZ9Vy--/f_auto/v1770497658/ugc/content_8b013683-33b2-4a69-9c58-7f4ee06af73c?_a=BAMAMiiu0" alt="image">
Cline’s View Changes looks like the usual story: a file list, hunks, additions, deletions. The kind of UI that makes it feel safe to assume the engine is git diff somewhere in the background.
Then the logs quietly drop a detail that doesn’t belong in a normal UI narrative: checkpoint_created, followed by lastCheckpointHash — a 40-character SHA that looks exactly like a Git commit id.
That’s the pivot. Because once a commit hash exists, the question becomes: Which Git repo does this hash exist in? And the answer is: not the workspace repo.
Two parallel realities: the workspace repo vs Cline’s repo
To understand View Changes, it helps to think in two worlds:
The workspace repo: the Git repo opened in VS Code. Branches, staging area, untracked files, unrelated edits — the full human mess.
Cline’s checkpoint repo: a separate, hidden Git repository that Cline maintains under VS Code’s global storage. It exists specifically to snapshot the workspace state during a task.
This is why View Changes doesn’t require a clean working tree. It doesn’t even require the workspace to be a Git repo at all. Cline wants a stable way to say: this is what the task did, step by step. Git already has the perfect model for that, so Cline uses Git.
What a “checkpoint” really is
A checkpoint isn’t a vague “save state.” It is a real commit inside the checkpoint repository.
That means each checkpoint has a commit SHA (what appears as lastCheckpointHash), a tree snapshot (what the workspace looked like at that moment, from Cline’s perspective), and a position in a commit chain. Conceptually, a task becomes a small, controlled history:
base → C0 → C1 → C2 → C3
Each Ci is a Git commit created when Cline makes a checkpoint.
So what is View Changes actually diffing?
In practice, View Changes maps to one of two diffs.
Step diff: previous checkpoint → current checkpoint
This answers: What changed since the last checkpoint?
Mechanically: diff(Ci-1, Ci)
This is the incremental view — useful when iterating and wanting to see the delta from the last Cline action.
Task diff: baseline → last checkpoint
This answers: What did the entire task do?
Mechanically: diff(baseline, Cn)
Here’s the subtle part: the baseline is usually not C0. It’s typically the parent of the first checkpoint, i.e. C0^.
Why? Because C0 already contains edits; to represent “before the task,” the baseline has to be the commit immediately before the first checkpoint’s snapshot.
So the “task diff” form is: diff(C0^, Cn)
That is the view that feels magically task-scoped.
Why it stays stable even when the workspace is messy
Because the diff isn’t computed from the workspace working tree.
It’s computed from two checkpoint commits inside Cline’s controlled history. That means untracked junk doesn’t matter. Whatever branch is checked out doesn’t matter. Staged-but-not-committed changes don’t matter. Unrelated edits don’t leak into View Changes.
The system is effectively saying: ignore the outside world; here’s the ledger of this task’s edits.
Where the checkpoint repo lives
On Windows with VS Code stable, Cline’s storage is under the VS Code global storage directory. Checkpoints are stored under a workspace-id folder, and inside it lives a hidden .git directory. The important operational detail: .git can be hidden, so listing folders often requires dir -Force (PowerShell) to see what’s actually there.
The practical payoff: exporting a clean patch
Once it’s clear that View Changes is “just” a Git diff inside a checkpoint repo, a new capability appears:
A task’s result can be exported as a real patch file — reproducible, reviewable, attachable to tickets, and independent of the workspace’s current state.
And it can be made clean by excluding noisy build artifacts (for Rust/Tauri, the classic culprit is src-tauri/target).
This matters because View Changes can include build noise depending on what happened during the run: compilation can touch target/, codegen can rewrite schema files, and lockfiles can churn. A clean patch is the version of the story that reads like intent.
The gotcha everyone hits: build artifacts
If the export doesn’t exclude build outputs, diffs can contain fingerprints and compiled artifacts — especially under target/. That’s not “Cline changed the code.” That’s “the build pipeline touched files and the checkpoint snapshot captured them.”
Treat clean patch export (with exclusions) as a first-class step.
A real example patch (sanitized)
Below is a real patch exported from a Cline task (URLs redacted to <a href="http://example.atlassian.net" target="_blank" rel="noopener nofollow">example.atlassian.net</a>). Notice how it reads like one coherent unit of work: add the Tauri shell plugin, update capabilities, tag an API route, and add a UI action to open a Jira issue in Chrome.
It touches:
package.json / package-lock.json (plugin dependency)
src-tauri/capabilities/default.json (permissions)
src-tauri/tauri.conf.json (plugin scope)
src-tauri/src/api/handlers.rs (OpenAPI tags)
src/modules/jira-details/JiraDetailsPanel.svelte (open-in-chrome action)
Appendix: minimal reproduction (PowerShell concepts)
At a high level, reproducing View Changes requires three steps:
Extract lastCheckpointHash from Cline task logs.
Locate the checkpoint repo that contains that commit hash.
Run a Git diff inside that checkpoint repo.
Then decide which diff mode is desired:
incremental (previous checkpoint → current checkpoint)
full task (parent of first checkpoint → last checkpoint)
Finally, exclude noise paths (e.g., src-tauri/target) when exporting a patch meant for humans.
Takeaways
View Changes is not a window into the workspace working tree. It’s a diff inside a hidden checkpoint Git repo that Cline builds from task checkpoints. That’s why it’s task-scoped, stable, and exportable. Once it’s treated like Git, it can be automated like Git.

oleksandr buzunov

Cline's "View Changes" feature operates through a hidden Git repository that maintains task-scoped checkpoints, separate from the workspace repo. Each checkpoint is a real Git commit with a SHA hash, allowing Cline to generate clean, stable diffs that exclude workspace clutter like untracked files or unrelated edits. The system enables two diff modes: incremental (previous to current checkpoint) and full task (baseline to final checkpoint). This architecture allows exporting reproducible patches independent of workspace state, though build artifacts should be excluded for clean output. The checkpoint repo lives in VS Code's global storage and can be accessed directly using Git commands.

The Unseen Commit: Cline’s Shadow Workflow Explained