> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Change Stack
> 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.
export const EarlyAccessBadge = ({tip = "This feature is in early access. Enable it by setting `early_access: true` in your `.coderabbit.yaml`, or by toggling Early Access on the web interface.", title = "Early Access", cta = "View configuration", href = "/reference/configuration#param-early-access", disabled = false}) => {
return
{title}
;
};
export const AzureBadge = ({tip = "This feature is available on Azure DevOps.", title = "Azure", cta, href, disabled = false}) => {
return
{title}
;
};
export const BitbucketBadge = ({tip = "This feature is available on Bitbucket.", title = "Bitbucket", cta, href, disabled = false}) => {
return
{title}
;
};
export const GitLabBadge = ({tip = "This feature is available on GitLab.", title = "GitLab", cta, href, disabled = false}) => {
return
{title}
;
};
export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => {
return
{title}
;
};
|
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.
## Review a pull request
Every CodeRabbit review comment carries a **Review Change Stack →** button above the [walkthrough](/pr-reviews/walkthroughs). You can also open Change Stack from [Triage](/triage) or from a link a teammate shares.
Start with **Overview** to see the change summary, merge readiness, and items that need your attention.
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](/change-stack/navigation).
Inspect the relevant diffs, then use **Needs your attention** and the finding filters to decide what matters. See [Read changes](/change-stack/reading-diffs) and [Understand findings](/change-stack/findings).
Open chat from a layer, file, or range to ask about the code in front of you. See [Ask about the change](/change-stack/chat).
Comment, submit your review, apply an eligible suggestion, or merge when your provider supports the action. See [Review and merge](/change-stack/reviewing) and [Provider support](/change-stack/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.
## How a change is structured
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.
### How the layers are chosen
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](/configuration/path-instructions) 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](/change-stack/snapshots) covers it in full, including which capabilities are pinned and which are live.
## Availability
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](/management/plans) enables it, and **Coding Agent 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](/change-stack/provider-support) for the full matrix.
## The rest of this section
Move between views, layers, and files; search the artifact; track what you have read; and share a link that points where you mean.
Semantic and line diffs, context expansion, blame, Code Peek, rendered diffs for prose and images, and the appearance settings that persist.
What each finding label means, what needs your attention first, how merge readiness is assessed, and how findings resolve across review runs.
Write a review under your own provider identity, apply suggestions, and merge or enqueue the pull request.
Put questions to CodeRabbit about the layer, file, or range in front of you.
Carry a review into a chat destination and keep it fed with pull-request events.
Which review run you are reading, when to move to a newer one, and exactly what is pinned versus live.
What GitHub, GitLab, Bitbucket, and Azure DevOps each offer, and where they differ.
## What's next
See how the walkthrough comment structures every review and feeds the layer summaries in Change Stack.
Prioritize your pull request queue and open the changes that need attention directly in Change Stack.