Skip to main content
|

​
Overview

Delivery is always a separate, explicit step. A task that finishes successfully has changed nothing in your repository until you accept its patch and choose how it should land.

​
Choose how changes land

A finished task rests in the proposed patch state: the work exists on the task page and nowhere else. That state is where you review, and it is not itself a way of delivering — leaving it is the delivery. There are two ways to leave it: You can reject a proposed patch at any point before delivery. After delivery, the changes are ordinary Git history — undo them through your provider the way you would undo any other commit.
Delivery from the standalone Coding Agent app covers GitHub, GitLab, Azure DevOps, and Bitbucket Cloud. Delivery from the embedded Change Stack panel covers GitHub and GitLab.

​
Who pushes, and who wrote it

Delivery uses your Git provider authorization, and the commit carries CodeRabbit as its author. That split is deliberate, and it has two consequences worth knowing:
  • Your permissions apply. The push is made with your provider credentials, so branch protections and your repository permissions evaluate exactly as they would for a push you made by hand. Coding Agent has no path around them.
  • The change is attributable. The commit is visibly CodeRabbit-authored, so it is obvious in git log and in review which changes came from an agent.
A stacked pull request is opened as you.
Delivery needs a valid provider authorization for your own account, even though CodeRabbit authors the commit. If yours has expired or been revoked, delivery is refused — reauthorize your provider account and start delivery again.

​
When delivery is blocked

Delivery can be refused after the patch is ready. Each refusal has a specific cause and a specific way forward. A moved branch tip is not the same thing as a conflict. The tip check is about when the patch was built; a conflict is about what changed underneath it. The first is fixed by choosing a different delivery mode, the second by reconciling.

​
Resolve delivery conflicts

Delivery can discover that the target branch has moved on since the task started. When that happens the task reports conflicts rather than forcing a write.
1

Conflicts are detected

Delivery stops and the task moves to a conflicted state. Nothing has been pushed.
2

Ask the task to reconcile

The task re-reads the current state of the branch, works out a resolution with the context it already has, and retries delivery.
3

Review the result

Reconciliation is a normal turn: it produces work you review the same way you reviewed the original patch.
Automated conflict handling covers up to 500 conflicted files. Conflict resolution can rewrite the task’s branch history. When it does, CodeRabbit declines to publish a merge commit on top of that rewritten history rather than producing a misleading one.

​
After delivery

If a task was started within an existing pull request, CodeRabbit posts a comment back on the pull request when it finishes. The comment links to the task, so anyone reading the pull request can open the full activity, diff, and decision history behind the change. On GitHub and GitLab that comment carries interactive checkboxes for the follow-up actions. On other providers the same actions are offered as reply instructions in the comment itself. For the reply commands themselves, see Review commands. The task page tracks the state of any pull request it opened — open, merged, or closed — so you can see from the task whether its work has landed.

​
What’s next

Access and billing

Which turns are free, how agent minutes are metered, and what the monthly cap does.

Coding environments

Give your repositories a reusable sandbox with the right toolchains, packages, and setup.

Work with a running task

Steer a task, answer its questions, and review its plan or patch.