Fix repeated auth prompts in CodeRabbit Codex reviews

[coderabbitai]

Summary

Stop the CodeRabbit Codex plugin from checking authentication before every review. The skill now starts the requested review directly and handles authentication only after an explicit auth failure.

Customer evidence

• Cisco Systems reported in Pylon ticket #27481 that CodeRabbit in a Codex review/fix loop asks for authentication frequently and appears to do so for each GitLab repository, halting unattended loops.
• Linear issue ENG-4340 independently records the same failure mode: Codex prompts for authentication too often, possibly every run, and waits for user input.
• The current published skill explicitly runs coderabbit auth status --agent as prerequisite step 3 before every review, then starts browser login when it interprets auth as missing.

Root cause and reasoning

The proactive skill instruction is inconsistent with the CLI auth contract:

• Browser-auth credentials are persisted locally and access tokens are refreshed automatically.
• Repository-to-organization attribution is resolved from the current Git remote; changing repositories does not require a new login.
• In non-interactive environments, browser login may require user action and therefore stalls Codex loops.

Removing the unconditional preflight prevents the plugin from manufacturing an interactive auth step on every run. Genuine auth failures remain recoverable: the skill checks status reactively, runs login once, and retries the review once. Headless or ephemeral environments receive the documented Agentic API-key path.

Changes

• Replace unconditional auth status / browser-login prerequisites with reactive auth recovery.
• State explicitly that repository changes do not require separate login.
• Add the Agentic API-key path for non-interactive or ephemeral runtimes.
• Bump the CodeRabbit plugin patch version from 1.1.1 to 1.1.2.

Confidence

High for eliminating unnecessary per-review prompts because the triggering instruction is explicit in the current skill and the replacement matches the current CLI implementation. Medium for resolving every Cisco occurrence until we confirm whether their Codex runtime also discards ~/.coderabbit or OS credential storage between runs.

Validation

• jq empty plugins/coderabbit/.codex-plugin/plugin.json
• git diff --check

Final Prompt

Automation execution profile: CODEX_WORKSPACE.
Treat the following as an operational task for the current automation run, not as a request to create, update, preview, review, or explain an automation.

• Do not create or modify automations as part of this phase.
• Do not emit automation_proposal or automation_action_proposal in a live automation run.
• Do not talk about automation setup, scheduling, confirmation UI, sample-run requirements, or draft previews.
• Ignore earlier automation-authoring, preview, and review messages in this thread. They are historical setup context, not instructions for this live run.
• The automation runtime has already created the current run thread when this phase starts. Do not create a second top-level channel message or a second run thread.
• If the task refers to the top of the new run thread or to the original post or message, it means the Slack message the automation runtime already created for this run.
• Carry out only the current phase below, then stop. Do not implement later phases yourself.
• If this run already has a live automation-owned status card, update that existing card in place with an automation_status_card. Do not emit a preview card, draft card, or alternative control surface.
• If this run does not already have a live automation-owned status card, do not emit automation_status_card. Return only the visible thread reply.
• When a prompt-driven action says to update the original post, original message, or status card, your final output for this phase must include an automation_status_card that reflects that requested end state before you stop.
• When the runtime already created or updated the live root status card for this phase, do not add a redundant acknowledgement reply such as 'thread is live' or 'status card updated'.
• When the live root status card already presents the initial choices or status for this run, do not add a separate introductory thread reply that only restates those controls. Treat the root card as the initial UX for that phase.
• For the main visible Slack message in this automation run, do not call actor-slack, post_message, a user token, or any other user-scoped Slack action.
• Return the exact Slack message as your normal final output instead. The automation runtime will deliver that output with the bot identity according to this automation's saved delivery mode.
• Use actor-scoped Slack actions only when the saved task explicitly asks for a separate user-scoped side action beyond the main automation message.
• When the task only asks you to post message text, do not return an acknowledgement such as 'Posted hi bot testing'. Return the message text itself.
• When opening a pull request, include at the end of the PR body.
• This run was triggered by a webhook event.
• The automation runtime already applied the saved event type and payload field rules before starting this run. Do not re-check whether the webhook should qualify.
• Use the webhook payload below as live runtime input. Do not treat it as an example or preview artifact.

Webhook event context:

• Provider: pylon
• Connection ID: 5982ab23-a59e-46a7-9b97-8910174f899c
• Event type: pylon.issue.created
• Channel ID: C0B1AFCP40J
• Payload JSON: {"event_type":"pylon.issue.created","source":"pylon","issue":{"id":"062c571a-d24a-41a6-a973-d39d592b2f50","link":"https://app.usepylon.com/issues?issueNumber=27481","body":"I'm using CodeRabbit tied into my Codex loop, and it seems to require me to reauthenticate extremely frequently, and for each individual repository in GitLab. This can cause my loops to halt. Is there something I have misconfigured?","account":{"id":"6b16b458-c8a1-4cd7-9629-6bd566de62fd","name":"Cisco Systems Inc"},"assignee":"Charles Harring"}}

Task:
Triage this customer support event like a senior support engineer.

Use the ticket details to identify the customer, product area, urgency, impact, and what the customer is trying to do. Classify the issue as one of: product bug, customer confusion, missing documentation, pricing or billing question, account or permissions issue, integration setup issue, or unknown.

If this looks answerable from documentation or known product behavior, check the relevant docs or knowledge base connections and draft a clear customer-facing answer.

If this looks like a product bug, investigate it like a production issue. Check observability and infrastructure connections for matching errors, latency, saturation, traffic shifts, dependency failures, and trace examples. Compare the alert window with recent deploys, config changes, and commits. Check issue tracking and docs and knowledge connections for similar issues/postmortems in the past and see how they were addressed and whether any useful information exists to help debug or resolve the current issue. If you can figure out what the code fix is based on the evidence, then open a PR with the fix. Make sure the pr description includes all the evidence and reasoning about why this PR will fix the issue and your confidence level in the fix working.

Return:

• classification
• customer impact and urgency
• what the customer is asking or reporting
• confirmed facts
• likely cause
• recommended customer response
• internal next action
• missing information, if any

Additionally, ensure the final response formatting is visually consistent. All section headers and subsection headers (for example: classification, customer impact and urgency, confirmed facts, likely cause, etc.) must always be bolded consistently in both the returned output and the private note formatting posted to Pylon.

Also post the whole analysis as private note on the pylon ticket that triggered this message using the bot/service-account Pylon connection. Do not use a personal Pylon API token.

If the issue is classified as a billing question, skip the workflow entirely and post only this private note on the Pylon ticket that triggered this message using the bot/service-account Pylon connection: "Skipping CodeRabbit bot analysis since this is a billing-related issue."

Final Plan

Classification

Product bug in Codex plugin authentication guidance, potentially amplified by ephemeral credential storage.

Customer impact and urgency

High workflow impact; P2 medium. Reauthentication halts unattended Codex review/fix loops.

What the customer is reporting

CodeRabbit appears to require authentication for each GitLab repository during Codex loops.

Confirmed facts

• Authentication should persist per machine and automatically resolve each repository’s organization.
• The plugin proactively checks authentication before every review.
• Linear issue ENG-4340 documents the same behavior.
• No customer-attributable Datadog errors indicated a platform outage.

Likely cause

The plugin’s unconditional auth preflight triggers unnecessary interactive login. Disposable Codex environments may also be losing stored credentials.

Recommended customer response

You should not need repository-specific authentication. Update to CLI v0.7.0 and authenticate once inside the Codex runtime. For ephemeral/headless environments, use an Agentic API key and persistent credential storage. Please provide coderabbit doctor, redacted coderabbit auth status --agent, the exact error, and whether GitLab is hosted or self-managed.

Internal next action

• Full analysis posted privately to Pylon #27481.
• Opened PR #7 to make authentication reactive.
• Change digest: 🛠️ plugin manifest +1/-1; 🛠️ review skill +4/-12; total +5/-13.
• CodeRabbit check is pending.

Missing information

CLI/plugin versions, runtime persistence model, GitLab deployment type, exact auth error and timestamp.

Initiative Context

• Initiated by: fariha
• Source thread: https://slack.com/app_redirect?team=T05K3R5Q6GH&channel=C0B1AFCP40J&cid=C0B1AFCP40J&message_ts=1785282815.775979

Summary by CodeRabbit

• Improvements
  • Review commands now start directly using saved credentials.
  • Authentication checks and login prompts occur only when a review reports an authentication error.
  • Added a non-interactive API key login option.
  • Simplified setup requirements for fresh installations.

[linear]

ENG-4340

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: aabc2eb2-e3f8-463f-9c74-d21428f8cc38

📥 Commits

Reviewing files that changed from the base of the PR and between 0f66928 and e9a64bb.

⛔ Files ignored due to path filters (1)

• plugins/coderabbit/.codex-plugin/plugin.json is excluded by !**/*.json

📒 Files selected for processing (1)

• plugins/coderabbit/skills/coderabbit-review/SKILL.md

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• coderabbitai/bitbucket (manual)

📜 Recent review details

🧰 Additional context used

🪛 SkillSpector (2.4.4)

plugins/coderabbit/skills/coderabbit-review/SKILL.md

[error] 29: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.

(Privilege Escalation (PE3))

🔇 Additional comments (2)

plugins/coderabbit/skills/coderabbit-review/SKILL.md (2)

27-32: LGTM!

---

33-33: 🔒 Security & Privacy

Sensitive Data Exposure (CWE-214)

Reachability: External

Keep the current API-key login guidance. <key> is a placeholder, and the CLI only documents API-key auth via --api-key, so there’s no supported env/stdin path to mandate here.

			> Likely an incorrect or invalid review comment.

---

📝 Walkthrough

Walkthrough

The review skill now starts the requested review command without a preliminary authentication check. If the command returns an explicit authentication error, it checks authentication status, performs agent or API-key login as needed, and retries the same review once.

Poem

I’m a rabbit with credentials bright,
I hop straight into review tonight.
If auth says “no,” I check and renew,
Then retry the review—just once, not two.
Squeak, click, done! 🐇

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and clearly describes the main change to reduce repeated authentication prompts during CodeRabbit Codex reviews.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}