Actions on a pull request

| Triage keeps the useful actions next to the queue, so deciding what to do and doing it are the same visit. They live on the card itself: the Next action button, the card’s action menu, the reviewer stack, and the check indicator. Manual Git-provider actions such as merging, closing, and requesting reviewers run as you, using your own Git-provider authorization and permissions. Repairs ask CodeRabbit to do the work. For recurring actions, configure Triage rules; automated GitHub actions use the organization’s CodeRabbit integration and require administrator authorization.

​

What each action needs

You need an active Review seat to open Triage at all — see Requirements and FAQ. The actions marked below also check for that seat each time they run. Without an active seat, Triage does not open for you, so ask an admin to assign one. See Seat assignment. An action also appears only when it is possible on that pull request — a repair only when there is something to repair, a close only on a pull request Triage can close as you. Where Triage cannot act directly, the card offers a link to open the pull request in your Git provider instead, so you are never left with a button that fails.

​

Open a pull request

Selecting a card opens it in Change Stack, where the change is broken into logical cohorts and layers with CodeRabbit’s findings attached. That is where the actual reading happens; Triage decides which pull request, Change Stack shows you what is in it. When Change Stack is not available for a pull request, the card offers a link to open the pull request in your Git provider instead.

​

Start a CodeRabbit review

Start review requests a CodeRabbit review of the latest reviewable commit. The card follows the review’s progress, and the item disappears while a review is already running so you cannot queue two. Once a review has run, the same control becomes Retry review if it needs to be run again. For what the review itself produces, see CodeRabbit’s pull request review workflow.

​

Repair a pull request

One item in the card menu offers whichever repair applies right now: The item’s label tracks the repair through its whole life, so the card tells you where a request got to without opening the pull request: Requesting fix…, then Fixing CI… / Resolving conflicts… / Auto-fixing…, then one of Fix requested, CI fix proposed, Conflicts resolved, Auto Fix proposed, Manual CI fix required, or Retry CI fix when it did not work. Repairs are offered only on open pull requests that CodeRabbit is tracking, and only when that specific repair applies.

​

Refresh a branch

When a branch has fallen behind its base, Refresh branch merges the base branch into the pull request’s branch. Unlike the repairs above, CodeRabbit does not do this for you: the merge runs as you, with your own GitHub authorization and permissions, and needs an active Review seat. It is available for open GitHub.com pull requests.

​

Merge a pull request

When a pull request is ready to land, the card’s next action is Merge. It appears on open, non-draft pull requests that you authored or are assigned to — or that a bot opened — when checks are passing, there are no conflicts, your Git provider reports the pull request as mergeable under its branch policies, and you can merge in that repository. Selecting Merge re-checks the pull request with your Git provider before anything happens, then asks you to confirm in a Merge pull request box. Triage merges only the commit you were shown: if someone pushed since, the merge is refused. On GitHub, when a branch uses a merge queue, the box is Add to merge queue instead, and GitHub merges the pull request when the queue reaches it. The button then reads Merged or Queued. On GitHub, there is no merge method to choose. Triage uses the first method the repository allows, in this order: merge commit, squash, then rebase. To use a different method, merge the pull request on GitHub instead. The merge runs as you, with your own Git-provider authorization and permissions. If your Git provider no longer considers the pull request ready — checks stopped passing, a branch protection rule blocks it (such as one requiring the branch to be up to date with its base), or you lack permission — the box explains why and offers a link to open the pull request in your Git provider.

​

View check details

Open the check-status indicator on a card for the full check list: each check’s name, the app that reported it, its outcome (Successful, Failed, In progress, Skipped), how long it took, the summary the provider supplied, and a link to it in your Git provider. Opening the panel fetches live results rather than reading the card. While at least one check is still running, the panel refreshes every few seconds and stops when everything finishes or you close it.

​

Manage reviewers

The reviewer stack on a card is also the control for changing reviewers. Suggestions. Triage proposes reviewers from evidence it already has, strongest first:

• Code owners for the paths the pull request touches
• People already requested or already reviewing
• Recent contributors to the same code, weighted toward recent and repeated work
• People who have reviewed this repository before
• People who have reviewed this author’s work before
• Reviewers named in your CodeRabbit configuration, and members of relevant teams

Evidence has to be substantial to count — a single old commit does not make someone a candidate. Bots are never suggested, and neither are you. Search. When the right person has no history here, search for them. Search covers anyone with access to the repository, not only people Triage has evidence about. It uses your own Git-provider authorization, so you see exactly the people you can see in your Git provider. Request and withdraw. Add a reviewer from the picker; withdraw or re-request an existing one from that person’s row in the reviewer stack. All three happen in your Git provider immediately rather than being staged and saved, and all three need a Review seat and your own permission on the repository. Message a reviewer. The message button beside a reviewer sends a direct message to that person when their Git provider account is linked to Slack. See Reviewer requests in Slack.

​

Ping a channel or group DM

Where enabled for your organization, Ping in Slack in the card’s action menu shares the pull request in a channel or group direct message. You do not need to select or assign a reviewer. Choose Channel and search for a channel, or choose DM and select one or more teammates. Your linked Slack account is included in the group DM. Add an optional message, then select Send message. The pull request title and link are included automatically. Slack message queued confirms that the request was accepted for delivery; it does not confirm that Slack has received it yet. This action needs a Review seat, a tracked pull request, a connected Slack workspace, and your linked Slack account. Select Connect your Slack account if prompted. Channel choices come from the connected workspace, and CodeRabbit must be able to access the destination. See PR-level pings for details.

​

Close a pull request

For an open pull request marked as a close candidate, Triage can close it without you opening your Git provider. Close PR opens a confirmation box for a required comment — e.g. “superseded by #4312” — then posts the comment on the pull request before closing it. The action runs as you, so the comment and close are attributed to you and use your permissions. For a close candidate you disagree with, use Ignore close candidate to park it for yourself. For a CodeRabbit recommendation, Report incorrect close recommendation also lets you report that it was wrong. Neither action needs a seat, and ignoring is reversible. To change a manual recommendation, set a different priority.

​

Set a priority

When you know something the evidence does not, set the priority directly. Open the priority badge on a card, choose P0–P3 or Close candidates, and save. It takes an active Review seat. A reason is optional for P0–P3 and required for Close candidates, with a limit of 200 characters. Only tracked, open pull requests can be marked as close candidates. This recommends closing the pull request; it does not close it. In the Close candidates view, the card’s information icon opens Reason to close, showing the saved manual reason and its author. Select Close candidates again to save a revised reason. This also reverses your own prior Ignore close candidate action, without changing anyone else’s dismissal.

• The priority you set wins over the calculated one everywhere — in grouping, filtering, and ordering — and it keeps winning as the queue is re-evaluated.
• The calculated priority keeps being maintained underneath. You are overriding what is shown, not erasing what CodeRabbit concluded.
• Every change is recorded in Priority history on the badge, with who made it, when, and the reason they gave.

If someone else changed the pull request while your board was open, saving can fail with a message telling you to refresh and try again. That is a safeguard against overwriting a priority you could not see; reload and set it again.

​

What’s next