Codex GitHub review and repair task can enter an unbounded new-commit loop

What issue are you seeing?

A managed Codex GitHub review and a separate Codex repair task can form this loop:

review finding → task fixes and pushes → “New commits” review → another finding → repeat

There is no visible shared round limit, scope or usage checkpoint, or owner-approval gate.

I observed this in my own public repo:

• Token Ledger PR #70: 44 Codex reviews and 66 review threads; the latest review was again triggered by New commits.

Not every commit or finding was caused by Codex, and some reviews were manually requested. The bug is the missing stop condition when these two Codex features are used together.

What steps can reproduce the bug?

1. Enable managed Codex review for new PR commits.
2. Ask a separate Codex task to fix the PR review findings, push, and monitor until clean.
3. The task fixes a finding and pushes.
4. The push triggers another review with Review trigger: New commits.
5. If that review finds something else, the cycle repeats without a product-level limit.

What is the expected behavior?

After one repair round and one verification review, Codex should pause if findings remain and require owner approval before continuing. It should deduplicate reviews for the same head and warn when repeated rounds materially increase PR scope or usage.

Additional information

Related, but distinct:

• #37964 involves two tagged review bots reacting to each other. This case needs only one managed reviewer plus a separate Codex repair task.
• #19112 requests an intentional persistent repair loop; this is an accidental loop without safeguards.
• #5547 concerns findings per review, not repeated new-commit reviews.
• #40721 concerns trigger coverage, not termination.
• #35816, #35892, #38375, and #38989 cover broader local, subagent, or non-convergence behavior without this specific hosted GitHub review → repair → push topology.

Environment: Codex desktop 26.825.51511, bundled CLI 0.151.0-alpha.7.2, macOS 27.0 arm64.

No files, tests, or entry points are named. Start by tracing the managed GitHub review path for the “New commits” trigger and how separate repair tasks push changes, then compare the behavior with the related issues listed. Done should include an enforced repair and verification limit, approval before further rounds, and protection against duplicate or scope-expanding review cycles.