> ## 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. # Run Coding Agent tasks from the CLI > Start, follow, steer, and deliver cloud Coding Agent tasks from your terminal with cr code, or drive them from a coding agent or script with --agent JSON output. export const Hint = ({type, children, headline, tip, href, cta}) => { const TIPS = { learnings: { headline: "Learnings", tip: "Review preferences CodeRabbit learns from your chat conversations and applies automatically to future reviews.", cta: "Learn about Learnings", href: "/knowledge-base/learnings", content: "Learnings" }, walkthrough: { headline: "PR Walkthrough", tip: "A structured comment posted by CodeRabbit at the top of every pull request, summarizing changes, sequence diagrams, review effort, and more.", cta: "Learn about PR Walkthroughs", href: "/pr-reviews/walkthroughs", content: "Walkthrough" }, "finishing-touches": { headline: "Finishing Touches", tip: "Post-review agentic actions (Autofix, writing docstrings or unit tests, and more) you trigger from a PR comment or a checkbox in the Walkthrough.", cta: "See all Finishing Touches", href: "/finishing-touches", content: "Finishing Touches" }, "coding-plan": { headline: "Coding Plan", tip: "A detailed, codebase-aware implementation plan CodeRabbit generates from an issue or description, ready to hand off to any coding agent.", cta: "Learn about Coding Plans", href: "/plan", content: "Coding Plan" }, "knowledge-base": { headline: "Knowledge Base", tip: "The collected context sources CodeRabbit draws on during reviews: Learnings, Code Guidelines, issue trackers, connected MCP servers, and cross-repo analysis.", cta: "Explore the Knowledge Base", href: "/knowledge-base", content: "Knowledge Base" }, "path-instructions": { headline: "Path Instructions", tip: "Custom review rules that only apply to files matching a glob pattern, e.g. 'src/controllers/**'.", cta: "Configure path instructions", href: "/configuration/path-instructions", content: "Path Instructions" }, "change-stack": { headline: "Change Stack", tip: "An improved code inspection interface that reorganizes a pull request from a flat file list into a structured, layer-by-layer walkthrough with range-specific summaries and diagrams when useful.", cta: "Learn about Change Stack", href: "/change-stack", content: "Change Stack" }, scope: { headline: "Scope", tip: "A named set of repositories, connections, and spend limits that controls what CodeRabbit Agent can access in a given Slack conversation.", cta: "Learn about Scopes", href: "/slack-agent/scopes", content: "Scope" }, "coderabbit-agent": { headline: "CodeRabbit Agent for Slack", tip: "An AI agent built into Slack that investigates issues, generates implementation plans, and opens pull requests right from the Slack threads.", cta: "Explore CodeRabbit Agent", href: "/slack-agent", content: "CodeRabbit Agent" }, "configuration-inheritance": { headline: "Configuration Inheritance", tip: "A setting that merges configuration values across multiple levels — repository YAML, central YAML, and UI settings — instead of using only the highest-priority source.", cta: "Learn about Configuration Inheritance", href: "/configuration/configuration-inheritance", content: "Configuration Inheritance" }, "coding-agent": { headline: "Coding Agent", tip: "Turns a user request, a review finding, a coding plan or a failing CI check into a task that CodeRabbit's agent implements in the cloud, then delivers as a commit or a stacked pull request for you to approve.", cta: "Learn about Coding Agent", href: "/code", content: "Coding Agent" }, triage: { headline: "Triage", tip: "A single cross-repository queue of open pull requests, ranked by what each one needs next and what acting on it is worth.", cta: "Learn about Triage", href: "/triage", content: "Triage" } }; const defaults = TIPS[type] || ({}); return {children ?? defaults.content} ; }; export const OpenBetaBadge = ({tip = "This feature is currently in open beta. We are actively improving it based on your feedback. If you encounter any issues or have suggestions, please share them on our Discord community or visit the support page.", title = "Open Beta", cta = "Contact support", href = "/support", disabled = false}) => { return {title} ; }; export const CLIBadge = ({tip = "This feature is available with the CodeRabbit CLI.", title = "CLI", cta = "Read more", href = "/cli/index", disabled = false}) => { return {title} ; }; | Give CodeRabbit a prompt from your terminal, and the agent works on your repository in the cloud. With `cr code` (short for `coderabbit code`), you follow the work, steer it, and push the result or open a pull request with it. You can also hand off a local Codex or Claude Code session. For scripts and coding agents, see [Drive tasks from scripts and coding agents](#drive-tasks-from-scripts-and-coding-agents). For every option, see the [command reference](/cli/reference#code). A **task** is one unit of cloud work on a repository, with its own history and page in the web app. Each instruction you send runs as a **turn** of the task. ## Requirements * **CLI 0.9.0 or later.** Run `cr update`. `cr code handoff` and `cr code skills import` work from 0.8.1. * **A CodeRabbit SaaS login.** Run `cr auth login`, then `cr auth org` in an interactive terminal to select an organization. API key, self-hosted, and [SSO workspace](/cli/index#sso-workspace-logins) logins are not supported. * **Access.** Coding Agent must be enabled for your organization, and you need access to the repository. See [Access and billing](/code/access-and-billing). Tasks use agent minutes and are billed like tasks started in the web app. If your organization's Coding Agent trial has not started, your first task starts it. ## Quick start ```bash theme={null} # Start a task from your pushed branch. It prints the task ID and URL. cr code new "Fix the flaky retry test" # Optional: open the live view of your latest task to watch and steer it. cr code resume --last # When the turn finishes, push the changes: type /push in the live view, or run: cr code push ``` A push commits the changes onto the working branch; with `--stacked` it opens a pull request against that branch instead ([Push changes](#push-changes)). The first push can pause for a GitHub authorization in your browser. Closing the live view never stops the task. Add `--plan` to review a plan before any code changes ([details](#review-and-approve-a-plan)). ## Start a task A task starts from the branch on `origin` that your current branch tracks, or the branch with the same name, not from your working tree. Unpushed commits and uncommitted changes are not included, so push first if the task needs them. A detached HEAD is refused. ```bash theme={null} cr code new "Fix the flaky retry test" cr code new --plan "Plan the payments migration" cat PROMPT.md | cr code new - cr code new --resume "Add a regression test" ``` * **Prompt.** An argument, or `-` for standard input. An interactive terminal asks for one if you omit it. * **`--plan`** starts in Plan mode: the agent writes a plan for review instead of changing code. * **`--resume`** starts the task and opens the live view in one command, the same as running `cr code resume ` next. ## Follow and steer a task ```bash theme={null} cr code resume cr code resume --last cr code resume ``` `cr code resume` opens a live view of the task. `--last` opens your most recently updated task for this repository; with no task, the command lists your ten most recent tasks to pick from. The view, which `cr code new --resume` also opens, needs an interactive terminal. Closing it with `/exit` never stops the task. Commands accept a task ID or a task URL such as `https://app.coderabbit.ai/code/tasks/`, read from the region and organization of your current login (for another region, run `cr auth login --region eu` first). [Shell completion](/cli/index#shell-completion) completes task IDs you listed or opened. In the view you can: * Type a message. During a turn it joins or queues behind the running turn; otherwise it starts a new turn. Start with `//` to send a literal `/`. * Add guidance to the running turn with `/steer `, or stop it with `/cancel`. * Answer the agent's blocking questions. Answers to sensitive questions are hidden as you type. * Mention a file with `@` and at least two characters of its path, once the task's environment is ready. * Type `/` for suggestions; see the [slash command reference](#slash-command-reference). Some tasks can't be changed from the CLI. Workspace tasks are read-only, tasks on the previous Coding Agent runtime show only their history, and automation tasks can't be opened. Continue those in the web app. ### Stop a running turn ```bash theme={null} cr code cancel ``` `cr code cancel` stops the running turn and drops queued messages. The task stays open, and a new message starts a new turn. ## List and inspect tasks ```bash theme={null} cr code ls cr code ls --status needs_attention cr code ls --repo . cr code ls --all cr code show ``` `cr code ls` lists the 20 most recently updated tasks in the selected organization. By default it lists only your tasks; `--all` adds other people's tasks that you can see. Archived tasks are not listed, but `show` can read them. * **`--repo `** lists the tasks of the repository that matches the `origin` remote of the checkout at that path. * **`--status `** filters by the state shown in the web task list: `needs_attention`, `ready_for_review`, `running`, `completed`, or `canceled`. `cr code show` shows the status, repository, delivery, patch, plan, result, and pull request health of a task. ## Review and approve a plan A task started with `--plan` ends with a plan instead of code changes. Run `/implement` in the `cr code resume` view to implement the latest plan, or implement it from the task page in the web app. It needs a finished plan with no open plan comments, no running turn, and no queued messages. ```bash theme={null} cr code plan cr code plan --approve ``` `cr code plan` shows the latest finalized plan. `--approve` records your approval of that plan version; it does not start implementation. If the plan changed after you read it, approval fails: run `cr code plan ` to read the new version. For plan approvals in the web app, see [Review a plan](/code/work-with-a-task#review-a-plan). ## Push changes ```bash theme={null} cr code push cr code push --stacked ``` `cr code push` delivers the ready changes of a task. By default, CodeRabbit commits them onto the working branch and pushes, as **Commit and push** does in the web app. `--stacked` pushes them to a new branch and opens a pull request against the working branch, as **Create PR** does. A stopped or interrupted turn can still leave a patch, and `cr code push` delivers that partial work. See [Choose how changes land](/code/deliver-changes#choose-how-changes-land). GitHub can first ask you to authorize CodeRabbit. In an interactive terminal, the command prints the authorization URL, opens it when it can, and waits up to 10 minutes while you approve in a browser signed in to CodeRabbit with the same GitHub account. Without a terminal, it prints the URL and stops; run it again after you approve. * **Waiting.** The command stops waiting after 15 minutes and reports that the push is still running. The push continues, and `cr code show` shows the result. Ctrl-C stops only the wait. * **Failure.** The command shows the reason from the repository, such as the CodeRabbit GitHub App not being allowed to change `.github/workflows`. Fix the cause, then push again. * **Reruns.** Rerunning is safe: a running push is waited for, and already-pushed changes are reported without a new push request. While a turn runs or messages are queued, the command asks you to wait. ### Let Autopilot deliver and fix [Autopilot](/code/deliver-changes#autopilot) publishes a task's changes when the agent finishes, then fixes CodeRabbit findings, failing required CI checks, and merge conflicts. Turning it on lets it publish changes and push follow-up fixes without asking you. ```bash theme={null} cr code autopilot status cr code autopilot on cr code autopilot on --pr 12 cr code autopilot resume --pr https://github.com/acme/payments-api/pull/12 cr code autopilot off ``` `on` starts Autopilot, `off` stops it, and `status` shows its state. `resume` starts a new repair cycle after Autopilot pauses; `on` does not resume a paused Autopilot. Pass either a task or `--pr`: a pull request number in the repository that matches your checkout's `origin`, or a GitHub pull request or GitLab merge request URL. With `--pr`, `on` and `resume` can create an Autopilot task when you have no delivered task for that pull request. ## More `cr code` commands ### Continue a local session in the cloud `cr code handoff` hands a local coding session off to a new cloud task. ```bash theme={null} cr code handoff --summary /tmp/session-summary.md cr code handoff --summary /tmp/session-summary.md --plan /tmp/session-plan.md cat /tmp/session-summary.md | cr code handoff --summary - ``` Run it from a clean Git checkout on a branch with an `origin` remote. The cloud task must be able to fetch the selected commit, so commit and push first. Untracked files count as changes, so keep the summary and plan files outside the repository or commit them. * **`--summary `** is required; `-` reads standard input. **`--plan `** is the primary implementation plan file. * **Uploads.** The summary, the optional plan, and a session transcript when the command finds one, such as your current Codex or Claude Code session. Review these files first. Each attachment is limited to 25 MiB. A missing transcript or a failed transcript upload is a warning, not a failure. The result shows the branch, commit, transferred filenames, and a task link. The task exists then, but the cloud still has to verify the commit and load the files. Each run creates another task, so do not rerun a handoff that succeeded. ### Ask a side question ```bash theme={null} cr code ask "Why does the hook run twice?" cr code ask --follow-up "And the fix?" cr code ask - < question.md ``` `cr code ask` puts a question to a side chat of the task and prints the answer. A side chat reads the task's conversation and repository but does not change the task, and a running turn keeps running. The answer includes a turn ID. Pass it to `--follow-up` to keep asking in the same side chat, with the context of earlier questions. `cr code ask` can't close a side chat, so use `--follow-up` to keep asking in the one you opened. A task can have 3 open side chats, and an idle one expires after 24 hours. ### Import local skills `cr code skills import` uploads local agent skills to your cloud Coding Agent skill library, in the organization you selected with `cr auth org`. To install CodeRabbit skills into your local coding agent instead, use [`cr skills`](/cli/skills). ```bash theme={null} cr code skills import cr code skills import ./my-skill cr code skills import ./my-skill/SKILL.md --scope personal ``` Run it without a path to choose a local agent and select skills, or pass a skill folder or its `SKILL.md`. Review the selected files and destination before you confirm. * **`--scope personal|organization`.** New skills are personal within the selected organization by default; `organization` shares them with it. * **Non-interactive imports** need a path and `--yes`. With `--yes` and no `--scope`, new skills are personal and existing skills keep their visibility. * **Same name.** Importing a skill you own with the same name publishes a new version. For writing a `SKILL.md`, limits, and sharing, see [Coding Agent skills](/code/skills). ## Slash command reference Commands marked (billed) start agent work. Commands that say "Asks first" need a `y`; press Enter to keep things as they are. `/push` does not ask. | Command | Action | | - | - | | `/steer ` | Add guidance to the running turn. | | `/answer` | Answer the agent's question. | | `/cancel`, `/stop` | Stop the running turn and drop queued messages. Asks first. | | `/queue [edit\|delete\|send ]` | List queued messages, or edit, delete, or send message `n`. | | `/upload …` | Attach files to your next message. | | `/side ` | Ask a side question while the turn runs (billed). `/side close` closes the side chat that the view opened. | | `/skills [ [text]]` | List the library skills, or run one (billed). | | `/plan [comments]` | Show the latest plan, or count its open comments. | | `/approve` | Approve the latest plan. | | `/implement` | Switch to code mode and implement the plan (billed). | | `/revise ` | Ask the agent to rewrite the plan (billed). | | `/mode [plan\|code]` | Show or switch the mode. | | `/push` | Commit and push the changes. | | `/push --stacked` | Open a new pull request with the changes. | | `/pr` | Show the health of the pull request. | | `/fix ci\|comments\|conflicts` | Fix failing CI, address review comments, or resolve merge conflicts (billed). | | `/update-branch` | Merge new upstream commits (billed). | | `/autopilot [on\|off\|resume\|status] [--pr]` | Show or change [Autopilot](#let-autopilot-deliver-and-fix) for the task or, with `--pr`, its pull request. | | `/review [on\|off]` | Show or change the CodeRabbit review of the changes. | | `/access [manual\|full]` | Show or change repository access. Full access asks first, then needs a GitHub step in the browser. | | `/share [private\|team]` | Show or change who can see the task. A change asks first. | | `/subscribe [on\|off]` | Show or change your Slack notifications for the task. | | `/services` | List the task's dev servers. | | `/start-services` | Ask the agent to start the stopped dev servers (billed). | | `/restart-services` | Ask the agent to restart the dev servers (billed). | | `/schedule [delete ]` | List schedules, or delete one. Delete asks first. | | `/outputs [save ]` | List output files, or save one in the current directory. | | `/attachments [save ]` | List message attachments, or save one in the current directory. | | `/web [pr\|slack]` | Open the task, its pull request, or its Slack thread in the browser. | Run `/help` in the view for the full list. ## Drive tasks from scripts and coding agents Everything below is for scripts and coding agents. For the general agent-mode contract, see [Agent mode output and exit codes](/cli/agent-mode). * **A person signs in first.** Run `cr auth login` (browser) and `cr auth org` (interactive terminal) on that machine. There is no non-interactive login: API key, self-hosted, and SSO workspace logins fail with `unsupported_auth`, no selected organization fails with `organization_required`, and `cr auth org --agent` only lists organizations. * **Always pass `--agent`,** right after the full command name, as in `cr code new --agent …` or `cr code autopilot on --agent …`. Every `cr code` command except `skills import` accepts it. The CLI also switches to JSON when `stdout` is not a terminal and it detects a coding-agent environment (for example `CLAUDECODE`, `CODEX_SANDBOX`, `CURSOR_AGENT`, `GEMINI_CLI`, or `CR_CLI_AGENT=`), but only an explicit `--agent` turns argument errors into JSON. In `cr code new`, put `--agent` before `--plan`, or an argument error prints as plain text on `stderr` and exits with `1`. * **Use explicit task IDs,** not `--last`, which picks the most recently updated task and can change between runs. * **`command` fields** start with `coderabbit`, the same binary as `cr`. On `authenticate`, a person runs `command` (it opens a browser sign-in). On `authorize_github`, a person opens the `url`; after they approve, rerun `command`. On `answer_question` with an `answerTemplate`, don't run `command` (it holds a literal `` placeholder): run `cr code resume --agent --answer ''` with the filled-in template. On `answer_question` with a null `answerTemplate`, `command` is interactive: never run it; give it to the user. * **Records.** One JSON object per line, each with a `type`. `status`, `complete`, and `error` records have a `status`; on an `error` record it is the error code. `action_required` records have an `action`, and `message` is human-readable text. The first record is a `status` record with `status: "beta_notice"` and a `feedbackUrl`. `resume` also writes `trace` records with a `kind` such as `agent_message`, `command`, `file_change`, or `turn_end`. * **Liveness.** `resume`, `new --resume`, and `ask` write a `status` record `waiting` after 45 seconds without other output. `push` writes `delivery_waiting` on progress and every 45 seconds. `cancel`, `handoff`, `plan`, `autopilot`, `ls`, and `show` write none, so size CI idle timeouts with the limits below. * **The last record decides.** Branch on its `type`, then its `status` or `action`. Use the exit code only as a cross-check, because exit `1` and `4` each cover records that need different handling. Exit `0` is `complete`, but `push_in_progress` and `cancel_pending` are not final. Exit `1` is `error`, or `action_required` for `authenticate` and `authorize_github`. Exit `3` is `answer_question`. Exit `4` is `action_required`: for the `resume` action, rerun `cr code resume --agent `; for `read_answer`, never rerun `ask`. A signal interrupt exits `130` or `143` with no last record. If the last record has a `status` or `action` that this page does not list, stop and ask a person. * **Commit points.** Save these records as they arrive, and never rerun the command that wrote one (exceptions are under Retry safely): `task_submitted` (`new`, with `taskId` and `url`), `creating_task` (`handoff`), `message_sent`, `steer_sent`, `answer_sent`, and `question_sent`. A generic `error` record has no `taskId`, so keep it from earlier records. * **`agentMinutes`.** The last record of a turn (`complete` with `turn_completed`, or `error` with a `turn`) has `agentMinutes`: the gross agent minutes of the turn, rounded to two decimals, not billed minutes. It is `null` when the run did not see the turn run and end, or the minutes did not arrive in time. "Not final" marks outcomes that need a follow-up command. **`new`** | Last record | Exit | Next step | | - | - | - | | `complete`, `task_submitted` | `0` | Done. Keep `taskId` and `url`. Warnings: `unpushed_commits`, `uncommitted_changes`, `branch_not_on_origin`. With `--resume`, the stream continues as for `resume`. | | `error` after a `task_submitted` record, such as `task_not_found` or `new_failed` | `1` | The task exists. Use the `taskId` from that record, and don't rerun `new`. | | `error`, `operation_conflict` | `1` | A task may be being created. Don't rerun; run `cr code ls --agent --repo .` and let the user decide. | | `error`, `new_failed` before `task_submitted` | `1` | The request may have reached CodeRabbit. Check `cr code ls` or `show` before running `new` again. | | `error`, `task_rejected` with warning `branch_not_on_origin` | `1` | Push the branch, then retry. | | `error`, `billing_required` | `1` | A person must start a trial or set up billing in the web app. | **`handoff`** The statuses are `checking_repository`, `uploading_files`, and `creating_task`. | Last record | Exit | Next step | | - | - | - | | `complete`, `task_created` | `0` | Done; never rerun. Fields: `taskId`, `url`, `branch`, `headCommit`, `uploadedFiles`, and `warnings` (`transcript_missing`, `transcript_too_large`, `transcript_upload_failed`). | | `error`, `handoff_failed` | `1` | If `creating_task` was written, a task may exist: don't rerun, check `cr code ls --agent --repo .`, and ask a person. If not, nothing was created: fix the cause and rerun. | The earlier `cr handoff` form still works, but its human-readable output changed in 0.8.1; update scripts that parse the old output. **`resume`** (watch, `-m`, `--steer`, `--answer`) ```bash theme={null} cr code resume --agent cr code resume --agent -m "Add a regression test" cr code resume --agent --steer "Use the existing Postgres cluster" cr code resume --agent --answer '' echo "Add a regression test" | cr code resume --agent -m - ``` The command sends at most one of `-m, --message`, `--steer`, and `--answer`; all require `--agent` and accept `-` for standard input. `-m` joins the running turn, queues behind it, or starts a new turn. `--steer` adds guidance to the running turn. `--answer` takes the `answerTemplate` JSON of an `answer_question` record with each answer filled in. The run follows the resulting turn until it ends, the agent asks a blocking question, or 9 minutes pass. Without a send option, it reports the latest turn. | Last record | Exit | Next step | | - | - | - | | `complete`, `turn_completed` | `0` | Report `turn.finalReply`. | | `error`, `turn_failed`, `turn_canceled`, or `turn_interrupted` | `1` | Report it. A person stopped a canceled turn; the runtime stopped an interrupted one. Either can leave a patch; push it only with the user's OK. | | `action_required`, `answer_question` | `3` | If `answerTemplate` is not `null`, fill it in and run `cr code resume --agent --answer ''`, not `command`. If it is `null`, ask a person (see "When to stop and ask a person"). This can arrive before any send if a question is already pending. | | `action_required`, `resume` | `4` | Not final. Run `cr code resume --agent ` without a send option. | | `error`, `turn_not_running` | `1` | Send with `-m`. | | `error`, `message_dropped` | `1` | The message was not delivered. Send it again. | | `error`, `steer_not_delivered` | `1` | Retry the steer, or send it with `-m`. | | `error`, `task_stopping` | `1` | Wait, then send again. | | `error`, `turn_active`, `pending_queue_exists`, or `task_busy` | `1` | Wait for the turn or queue, then retry. | | `error`, `resume_failed` after a `*_sent` record | `1` | The send probably landed. Don't resend; follow instead. | **`cancel`** | Last record | Exit | Next step | | - | - | - | | `complete`, `task_canceled`, `turn_finished`, or `not_running` | `0` | Done. | | `complete`, `cancel_pending` | `0` | Not final. The stop was accepted, but the turn had not stopped after 60 seconds. Poll `cr code show --agent ` until `task.turnStatus` is not `in_progress` and `task.cancellationPending` is false. Don't rerun `cancel` to wait: it would stop whatever turn is running then and drop queued messages. | **`ask`** | Last record | Exit | Next step | | - | - | - | | `complete`, `question_answered` | `0` | Report `answer`. Keep `turnId` for `--follow-up`. | | `error`, `answer_failed`, `answer_interrupted`, or `side_chat_closed`, after `question_sent` | `1` | Report it. The question is billed; never ask it again. | | `action_required`, `read_answer` | `4` | No answer within 15 minutes. The side chat still answers, and the answer is billed: read it in the web app. Don't rerun `ask`. | | `error`, `ask_failed` | `1` | The CLI may not know whether the question arrived. Treat it as billed: don't ask again; give the task ID and question to a person. | | `error`, `side_chat_limit_reached`, before `question_sent` | `1` | The task has 3 open side chats. Use `--follow-up`. | | `error`, `side_chat_starting`, before `question_sent` | `1` | Retry later. | | `error`, `side_chat_closed` or `side_chat_not_found`, with `--follow-up`, before `question_sent` | `1` | Ask without `--follow-up`. | | `error`, `side_chat_unavailable`, `task_read_only`, or `unsupported_task` | `1` | Use the web app. | Nothing is billed before `question_sent`, except after `ask_failed`, where billing is unknown. Records after it carry `sideChatId`, `turnId`, and `clientOperationId`. `cr code show` does not show side chats. **`plan`** | Last record | Exit | Next step | | - | - | - | | `complete`, `plan_shown` or `plan_approved` | `0` | The record has `plan` and your role as `viewer`. | | `error`, `plan_stale` | `1` | Show the plan again and get approval again. | | `error`, `plan_not_found` | `1` | No finished plan yet. Wait for the plan turn, then retry. A code-mode task has none. | **`push`** (default and `--stacked`) | Last record | Exit | Next step | | - | - | - | | `complete`, `task_pushed` | `0` | Done. `alreadyPushed` is `true` when nothing new was sent; rerunning `--stacked` for an already-delivered patch opens no second pull request. | | `complete`, `push_in_progress` | `0` | Not final. The push continues. Rerun the same command with the same flags (`--stacked` included): it joins the running push and never sends a second one. Or poll `cr code show --agent `. Never switch `--stacked` on or off between runs. | | `action_required`, `authorize_github` | `1` | Returns immediately. Give the `url` to a person and never open it yourself. After they approve, rerun the record's `command`. | | `error`, `task_busy`, `turn_active`, or `pending_queue_exists` | `1` | A turn is running or messages are queued, and nothing was pushed. Wait, then rerun. | | `error`, `delivery_failed` | `1` | Report the reason. Don't push again until the cause is fixed. | | `error`, `delivery_conflicts` | `1` | Resolve the conflicts on the task page. | | `error`, `push_rejected` | `1` | Report it, for example when there is no ready patch. | **`autopilot`** | Last record | Exit | Next step | | - | - | - | | `complete`, `autopilot_status`, `autopilot_enabled`, `autopilot_disabled`, or `autopilot_resumed` | `0` | The record has the Autopilot state. | | `error`, `autopilot_paused` (`on` only) | `1` | Run `cr code autopilot resume --agent` with the same target. | | `error`, `billing_required` (`on`, `resume`) | `1` | A person must act. | **`ls` and `show`** | Last record | Exit | Next step | | - | - | - | | `task` records, then `complete`, `tasks_listed` (`ls`) | `0` | The record has `count`, `totalCount`, and `hasMore`. | | `complete`, `task_shown` (`show`) | `0` | The record has `task` and `warnings`. `task.deliveryError` is set when `task.deliveryStatus` is `failed` and there is no `errorSummary`, and `null` otherwise. | Both only read, so rerun them freely. **Any `cr code` command** | Last record | Exit | Next step | | - | - | - | | `action_required`, `authenticate` | `1` | A person runs the login `command`. | | `error`, `unsupported_auth` or `organization_required` | `1` | A person must sign in or select an organization. | | `error`, `invalid_arguments` | `1` | Fix the call. | **Tasks the CLI can't change.** Workspace tasks are read-only: `cancel` and `ask` fail with `task_read_only`, and `resume` fails with it only when you send. Tasks on the previous Coding Agent runtime fail `resume` and `cancel` with `task_read_only` and `ask` with `side_chat_unavailable`. Automation tasks fail with `unsupported_task`. Continue these in the web app. 1. **Never rerun a command after it wrote a commit-point record;** follow the task with `cr code resume --agent ` instead. Exceptions: `message_dropped` and `steer_not_delivered` mean the send did not land, so send again. `handoff` has no task ID before `task_created`: after `creating_task`, don't rerun. Run `cr code ls --agent --repo .` and give the result to a person. 2. **No last record?** If a run was killed or crashed (or exited `130` or `143`), use the records you saw. If you saw no commit point from `new` or `handoff`, a task may still exist: check `cr code ls --agent --repo .` before rerunning. 3. **After `-m`,** keep the `clientOperationId` from `message_sent`. If the run that sent the message ends with a turn whose `turn.queueItemId` equals it, that turn is yours. If it differs, your message joined the turn that was already running, and that outcome covers it. After an exit-`4` rerun, a turn whose `turn.queueItemId` is not yours means your message may still be queued: rerun without a send option a few seconds later, at most three times, then report to a person. Never resend `-m`. 4. **Safe to rerun:** `ls`, `show`, `plan` without `--approve`, and `push` with identical flags, unless the last record was `delivery_failed`, `delivery_conflicts`, or `push_rejected`. Don't rerun `cancel` to wait. * **Sensitive question.** `answer_question` with a null `answerTemplate` and a `command`: give the user `command` (`coderabbit code resume `, interactive) to run and answer there. Never run it or collect the answer yourself. * **Question on a workspace task.** `answerTemplate` and `command` are both null: give the user the web app link from `message`. * **Authorization, login, and billing.** `authorize_github`, `authenticate`, `unsupported_auth`, `organization_required`, and `billing_required`. * **Get a person's OK before** delivering changes (`push`), approving a plan (`plan --approve`), turning on Autopilot or resuming it (it publishes and pushes follow-up fixes on its own), running `cancel` (it drops queued messages), pushing partial work after `turn_failed`, `turn_canceled`, or `turn_interrupted`, or answering a question you would have to guess. | Command | Limit | | - | - | | `resume --agent` | Waits up to 9 minutes, then exits `4`. | | `ask` | Waits up to 3 minutes for the task's environment, then up to 15 minutes for the answer. | | `push` | Waits up to 15 minutes for delivery. In agent mode, GitHub authorization returns `authorize_github` immediately; only the interactive view waits up to 10 minutes. | | `cancel` | Waits up to 60 seconds for the turn to stop. | | `show` | Reads pull request health for up to 20 seconds. If that fails or times out, it warns and still succeeds. | | Prompts, messages, steers, and questions | Up to 65,536 characters. | | Standard input | Up to 262,144 bytes. | ## What's next Follow, steer, and review a task in the web app, including plans and proposed patches. Compare the delivery modes and see how Autopilot publishes and fixes changes. Look up every `cr code` command and option, generated from the CLI help output. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.