Skip to main content
|

Overview

With manual delivery, a task that finishes successfully leaves its changes in the sandbox until you choose how they should land. Where available, you can enable Autofix to publish the work and handle follow-up fixes automatically.

Choose how changes land

A task using manual delivery rests in the proposed patch state: the work is ready on the task page for you to review. Finishing the task does not itself publish that patch. 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

Manual delivery (Create PR or Commit and push) and Autofix normally use your own Git provider authorization. On GitHub, when your user authorization is in effect, pull requests are opened as you, the signed-in user, and each commit names you as its author and committer, with a Co-authored-by: coderabbitai[bot] trailer that credits CodeRabbit as a co-author. Autofix enabled on an existing pull request can run with the CodeRabbit installation’s credentials instead, and other providers can use different credentials, so authorship can differ in those cases. 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.
Delivery needs a valid provider authorization for your own account. If yours is missing, expired, or revoked, delivery is refused — reauthorize your provider account and start delivery again.

Autofix

Autofix was previously called Autopilot. To apply review findings in a single repair task, use Fix comments. Where Autofix is available for your repository, turn it on from the task’s Autofix control, or type /autofix in the task’s composer to open it. You can also turn it on from a pull request. When the agent finishes, Autofix creates a pull request or commits and pushes to the linked pull request. It then checks for unresolved CodeRabbit findings, failing required CI checks, and merge conflicts, and starts follow-up work to address them.
Enabling Autofix authorizes automatic publication and follow-up fixes. You do not approve each patch separately. Repository permissions and branch protections still apply.
The control shows whether Autofix is checking, fixing, publishing, waiting, done, or paused. If it pauses, read the reason and the task’s latest message, resolve the blocker, then turn it on again to resume. Provider authorization, billing, or a repair that needs your input can all require attention. Turn Autofix off to stop it. Changes already published remain in the repository. Done means its checks are satisfied; use the pull request’s own status to see whether it has merged. Autofix is available on CodeRabbit Cloud for enabled repositories on GitHub Cloud, GitLab Cloud, Azure DevOps Services, and Bitbucket Cloud. Availability is checked separately from ordinary task access, and normal billing checks apply to its follow-up turns.

Turn on Autofix from a pull request

Post the command as a pull request comment to turn Autofix on from the pull request. Turns on Autofix, which keeps fixing CodeRabbit findings and failing required CI checks, and resolves merge conflicts, on the pull request.
  • Post in: A pull request comment (the whole comment must be the command)
  • Also accepted: autopilot, auto-fix, auto fix
  • Requires: write access to the repository
suffix
Turns Autofix off for this pull request. Putting stop first, as in @coderabbitai stop autofix, also works.
suffix
Restarts Autofix after it pauses, once you have resolved the blocker. Putting resume first, as in @coderabbitai resume autofix, also works.
Turn Autofix off
Resume Autofix after a pause
  • CodeRabbit replies with a link to the coding task that runs Autofix.
  • stop and resume work with every spelling of the command.
  • A leading please and a trailing . or ! are ignored.
  • Plain-language requests such as @coderabbitai take this PR to completion also turn Autofix on.
  • On GitHub, you can also select the Autofix checkbox in CodeRabbit’s walkthrough comment.
  • Normal billing checks apply to the follow-up work Autofix starts.
On GitHub, the Autofix checkbox in the walkthrough comment shows Autofix’s current state. @coderabbitai autofix stacked pr runs a one-off Fix comments and delivers the fixes as a stacked pull request. See the review commands reference for every spelling.

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.