What a snapshot is
Two pairs of identifiers are in play. A provider repository and a pull-request locator identify the change you are reviewing. A review-run identifier and a head commit identify the snapshot you are looking at. Every completed review run against a new head produces a new snapshot, and earlier snapshots are retained rather than replaced. So a pull request that has been reviewed five times has five artifacts you can open, each a frozen record of what CodeRabbit saw at that commit: its diff, its layers, its findings, its summaries, its Blast Radius and Architecture Impact graphs. That retention is the point. When someone pushes a small follow-up commit while you are halfway through a review, the material you were reading does not shift under you, and you can go back and see exactly what a finding was pointing at when it was raised.Why the pinned-versus-live split matters
The two halves diverge as soon as the branch moves. Reading is safe: an old snapshot renders exactly as it did when it was produced, because it is a stored artifact rather than a live query. Acting is not, because the provider only has one pull request and it is at the current head. When you submit a comment anchored to a line that has since been rewritten, the provider decides where — or whether — that comment lands. When you merge, you merge whatever is on the branch now, not what you were reading. Change Stack handles this by refusing rather than guessing. The merge control declines a stale artifact instead of merging something you have not seen, and freshness state tells you when the displayed snapshot no longer matches the live head. Your part is to notice the signal and switch snapshots before acting.What is pinned and what is live
The rule covers almost everything: what you read is pinned to the displayed snapshot; what you write goes to the live pull request. So the whole reading surface — the diff and its layouts, Overview, Blast Radius, Architecture Impact, Code Peek, browser search, range summaries, viewed-file progress, re-review comparison, the links you copy, public share links, and a chat thread — all belong to the snapshot you have open, and none of them change when someone pushes. Regeneration requests behave the same way: a summary refresh, a graph rebuild, or a re-review is asked for on the snapshot you are looking at. They are queued rather than immediate, and the displayed snapshot only changes once the work has actually succeeded — see Findings. A handful of capabilities sit on the boundary, and those are the ones that catch people out.
One capability ignores the snapshot entirely: marking a draft ready for review acts on the live pull request whichever snapshot you happen to have open.
And some things have no relationship to snapshots at all, behaving the same whichever artifact is in front of you: theme, syntax theme, code font and diff presentation; the command palette and responsive navigation; autofix mode; pull-request event subscription; and the layout, filtering and interaction preferences kept for a signed-in reviewer.
The snapshot selector
The selector lists at most 25 stored snapshots for a pull request. A long-running branch with more review runs than that will not show its earliest artifacts. The same bound applies when a snapshot is resolved by commit rather than picked from the list: resolution examines at most 25 stored snapshots, so one that sits further back in history can fall outside resolution even though it still exists.Freshness
Freshness state tells you whether the artifact you are reading still matches the live pull-request head, and offers you a newer snapshot when one exists. Treat a stale indication as a prompt to switch before you act, not merely as a note about age — reading a stale snapshot is fine and often deliberate, acting from one is where things go wrong.Review progress and invalidation
While a review run is in flight you can follow its progress, and when a run completes it invalidates the displayed snapshot so you can refresh to the artifact that run produced. Findings covers review progress, re-review comparison, and regenerating stale material in depth.What a shared link does
A Change Stack link without explicit snapshot parameters follows the latest snapshot rather than preserving what the sender was looking at, so a link you paste into a review thread today can show a colleague different findings against different code next week. Include the review-run and commit parameters when snapshot identity matters. Navigate a change covers building links, including that one.Acting while an older snapshot is displayed
Two actions behave differently when the live head has moved past the artifact you are reading. Merging. The merge control refuses a stale artifact rather than merging commits you have not seen. Switch to the latest snapshot first, read what changed, then merge. Reviewing covers the merge control and merge queue in full. Provider review writes. A comment or review prepared against an older snapshot can be rejected by the provider, or anchored to a different location, because the lines it references no longer sit where they did. Switch to the latest snapshot and recreate the pending action rather than trying to submit the stale one.Chat is pinned to where it started
A chat thread stays on the review run and commit where it began instead of following later snapshots, so a long conversation keeps answering about the change as it stood when you opened it. See Chat.How the displayed stack was produced
A stack reaches you one of three ways, and it is a useful trust signal when something looks thin. Generated is the normal path. Generated and repaired means the generated stack needed repair before it could be used. Synthetic means a stack was substituted for a missing generation result — it stands in for review material that was never produced, so treat its contents as incomplete rather than as a finding-free result, and use re-review recovery to regenerate.What’s next
Understand findings
Follow review progress, compare snapshots, and regenerate material that has gone stale.
Review and merge
Write comments, apply suggestions, and merge against the live pull request.