Severity: high · found on PR #309, 2026-08-06
What's wrong
The ai-review reviewer has produced no review since 2026-08-05 evening, and
fails in a way that reads as a normal outcome. Every run since then posts:
No review: the reviewer did not produce a result. See the workflow run.
The workflow itself concludes success — all three jobs (Resolve pull request context, Run the reviewer, Publish the review) are green — so nothing on the
pull request page says the reviewer is broken rather than merely quiet. The check
is advisory and not required, which is correct, but it means the only signal is a
sentence in a comment that looks like it could be about the diff.
When it started
Last working review: PR #265, merged 2026-08-05 17:43 UTC.
First failure: PR #268, merged 2026-08-05 18:33 UTC.
| PR |
merged |
result |
| #240 |
08-05 15:14 |
real review |
| #260 |
08-05 16:21 |
real review |
| #265 |
08-05 17:43 |
real review |
| #268 |
08-05 18:33 |
no result |
| #270, #272, #274, #275 |
08-05 evening |
no result |
| #289, #291, #294 |
08-06 |
no result |
| #309 |
08-06 |
no result, twice (re-labelled) |
So eleven consecutive pull requests have merged with no automated review,
including three releases, while the process in CLAUDE.md treats the reviewer as
the thing you ask when you believe a branch is finished.
Where it fails
.github/workflows/ai-review.yml, the Review the diff step. The Codex CLI dies
about 12 seconds in:
/home/runner/work/_actions/openai/codex-action/…/dist/main.js:23546
reject(new Error(`${program2} exited with code ${code}`));
Error: codex exited with code 1
##[error]Process completed with exit code 1.
Twelve seconds is too fast to be the model working and failing — it is the shape
of an authentication, quota or entitlement refusal at the first API call. The
step's own output is not surfaced beyond the Node stack trace, so the actual
reason is not in the log we can read. The Normalize the result step then
catches the missing artefact and writes the generic sentence.
Worth checking in order: the OpenAI credential's validity and quota, whether the
openai/codex-action pin (52fe01e) still matches the CLI's expectations, and
whether anything changed on 2026-08-05 evening between #265 and #268.
Why severity:high
Not because a build is red — nothing is red. Because the repository's stated
review process depends on this, and it has been silently absent for eleven
merges. A gate that reads green because the thing is not in it is the exact shape
of #143 and #165; this is the same failure applied to the reviewer itself.
Two fixes, and the second matters as much as the first:
- Whatever is making
codex exit 1.
- Surface the failure.
Run the reviewer should not conclude success when
it produced nothing, and the comment should distinguish "the reviewer failed"
from "the reviewer found nothing". Otherwise the next outage is found the same
way this one was — by accident, eleven pull requests later.
How you would know it was fixed
A pull request with a deliberate defect in it gets a finding. And a run with the
credential removed posts a comment that says the reviewer failed, not that it had
nothing to say.
Related
Cluster: Tests, CI, dependencies (#109 #130 #132 #143 #154 #155 #156 #158
#162 #165 #188 #203 #215). Nearest relatives are #143 and #165 — both
"a gate that reads green because the thing is not in it", which is precisely this.
Not a duplicate: those are about coverage and CI parity, this is the reviewer.
docs/code-review.md describes the reviewer's behaviour and should say what a
failed run looks like once (2) is done.
Severity: high · found on PR #309, 2026-08-06
What's wrong
The
ai-reviewreviewer has produced no review since 2026-08-05 evening, andfails in a way that reads as a normal outcome. Every run since then posts:
The workflow itself concludes success — all three jobs (
Resolve pull request context,Run the reviewer,Publish the review) are green — so nothing on thepull request page says the reviewer is broken rather than merely quiet. The check
is advisory and not required, which is correct, but it means the only signal is a
sentence in a comment that looks like it could be about the diff.
When it started
Last working review: PR #265, merged 2026-08-05 17:43 UTC.
First failure: PR #268, merged 2026-08-05 18:33 UTC.
So eleven consecutive pull requests have merged with no automated review,
including three releases, while the process in
CLAUDE.mdtreats the reviewer asthe thing you ask when you believe a branch is finished.
Where it fails
.github/workflows/ai-review.yml, theReview the diffstep. The Codex CLI diesabout 12 seconds in:
Twelve seconds is too fast to be the model working and failing — it is the shape
of an authentication, quota or entitlement refusal at the first API call. The
step's own output is not surfaced beyond the Node stack trace, so the actual
reason is not in the log we can read. The
Normalize the resultstep thencatches the missing artefact and writes the generic sentence.
Worth checking in order: the OpenAI credential's validity and quota, whether the
openai/codex-actionpin (52fe01e) still matches the CLI's expectations, andwhether anything changed on 2026-08-05 evening between #265 and #268.
Why severity:high
Not because a build is red — nothing is red. Because the repository's stated
review process depends on this, and it has been silently absent for eleven
merges. A gate that reads green because the thing is not in it is the exact shape
of #143 and #165; this is the same failure applied to the reviewer itself.
Two fixes, and the second matters as much as the first:
codexexit 1.Run the reviewershould not concludesuccesswhenit produced nothing, and the comment should distinguish "the reviewer failed"
from "the reviewer found nothing". Otherwise the next outage is found the same
way this one was — by accident, eleven pull requests later.
How you would know it was fixed
A pull request with a deliberate defect in it gets a finding. And a run with the
credential removed posts a comment that says the reviewer failed, not that it had
nothing to say.
Related
Cluster: Tests, CI, dependencies (#109 #130 #132 #143 #154 #155 #156 #158
#162 #165 #188 #203 #215). Nearest relatives are #143 and #165 — both
"a gate that reads green because the thing is not in it", which is precisely this.
Not a duplicate: those are about coverage and CI parity, this is the reviewer.
docs/code-review.mddescribes the reviewer's behaviour and should say what afailed run looks like once (2) is done.