›_ Codex Issues
Codex Issues / #38405

GitHub review connector quota failure leaves required exact-head review blocked without retry guidance

Open 💬 3 comments Opened Aug 13, 2026 by henrymodisett

Problem

The GitHub-hosted Codex reviewer can reject a requested security review with only:

You have reached your Codex usage limits for security reviews. Please try again later.

Example: https://github.com/autumngarage/touchstone/pull/827#issuecomment-5283708031 (2026-08-13). The PR is public and the review was requested against exact head e9780c11116c17b4ba5aa7c8767082fdf22394a4.

Impact

This repository requires PR-visible exact-head review before merge. A quota rejection therefore blocks delivery, but the response provides no retry-after time, quota window, observable quota state, or durable queued retry. Re-requesting blindly risks duplicate work and further quota consumption. The immediately preceding PR needed multiple review/fix rounds, which appears to have exhausted the quota during normal feedback handling.

Requested behavior

Please provide at least one actionable recovery signal:

  • a concrete retry-after timestamp/duration,
  • a machine-readable quota status, or
  • automatic queuing/retry of the existing exact-head request when quota becomes available.

The review result should remain bound to the requested head so recovery does not require moving the commit or weakening the merge gate.

View original on GitHub ↗

3 Comments

henrymodisett · 14 days ago

Additional failure mode observed on 2026-08-13 while delivering autumngarage/touchstone#827:

  • Exact-head review request: https://github.com/autumngarage/touchstone/pull/827#issuecomment-5285553588
  • Requested at 19:41:18Z for head 978ff0648b43608132671158e006b8658e83fe24.
  • More than eight minutes later, the connector had produced neither its normal eyes acknowledgement reaction, a review result, nor a quota/error comment.
  • The repository's required exact-head review binding correctly remained failed, so delivery was blocked with no observable retry state or guidance.
  • I did not post a duplicate request because the repository deliberately binds one review request per head.

This is distinct from the explicit quota response in the original report: here the trigger is silently unacknowledged.

henrymodisett · 14 days ago

Further evidence from the same PR shows an acknowledged-but-stalled failure mode, distinct from the original unacknowledged trigger:

The connector therefore needs observable task state after acknowledgement (queued/running/failed), not only an emoji reaction, and a deterministic recovery signal when an accepted task never completes.

henrymodisett · 14 days ago

Fresh reproduction on autumngarage/touchstone PR #828 (2026-08-13), with a corrected timeline:

The quota output therefore belonged to the separately enabled automatic Security Review, not the manual Code Review request. The signed-in Codex Usage panel showed 81% weekly usage remaining, 1,145 credits, credit use enabled, and auto-reload active. Repository settings had Security Review set to Review all PRs / On every push.

This still appears incorrect or misleading: a Security Review quota failure is posted as an undifferentiated top-level Codex comment on a PR even when account-wide usage and credits are available. The requested Code Review did complete independently.