Qodo review bot has failed on every recent PR since Aug 29

[auroraxo]

Problem

The repository's Qodo review bot appears to fail on every PR. The automatic review posts only:

Sorry, something went wrong. We weren't able to complete the code review on our side. Please try again manually by commenting /agentic_review on this PR.

The suggested manual retry fails identically.

Reproduction

1. Open any recent PR, for example fix(providers): make the base persistent comment actually persist #3254.
2. Observe the automatic failure comment.
3. Comment /agentic_review.
4. The bot responds within seconds with the same failure: fix(providers): make the base persistent comment actually persist #3254 (comment)

Scope / evidence

I sampled the bot comments on the 200 newest PRs via the GitHub API:

• 195/195 bot comments were failures (0 successful reviews).
• Last successful review I found: feat(models): support Grok 4.5/4.6 on xAI and OpenRouter #2871 at 2026-08-29 11:23 UTC.
• First failure I found: chore: consolidate linting on ruff, replace flake8 #2880 at 2026-08-29 19:42 UTC.
• Latest confirmed failure: fix(providers): make the base persistent comment actually persist #3254 at 2026-09-10 00:31 UTC.

So this appears repo-wide rather than PR-specific and has persisted for roughly 11 days.

Expected

Automatic reviews complete, or /agentic_review successfully retries a failed review.

Actual

Both automatic and manually retried reviews return only the generic failure message, leaving contributors without the configured review signal.

[auroraxo]

Measured this across the PR history rather than leaving it as an impression. The window is sharper than the title says, and there is a clean bisect boundary.

Scanned: every qodo-code-review[bot] comment on the last 240 PRs (#2866-#3264), 263 bot comments in total.

Last successful review	#2871, 2026-08-29T11:23:14Z
First failure after it	#2880, 2026-08-29T19:42:17Z
Failures since	230, across 229 distinct PRs
Successes since	0
Most recent failure	#3264, 2026-09-10T03:41:57Z

So it is not intermittent and not degraded — it is a hard changeover somewhere in that eight-hour gap on Aug 29, and nothing has produced a review in the 12 days since. Every one of the 263 comments is either a real review (all before the boundary) or the identical Sorry, something went wrong body (all after it). There is no third shape and no partial success.

The retry advice in the failure message does not work. The bot's own body says to comment /agentic_review manually. That has been done 16 times by 8 different people (@Ricky-7-Yan, @Tiancheng-Xu, @noooooooookro, @nanjingya, @yashaskn8, @macjayz, @Carlos0196 and me), on #3065, #3140, #3148, #3156, #3202, #3219, #3222, #3232, #3239, #3243, #3244, #3246, #3251 and #3254. All 16 fall after the boundary, and all 16 were answered with the same failure. I would suggest that instruction is worth removing or changing regardless of the underlying cause, since it currently sends every contributor down a path that has a 0/16 success rate and makes them think they did something wrong.

Why this is worth a maintainer's attention rather than just noise: the failure is silent in the direction that matters. A PR that gets no review still gets a bot comment, so the queue looks reviewed at a glance. #3227, #3243, #3254, #3257, #3259, #3262 and #3264 are all currently sitting with a bot comment and no actual review.

This is entirely outside the repo — no commit here is implicated, and the boundary does not line up with anything merged that day, which is consistent with it being a change on the Qodo service side or an expired/rotated credential on the app installation. I cannot see either from outside, so this is as far as I can take it. Reproduction is just: open any PR and wait.

Happy to re-run the scan on request; it is a straightforward pass over the issue-comments API.

[auroraxo]

Correction and a sharper diagnosis on my earlier comment here.

I previously reported this as a Qodo-side outage, based on measuring only this repo: 230 consecutive Sorry, something went wrong reviews across #2880-#3264 with zero successes since 2026-08-29, and /agentic_review retries 0/16. That data still holds, but the conclusion I drew from it was too broad, and the correction matters because it changes who can fix this.

I sampled the same bot account (qodo-code-review[bot]) across other public repositories via the GitHub search API and classified every comment by the same failure signature.

Result: 241 comments across 134 other repos — 241 successes, 0 failures.

The contemporaneous slice is the decisive part. In the window 2026-09-10 01:00-05:59Z:

	outcome
159 review comments across 86 other repos	all succeeded
this repo, PR #3262 @ 03:19:42Z	Sorry, something went wrong
this repo, PR #3264 @ 03:41:57Z	Sorry, something went wrong

Same bot, same hours, opposite outcomes. Examples of successes in that window: daqifi/daqifi-nyquist-firmware#957 @ 01:05Z, mrploch/ploch-data#186 @ 01:06Z, rmusser01/tldw_server#2627 @ 01:09Z, gandli/ai-proofduck-extension#643 @ 05:01Z.

So the service is healthy and the failure is scoped to this repository's installation. That reframes it from "wait for Qodo to recover" (which is what my previous comment implied, and 12 days of waiting has not fixed) to something a maintainer with admin rights can act on. Most likely candidates, in the order I would check them:

1. The GitHub App installation for this repo — a revoked/expired token or a permission scope dropped around 2026-08-29 fails per-install while every other install keeps working.
2. Repo-scoped Qodo configuration (.pr_agent.toml / repo settings) that the reviewer chokes on. This repo is unusual in that it is the source of the tool reviewing it.
3. Org-level seat/quota binding attached to this repo's owner rather than to the service.

I cannot distinguish between those three from outside — they are all invisible without admin access to the installation, which is why I am handing this over rather than continuing to measure. Reinstalling the app on this repo is the cheapest test of (1).

Happy to re-run the cross-repo measurement after any change to confirm whether it clears.

[auroraxo]

One more discriminator, measured from the bot's own comments rather than inferred from the generic error:

The whole hosted command pipeline stopped, not only /agentic_review

Before the cutoff, a normal PR got two distinct Qodo comments:

1. PR Summary by Qodo — the configured /describe path
2. Code Review by Qodo — the configured /agentic_review path

Across PRs #2860–#2878 before the cutoff I found 15 summary comments and 16 successful review comments. After the cutoff I scanned 364 issues/PRs (#2900–#3266) and found 213 identical failure comments, 0 summaries, and 0 successful reviews.

The chronology is clean:

• last successful bot activity: feat(models): support Grok 4.5/4.6 on xAI and OpenRouter #2871, 2026-08-29 11:23Z
• first failure: chore: consolidate linting on ruff, replace flake8 #2880, 2026-08-29 19:42Z
• a retry on the previously successful feat(models): support Grok 4.5/4.6 on xAI and OpenRouter #2871 also failed on Aug 30

That older-PR retry matters: this is not caused by the diff in the first failing PR. And because /describe disappeared at exactly the same boundary as /agentic_review, a reviewer-specific setting in .pr_agent.toml is now an unlikely cause. The failure appears to happen before the hosted service dispatches either configured command.

I also tested the most obvious repository-state candidate from that eight-hour window. The repo migrated to uv at 19:11Z, removing requirements.txt and setup.py. But among other repos reviewed by the same bot I found 21 repos with uv.lock and no requirements.txt; they produced 143 successful Qodo comments and 0 failures in the sampled set. So a general "Qodo cannot handle uv-only repos" explanation is falsified.

This narrows the maintainer-side check: start with the repository's hosted Qodo/App binding (including any repo move/owner binding), not the individual review configuration. The app can still publish its generic failure comment, but neither configured command reaches output.

[naorpeled]

Hey @auroraxo,
Thanks for raising this, I fixed the issue 🙏