🐰 New: Triage — a self-updating cross-repository queue that prioritizes pull requests by value and risk, so you always know what to review next. Now in beta! Explore Triage →
Change Stack is CodeRabbit’s review workspace: it turns a pull request into a structured, navigable artifact you can read, question, and act on in one place.
| A pull request arrives as a flat list of files in alphabetical order, and nothing about that order reflects how the change was built or how it should be read. Change Stack is CodeRabbit’s review workspace: it takes the same pull request and presents it as a structured artifact — grouped into coherent areas, ordered so foundations come before the code that depends on them, with every finding, summary, and graph anchored to the exact lines it is about. You read the change, ask questions about it, and comment, approve, or merge without leaving the page.
Every CodeRabbit review comment carries a Review Change Stack → button above the walkthrough. You can also open Change Stack from Triage or from a link a teammate shares.
The "Review Change Stack →" button in a CodeRabbit review comment
1
Open the overview
Start with Overview to see the change summary, merge readiness, and items that need your attention.
2
Choose how to move through the change
Use the layer rail for the intended reading order or switch to the file view when you already know where to look. See Navigate a change.
3
Read the changes and findings
Inspect the relevant diffs, then use Needs your attention and the finding filters to decide what matters. See Read changes and Understand findings.
4
Ask for context when you need it
Open chat from a layer, file, or range to ask about the code in front of you. See Ask about the change.
5
Finish the review
Comment, submit your review, apply an eligible suggestion, or merge when your provider supports the action. See Review and merge and Provider support.
Using Change Stack is voluntary. A teammate who prefers their provider’s own review interface can ignore the button and keep reviewing there.
Change Stack builds the pull request into a stack of numbered layers. A layer is a checkpoint in the change — a coherent step, with the files and review context that belong to it. Inside a layer are the changed files, and inside those are ranges: spans of source lines that carry a summary, a finding, or a review anchor.The range is the level that makes the rest work. Because summaries and findings attach to source spans rather than to whole files, Change Stack can put a summary beside the lines it describes, jump from a finding on a dependency graph to the code that produced it, and tell you whether that finding is still open three pushes later.
CodeRabbit reads the change and groups it, rather than splitting it by file or folder. A layer is meant to be a step a developer would recognize — a contract and the code that implements it and the tests that cover it belong in one layer, not three — and the layers are numbered in the order someone would explain the change, which is roughly the order it was built rather than commit order or diff order. Where one layer genuinely depends on another, that relationship is recorded rather than inferred from the numbering.Two consequences are worth knowing. File and directory boundaries are treated as evidence, not as rules, so a layer can span directories and a single directory can split across layers. And because the grouping is produced by a model as part of the review, it is fixed for a given snapshot but can legitimately come out differently when a later review run regenerates it — CodeRabbit is asked to keep titles and ordering that still hold, not guaranteed to.
Change Stack shows CodeRabbit’s review scope, not necessarily every file on the pull request. Files excluded by default ignore rules or by configured path filters do not appear in layers or file counts.
What you read is a snapshot; what you act on is live
This is the one idea worth carrying into every other page.Change Stack displays a snapshot — one completed review run against one head commit — and keeps earlier snapshots rather than replacing them. Everything you read comes from the snapshot you have open. Everything you do — submitting a review, applying a suggestion, merging — targets the live pull request as it exists right now.Those two things diverge the moment someone pushes. That gap is not an implementation detail leaking through; it is the reason the merge control refuses a stale artifact, the reason a chat thread keeps answering about the change as it stood when you opened it, and the reason a link you paste into a review thread may show your colleague a different snapshot next week. Snapshots and freshness covers it in full, including which capabilities are pinned and which are live.
Change Stack is on by default. There is no plan to upgrade to and no flag to switch on — if CodeRabbit reviews your pull requests, the artifact is generated and the button is there. Being enabled is not a promise that every artifact is complete: a generation step can fail or still be running, and Change Stack says so rather than presenting a thin result as a finished one. It is supported on GitHub, GitLab, Bitbucket, and Azure DevOps, and self-hosted GitHub, GitLab, and Azure DevOps instances count as their cloud counterparts. A small number of Azure DevOps organizations are excluded from it; if the button never appears for your organization on Azure DevOps, that is the reason.The interface labels Change Stack a preview. It is on for everyone, and it is still changing.Two capabilities inside Change Stack carry their own gates rather than following the feature: chat is offered when your organization’s plan enables it, and tasks are offered when your plan, your repository write access, and the provider connection all allow it. You can have one without the other.
Azure DevOps Change Stack artifacts are read-only. You can read the change, the findings, and the graphs, but no live action — commenting, submitting a review, applying a suggestion, or merging — is offered there. See provider support for the full matrix.
