CodeRabbit Release Notes

CLI v0.8.0

Deep review: Added cr review --deep.

Included-review availability: Run cr usage to see available included reviews, the rolling window, and when capacity returns. Add --agent for structured output.

Continue local work in the cloud: Run cr handoff --summary /path/to/SUMMARY.md to create a new CodeRabbit Cloud task from your committed and pushed branch. Pass --summary - to read the summary from standard input, and add --plan /path/to/PLAN.md to include an implementation plan.

Bring session context: Handoff supports up to 25 MiB per file and automatically includes an available Codex or Claude Code transcript for the current session. An unavailable or failed optional transcript upload does not block the handoff.

Clearer agent sign-in: Agent login presents the browser URL while the callback is live and explains how to restart an expired attempt.

Accurate oversized-review errors: Errors report file sizes only when the size is known, while retaining guidance to reduce the review scope.

Run cr update to update your CLI. See cloud coding commands for setup, transcript behavior, and retry guidance.

Original source

CLI v0.8.1

Continue local work in the cloud: Use cr code handoff --summary <path> to start a new cloud Coding Agent task with your session summary, an optional plan, and an automatically discovered transcript when available.

Clearer handoff results: See transfer progress, the branch and commit, transferred filenames, and a direct link to the cloud task. The existing cr handoff command remains supported, but its human-readable output has changed; update scripts that parse the previous output.

Cloud skill import preview: cr code skills import imports local skills into the cloud library. This requires a CodeRabbit user login and Coding Agent access for the selected organization.

Run cr update to update your CLI. See cloud coding commands for usage and requirements.

Original source

Share TypeScript configuration from another repository

Programmatic .coderabbit.config.ts files can now load shared fragments from an authorized repository selected with includeRemote({ repo, path, ref? }). Omit repo to keep using your organization's central coderabbit repository.

CodeRabbit's provider connection must be able to read the selected repository. When a pull or merge request's head configuration selects it, CodeRabbit also verifies that the request author and the distinct human actor who started the review can read it.

See TypeScript configuration for repository formats and access requirements.

Original source

CodeRabbit Triage

CodeRabbit Triage is a single queue of every open pull request your organization is tracking, across repositories, ordered by what each one needs next and what acting on it is worth. It is built for reviewers, code owners, maintainers, and team leads who have more pull requests in front of them than review hours.

Priority with its evidence: Every card carries a priority from P0 to P3 and a short reason for its rank. Priority reflects issue severity, the priority of a linked Jira or Linear issue, and how much other work is blocked behind the pull request. Failing checks and merge conflicts decide the next action rather than making a pull request urgent. See How Triage prioritizes.

Your rules and your judgment: Administrators describe in plain language how their organization wants pull requests ranked, and CodeRabbit turns that description into priority rules. When you know something the evidence does not, set a priority yourself.

Views that fit how you work: Start from Requires my action, All PRs, or Close candidates, then narrow and arrange the queue with search, filters, grouping, and list or board layouts. Keep the setups you use as personal saved views. See Your Triage view.

Act from the card: Start a CodeRabbit review, fix CI or merge conflicts, run Auto Fix, refresh a branch, request reviewers, merge, or set a priority without leaving the queue. Actions that write to GitHub run as you, with your own permissions. See Actions on a pull request.

Clear out stale work: Close candidates collects pull requests that look duplicated, superseded, abandoned, or too far behind their base to apply. Triage never closes one by itself; close it with a comment, or tell CodeRabbit the recommendation was wrong.

Triage in Slack: Get the top of your queue in a Slack digest once or twice a day, send reviewer requests as direct messages, act on pull requests from message buttons, and follow a pull request in its own Slack thread. Slack delivery is rolling out gradually. See Triage in Slack.

Triage requires GitHub Cloud and the Team plan or higher, and you need an active Review seat to open it. See Requirements and FAQ for details.

Open Triage at app.coderabbit.ai/triage, or see the Triage documentation to get started.

Original source

What a sorted list can’t tell you

AI coding tools and agents make it faster to produce code and open pull requests. As those requests accumulate, teams have to decide which changes need attention first. That starts with understanding what each PR needs next and who can move it forward.

That is the problem we set out to solve with CodeRabbit Triage. We started by organizing the queue, but quickly realized it was only useful if we could clearly see where each PR stood.

An inbox concept is a natural starting point for organizing a PR queue. Some tools group open pull requests into sections, giving reviewers one place to see work that needs their attention.

We began with a similar approach, but our filters sometimes labeled PRs as needs review for people who had already approved them. We also surfaced approved PRs with merge conflicts as though they needed another review, even when the next step was for the author to rebase.

Those PRs matched the filters we had written. The problem was what the label told the reviewer to do. Someone would open a PR expecting to review it, only to discover that the next action belonged to its author.

Repeated mistakes like that give reviewers a reason to question the queue. The extra work of opening each PR to check its status before deciding whether to act undermines the usefulness of the inbox.

We needed to establish what each PR needed next and who was responsible for it before deciding where it belonged in the queue.

Deciding what a PR needs next

To do that, we first had to clarify what each part of the system was responsible for deciding. Early designs treated buckets, lifecycle stage, priority, health, readiness, next action, and ownership as separate concepts, but their responsibilities sometimes overlapped.

Those overlaps became clearer during implementation. A PR can be high priority even when no one can act on it yet. The interface had to explain both its priority and what was holding it up.

We separated workflow classification from comparative ranking because they serve different purposes.

• Workflow classification determines what the PR needs next. Explicit rules evaluate the available evidence to establish the workflow state, next step, responsible role, and whether an action or review is overdue. These decisions are made without an AI model.
• Comparative ranking determines the order of attention. Once workflow states are established, ranking helps decide which PRs to look at first and how deeply to review them. It cannot change their workflow states.

The classifier checks the following rules in order and selects the first match:

1. Closed or untracked → untracked
2. Strong retirement evidence, after close protections → close_candidate
3. High explicit risk or duplicate/superseded evidence → needs_decision
4. Requested changes, unresolved threads or stale approval → needs_update
5. Merge conflicts → blocked
6. Base drift → needs_update
7. Draft status → needs_update
8. Failing required checks → blocked
9. Missing current review or stale reviewer attention → needs_review
10. Otherwise choose the highest-utility action: merge, author update, reviewer action, refresh, revive, close, monitor or watch.

Human judgment about whether a PR should proceed takes precedence over mechanical fixes, which is why needs_decision comes before blocked. If a PR duplicates work that has already merged, the team should decide whether to keep it before spending time resolving its conflicts. Requested changes also come before detected conflicts because reviewer feedback provides a more specific next step.

The classifier records every applicable reason, even though it selects the workflow state from the first matching rule. It then identifies one next action and one responsible role. With those established, ranking determines where the PR belongs in the queue.

Why "Other" still exists

Even with those rules, some PRs need a fallback category. In our case, Other was often mistaken for a low-priority score. It is a review workflow label the system uses when current evidence cannot support a more specific handoff.

When Triage cannot derive an action label from the review record for the latest reviewable commit, it falls back to the PR's workflow state:

• needs_review becomes Not reviewed by CodeRabbit when no completed CodeRabbit review is recorded for that commit; otherwise, it becomes Awaiting your review.
• needs_update, blocked, and needs_decision become Waiting on author.
• All remaining states, including monitor and close_candidate, become Other.

Other also covers situations where no action label accurately describes what should happen next. Pending checks are one example. A PR may be waiting for checks to finish before it can merge, with no author action required while they run.

Keeping Other makes those limits visible. A more specific label needs supporting evidence; otherwise, we risk sending reviewers or authors back to address work that requires no action from them, which is the same problem people encounter with the PR inbox concept.

How priority is computed

Triage uses priority levels from P0 to P3. Its base score is calculated from verifiable evidence about the PR using deterministic rules, so the same inputs produce the same result. The displayed priority can also reflect administrator rules, a CodeRabbit verdict, or a manual override, as described in the prioritization documentation.

The calculation uses three signals.

• Severity - How serious the current, validated review findings are
• Urgency - How urgent a linked Linear or Jira issue is
• Impact - How many other open PRs are blocked waiting on this one

Each signal is normalized to a value between 0 and 1, and a missing signal contributes zero. We combine them so that one strong signal can produce a high priority on its own, several moderate signals reinforce each other, and adding positive evidence never lowers the score.

function computePriority(s: PrioritySignals): Priority {
  const impact = combine(s.severity, s.externalUrgency, s.dependencyImpact);
  const score = Math.round(100 * impact);
  const bucket = toBucket(score);
  // Internal signals alone can't declare an emergency.
  if (bucket === "P0" && !s.hasQualifyingExternalEvidence) {
    return { bucket: "P1", score: 84 };
  }
  return { bucket, score };
}

We tune the curves and weights behind the calculation. The resulting score maps to the four priority levels shown below.

Priority helps reviewers decide which PR to look at first. Workflow status tells them what needs to happen next. For example, a P1 PR might fix an urgent problem while still needing its author to resolve a merge conflict or fix failing checks. Those blockers appear in its workflow status and are handled separately from its priority score.

Missing evidence needs particular care, because an unreviewed PR can receive a P3 score.

The PRs nobody had looked at

Every priority model has to decide what to do with a PR that has no review findings, no linked issues, and no other PRs depending on it. We treat each missing signal as zero, which gives us this result.

severity: 0 // no validated review findings yet
externalUrgency: 0 // no linked issue
dependencyImpact: 0 // nothing blocked on it
score = 0 →  P3

The math is straightforward, but the result is easy to misread. A reviewer might see P3, assume the PR is low priority, and take that to mean someone has checked it and found little reason for concern.

That creates a problem. A PR with evidence of moderate impact can rank above one that nobody has evaluated at all. The unreviewed PR gets a lower score because evidence is missing.

One tempting fix is to invent a number here. We kept the score tied to the available evidence.

• P3 reflects the available priority evidence - It means the scoring signals have yet to establish an elevated near-term priority. A P3 PR may still be valuable and need careful review.
• Evidence expires - Review findings are tied to the version of the PR they were evaluated against. When a new commit arrives, the stale severity contribution is removed until current evidence is available.
• Review status stays visible alongside priority - Whether anyone has reviewed the PR, who has approved it, whether it is waiting on its author, and whether checks pass or merge conflicts exist are recorded in separate fields. Reviewers can see both its priority and what needs to happen next.

Each contribution to the score traces back to evidence a reviewer can inspect.

The model

CodeRabbit Triage uses a repository-level model to compare PRs. It considers value relative to remaining effort, time sensitivity, information value, rework risk, dependency order and the amount of human judgment each change needs.

Two PRs can have similar checks and activity, while one unblocks a release or tests an assumption that several other changes depend on. The model considers those differences when ranking them.

The model returns a repository-local rank, an advisory urgency assessment, recommended review depth, a short explanation, and relationships between PRs. These ranking and review-guidance outputs do not feed the deterministic base score through an attention adjustment.

The displayed P0–P3 priority follows a separate precedence: manual overrides take priority over a CodeRabbit verdict, which takes priority over administrator rules and the base score. The base score and verdict are recomputed when evidence changes, rather than on a fixed timer. See how Triage prioritizes for the current behavior.

Deterministic code controls workflow state, next action, readiness, eligibility, permissions, and any action that changes the PR or sends a notification. Keeping those controls separate from ranking and review guidance preserves the routing that identifies who acts next.

Each person sees a personalized queue and a next action tailored to their role. A separate attention score determines where a PR appears for that person using these signals:

• Who owns the next action
• How long a handoff has been waiting
• Recent activity
• Waiting pressure
• Engagement
• Impact
• Review effort

Repository rank and model output are excluded from this calculation. A PR rises in a person’s queue according to their responsibility for it and the pressure to act.

That responsibility extends to taking action. Triage can suggest reviewers and explain why it selected them. Requesting a review, pinging someone in Slack, or changing the PR’s state in the connected platform requires an explicit human action.

The interface

Once the state model was settled, we designed the interface around grouping, subgrouping, filters, display properties, and saved views. These controls let users organize the queue around the question they need to answer.

The first axis - grouping

Triage gives reviewers a focused way to prioritize and work through that queue.

• Workflow - See which PRs are awaiting review, need author follow-up, or are ready to merge
• Author - See whose PRs are waiting and what is holding them up.
• Repository - See where work needs attention across repositories.

The second axis - subgrouping

Subgrouping adds another level of detail within each group. Group by Priority, then subgroup by Review workflow, and the P1 group separates into PRs awaiting human review, awaiting CodeRabbit review, requiring author action, or ready to merge.

That gives you a practical starting point for the morning. You can pick up high-priority reviews assigned to you, see which PRs need their authors’ attention, and check what is ready to merge.

For a different view, group by Review workflow and subgroup by Review guidance. Filter for Awaiting human review, and you can separate PRs recommended for a quick review from those likely to need more uninterrupted time.

These views depend on consistent information about each PR. A PR marked P1 and awaiting human review should show the same priority and status wherever it appears. Changing the grouping changes how you see that information; the PR’s underlying state stays the same.

Grouping organizes, filters narrow the queue

We began this project with filters doing both jobs, but that quickly became difficult to manage. Filters determine which PRs stay in view. Grouping arranges those PRs so reviewers can see what needs their attention.

For example, you can filter to one repository and then group its PRs by workflow to see which are awaiting review and which need author action.

Remember your setup with views

Once you have configured your Triage board or list, save it as a view. A view keeps the filters, groupings, layout, and ordering so you can return to the same setup without rebuilding it each time.

Where Triage fits into Agentic Change Management

CodeRabbit Triage addresses one part of a larger problem. As agents make implementation cheaper, teams receive more proposed changes than they have time to validate and understand. They still need to take responsibility for the code they accept.

Agentic Change Management brings those responsibilities into a shared workflow for changes created by people and agents. It starts with independent review and validation, helps teams prioritize human attention, explains how changes affect the codebase, and extends security analysis to committed code.

Triage handles prioritization and identifies the next action for each PR. It answers two questions:

• What needs attention now and why?
• Who should act on it?

The reviewer can then see why a PR has reached them, what it needs, and the evidence behind that recommendation before deciding how to proceed.

See what needs your attention next

CodeRabbit Triage shows each PR’s current state, who owns the next action, how long that action has been waiting, and the evidence behind its priority. You can see why a PR is near the top of your queue and what you’re being asked to do.

CodeRabbit Triage is available now. Open your queue to see which PRs are waiting for your review, which need an author’s follow-up, and which are ready to merge.

Original source

CLI v0.7.8

More reliable large reviews: Reviews avoid duplicate file content and report oversized requests with guidance to reduce the review scope.

Smoother branch detection: Git branch detection avoids interactive credential prompts that can stall reviews.

Clearer agent login guidance: Agent login explains how to use an API key or a reachable browser when automatic browser login is unavailable.

Visible unverified findings: Unverified findings remain available for inspection, without AI fix prompts, and are counted separately.

Responsive retry prompts: Review retries restore terminal input before asking to use credits.

Clearer sign-in errors: Sign-in reports network and organization lookup failures more clearly.

Verified installer downloads: The Unix installer pins each download to one release and rejects ZIP archives with mismatched checksums.

Security Review attribution: Findings show when they were analyzed with Security Review, including in agent output.

Run cr update to update your CLI. See the CLI documentation and command reference for details.

Original source

Dynamic CodeRabbit configuration with TypeScript

Define CodeRabbit settings in a programmatic .coderabbit.config.ts, with PR-aware conditions, reusable merged fragments, local TypeScript/YAML includes, and shared includes from the organization’s coderabbit config repository! The optional @coderabbitai/config SDK provides editor autocomplete and type checking, while configuration factories can adapt settings to pull request metadata and distinguish local CLI runs from hosted reviews.

TypeScript configurations can compose local files and shared fragments from the central coderabbit repository. Existing YAML files keep precedence when both formats are present.

See TypeScript configuration for setup, composition APIs, evaluation limits, and the CLI invocation example.

Original source

Before reviewers read a line of code, they have to decide which pull request deserves their attention. That choice gets harder when agents add work faster than teams can assess it and the queue offers little context about urgency, risk, or ownership.

We built CodeRabbit Triage to bring that context into the queue, helping each reviewer identify where their attention is needed and what action will move the work forward.

Code generation isn’t scarce anymore

Agents can open pull requests faster than teams can review them. They also make it easier to try several implementations of an idea. Some engineering leaders are already asking whether creating issues makes sense when an agent can just open a PR.

Cheap experimentation is a real gain, but it stops being cheap the moment it becomes a pull request. An unnecessary PR can consume investigation and review time even if it never merges.

If it does merge, it carries maintenance obligations, regression risk, and architectural consequences that outlast the minutes it took to generate.

Deciding which problems are worth solving remains upstream work, and agents don’t change that. What has changed is the volume and variety of proposed changes arriving as pull requests. When several agents are working at once, the engineer overseeing them still has to decide:

• Does this PR need attention now, or can it wait?
• Who should handle it, an agent or a human?
• How much scrutiny does it warrant?

Those decisions have to be made deliberately and at a pace the team's review capacity can actually sustain.

Taste is still human

Judgment never moved to the machines. An agent can check its own work and report that a change is correct. That does not answer whether the abstraction it just introduced will make sense in your app architecture a few months from now. That is still a human call.

As agents take on more implementation work, teams face a wider range of decisions that require human judgment. Trust isn’t binary. Teams are continually deciding which work can remain with an agent and which changes need human scrutiny.

Treating every agent-authored PR alike wastes attention on routine changes and risks giving consequential ones too little scrutiny. Calibrating review depth is a recurring judgment call, and it depends on evidence.

Teams still have a limited budget for human judgment, and the agentic era has not removed that constraint.

Why flat lists fail

As teams adopt agents, throughput goes up, and engineers soon find themselves working from a long list of open PRs with little sense of priority, impact, or how much effort each review will take.

A complete list can still be a poor guide to action. That's because every PR requires reviewers to ask a series of questions: is this urgent, is it mine, and how long will it take? Multiply that by the number of PRs coming in, and a large share of the day goes to sorting instead of reviewing. It also becomes easy to treat the most recent PR as the top priority simply because recency is the clearest signal the list provides.

Inboxes only partly solve the problem. Some tools group PRs into sections, which may make the list easier to scan, but they still leave these important questions unanswered:

• What matters?
• What can be cleared in five minutes?
• What needs an hour of focused review?

We learned this early on while building CodeRabbit Triage. The queue needs to do more than organize open PRs. It needs to help each reviewer decide what deserves attention and what to do next.

What we built instead

CodeRabbit Triage replaces FIFO ordering with scored priorities. When Triage has enough evidence, it assigns a PR a priority from P0 through P3. The score is deterministic, and the card explains why the PR ranks where it does using evidence reviewers can inspect.

Alongside its priority, each card shows high-level context about the change before a reviewer opens the PR.

Triage works at both the individual and team level. It surfaces the PRs that involve each person, along with the context they need to act. The same evidence also helps teams step back from individual changes and ask broader questions:

• Which release is blocked?
• Which area of the codebase is absorbing most risk?
• Which agent’s work keeps stalling in review?

We also tag each PR with signals such as security findings, review guidance, and reviewer match. This gives engineers an early sense of what the work involves and how to approach the review. Before opening the PR, they can see whether the change warrants closer investigation or another reviewer’s attention.

Shape the queue around the work

No two teams triage PRs exactly the same way. Some may run the queue from top to bottom by priority, while others work by repository. What someone needs from the queue also depends on their role. A tech lead may want to see who is blocked, while an individual engineer may only want to see what requires their attention.

Triage’s interface is designed to adapt to the user. You can group or sub-group PRs, apply the filters that matter to you, and switch between list and board layouts. Once the queue is organized the way you like, you can save that view and return to it the next day.

Now shows the highest-ranked PRs to focus on today. Next keeps the rest visible for later. For each PR, Triage identifies the next action needed to move it forward.

One layer of a bigger system

Triage is the prioritization layer of Agentic Change Management, CodeRabbit’s system for governing software change from both people and agents. As agents produce more code, the harder problem becomes deciding which changes should advance, what evidence they need, and how the resulting codebase stays healthy after merge.

For each open PR, Triage shows what is blocking it, who needs to act, what it depends on, and the evidence behind its priority. Triage doesn’t replace human judgment. It helps teams determine where that judgment is needed before they open a PR.

Start with your queue

As agents take on more implementation work, the PR queue becomes the handoff between the code they produce and the people responsible for what ships. A flat list is not enough for that job.

Try CodeRabbit Triage and see what rises to the top of your queue.

Original source

CLI v0.7.7

Review without a local clone: Use cr review --remote owner/repo --base main --source-branch feature to review an installed GitHub repository from any directory. See remote reviews for requirements and limits.

Configure reviews from the CLI: Run cr config to create or update repository settings with a preview before saving. Agent workflows can inspect settings and generate proposals with structured output. Local reviews also discover .coderabbit.config.ts when no supported YAML configuration is found. See configuration setup.

Clear earlier findings: Run cr review findings --clear to dismiss findings retained for the current review scope while preserving incremental review state. See stored review findings.

More accurate Git comparisons: Reviews combining committed and uncommitted changes use the net changes for the selected comparison. Committed-only reviews read file content and automatically discovered configuration from the Git snapshot.

Clearer failure reporting: Failed or incomplete reviews exit with code 1 while preserving received findings and the last successful review checkpoint.

Fresh context after base changes: Changing the comparison base resets saved review context. Checkpoints from earlier CLI versions reset once on upgrade.

Run cr update to update your CLI. See the CLI documentation and command reference for details.

Original source

Connections and scopes

Connecting CodeRabbit to issue trackers, documentation systems, analytics tools, and other external services used to mean setting up the same service separately for pull request reviews, Agent for Slack, and Agent for Discord. That setup is now unified: configure each connector once as a saved connection, then use scopes to control exactly where every product can use it, whether that's a repository for Review or a channel, conversation, or server for Slack and Discord.

A Base Scope defines each product's default connection access, and named scopes can inherit, exclude, or override it for specific repositories, teams, or sub-projects, so a security-sensitive repository or channel can be kept off a connection that the rest of the organization uses freely.

See the Connections documentation and Scopes overview for setup details.

Original source