Why does Codex keep finding new issues every time it reviews its own code?

Because the next review reads different code, and no single pass is built to list everything. Each fix adds lines to the diff, and the review rubric in the open-source Codex code flags only bugs "introduced in the commit". Each pass reports what clears a bar, such as "only P0 and P1 issues" in GitHub. Some "new" findings are old code: the Claude Code team at Anthropic traced about 59% of what its own reviewer kept flagging, with git blame, to code present since the reviewer's first pass. Four levers damp the loop: a written bar, a definition of done, when the reviewer runs, and a stopping rule such as a round cap.

The comment that closed issue #4710 on the openai/codex tracker on 7 January 2026 says /review "is designed to find and report only a few bugs in each pass", while the review rubric says "Do not stop at the first qualifying finding." Request #5547, to make the number of issues configurable, was open as of 21 October 2026.

Every fact below comes from each vendor's own pages as I read them on 21 October 2026, and none of these vendors saw this text before publication.

Reviewer	What starts the next pass	What happens to earlier findings	Documented brake or finish line
Codex /review (CLI, app, IDE)	you run /review again, as OpenAI's prompting guide suggests after fixes	the earlier review stays in the same chat by default; how a new pass treats it was not found in Codex's docs as of 21 October 2026	custom review instructions; a stopping rule for repeated reviews was not found in Codex's docs as of 21 October 2026
Codex code review in GitHub	an @codex review comment, or automatic reviews timed by the Review trigger setting	not found on its GitHub page or in Codex's docs as of 21 October 2026	only P0 and P1 issues; a ## Code Review Rules section in AGENTS.md
GitHub Copilot code review	a manual re-request; on each push only with Review new pushes, otherwise "it will only review a pull request once"	resolves its comments that a later commit addresses and lists previously missed findings apart from new ones (GitHub changelog); its docs say it may repeat comments you resolved or downvoted	custom instructions such as .github/copilot-instructions.md; leave Review new pushes off
CodeRabbit	each new commit, as an incremental review; @coderabbitai full review starts from scratch	"Fresh insights without repeating resolved comments"	review instructions; automatic reviews pause after 5 reviewed commits by default
Cursor Bugbot	each PR update by default, or once per pull request with frequency: oncePerPr	reviews only the changes since its previous review and reads earlier PR comments "to avoid duplicate suggestions and build on prior feedback"	rules in .cursor/BUGBOT.md; its check ends in success only when it found no issues and no Bugbot comments from earlier runs are unresolved
Claude Code Review (managed)	After every push (where a repository added from the admin page starts), Once after PR creation, Manual, or @claude review	the next review resolves a thread when it judges the issue fixed; a later automatic review focuses on what changed	Manual or Once after PR creation mode; rules in REVIEW.md
Claude Code /code-review (local)	you run /code-review again	when Claude fixes findings later in the session, it reports them again; in the findings list of a host app such as the desktop app, each is marked fixed, skipped, or no change needed	--max-findings sets how many findings a review reports

The next review reads different code

After a round of fixes, the diff that Codex's /review reads (base branch, uncommitted changes or one commit) holds lines the first pass never saw, and the rubric's test of "introduced in the commit" now covers your fixes. GitHub's Copilot tutorial advises a re-review after substantial changes "to check whether new risks were introduced while addressing earlier feedback." The Claude Code team adds the agent case: "Noise costs more when the author is an agent.", because "An agent fixes it, which means another commit and another round of review."

One pass reports what clears its bar

The rubric sets the bar in three sentences that only make sense together: "Output all findings that the original author would fix if they knew about it.", "If there is no finding that a person would definitely love to see and fix, prefer outputting no findings.", and "Do not stop at the first qualifying finding." These sentences were already in the review prompt when the #4710 comment was written, so the comment and the rubric are not a before and after. A number or limit per pass was not found on Codex's code review, GitHub or GitLab pages or in its full docs export as of 21 October 2026.

Other vendors write the same caveat. Copilot "is not guaranteed to spot all problems or issues in a pull request." CodeRabbit lists "Previous reviews may have missed something" as a reason for a full review. Anthropic's /code-review takes --max-findings to report up to a set number of findings, or every finding, "in place of the review's usual limit."

Some of the "new" findings are old code

On 15 October 2026 the Claude Code team at Anthropic wrote "Review has to converge." One of their CLI pull requests "went through more than fifty rounds of review and fixes overnight before its author stopped it." Then: "When we ran git blame on what the reviewer kept flagging, about 59% of it was code that had been there since the reviewer's first pass." In their words, "The reviewer was rarely finding new bugs, it was finding a few more old ones each round." These are one team's numbers for its own reviewer on its own code, measured with git blame. A measurement like it for Codex was not found in Codex's docs or in OpenAI's post on code review rules as of 21 October 2026.

Its own code

Codex's docs separate the reviewer from the writing session in a few ways: the CLI starts "a dedicated reviewer", though its review still appears in the same transcript; the app's Review with Codex button starts a review "in a new chat"; the IDE setting chatgpt.reviewDelivery set to detached opens a separate review chat; and review_model gives reviews their own model. The argument that a reviewer should differ from the author is CodeRabbit's: "the perspective of the reviewer differs from that of the code generator, whether human or machine".

What happens to earlier findings

The first Codex /review stays in the conversation: in the CLI, "The review appears as a turn in the transcript.", and the app and IDE extension review in the current chat by default. What a new review pass does with earlier findings, and when to stop reviewing, was not found on Codex's code review and GitHub pages or in its full docs export as of 21 October 2026; the export describes earlier findings and a stopping rule only for Codex Security scans. OpenAI's documented order is the loop itself: "Apply fixes based on review feedback, then rerun /review to confirm you resolved the issues."

Pull request reviewers document more. Claude Code Review "resolves its earlier thread when it judges the issue fixed", and a later automatic review "focuses on what changed since the last review and posts fewer nits and pre-existing findings", while @claude review "covers the whole pull request again." Per GitHub's changelog, Copilot code review now resolves a comment "during its rereview" once a pushed commit addresses it (11 September 2026), and since 18 September its overview lists "Previously missed" findings: "Issues not introduced by a new commit, but newly found in your existing changes by Copilot's subsequent review." Its docs still say a re-review "may repeat the same comments again, even if they have been dismissed with the "Resolve conversation" button or downvoted with the thumbs down".

Sigma (Mnemoverse, the author's company), in closed beta, reviews pull requests on GitHub, and its homepage says "Start with reviews on request." Its docs say "After a push, an Automatic reviewer first runs a full review of the new head." and that Sigma then "schedules a scoped recheck of that reviewer's earlier open and deferred findings on the same pull request", while "An On request reviewer runs no full review after a push, so nothing follows up on its findings". Sigma runs on Claude Code and OpenAI models and reviews its team's own repositories every day; teams can ask for access on its homepage, which says "A request does not grant access automatically."

What damps the loop

The first lever is a written bar: Codex in GitHub reads a ## Code Review Rules section in AGENTS.md, and OpenAI suggests you "narrow or remove guidance that produces noise"; Claude Code Review reads REVIEW.md, where "A cap like "report at most five nits" keeps reviews actionable." Copilot reads custom instructions such as .github/copilot-instructions.md, CodeRabbit takes review instructions, and Bugbot reads .cursor/BUGBOT.md files.

The second is what done means. OpenAI's Codex guide asks "What should be true before the task is complete, such as tests passing, behavior changing, or a bug no longer reproducing?" and adds "Codex can do this loop for you, but only if it knows what "good" looks like."

The third is when the reviewer runs: the Review trigger for Codex in GitHub, Review new pushes for Copilot, the pause after 5 reviewed commits at CodeRabbit, oncePerPr for Bugbot, and the three modes of Claude Code Review, where After every push "runs on each push, multiplying cost by the number of pushes".

The fourth is a stopping rule. The Claude Code team lists four changes as its own practice, not a product setting: "A round cap. After three rounds, the reviewer asks the author to step back and reconsider the approach.", "Diff-only re-review after the first few passes.", "Flag the class of bug, so the author fixes every instance, not one line." and "No repeats of findings already posted." Their chart of internal pull requests shows the share passing after one review and fix round rising from 65% to 78% after those changes. Documented relatives carry product names: deep scans in Codex Security, a different OpenAI product, "Stop after this many consecutive completed worker scans produce no new findings." (stop_after_no_new), and Bugbot Autofix, when it commits to an existing branch, has "(max 3 attempts per PR to prevent loops)".

Check which cause you have

Run the reviewer twice on the same diff with no edits in between; anything new on the second run did not come from your fixes. Then loop fix and re-review, labeling each new finding: in lines the fix changed, in lines present at the first pass (git blame, as the Claude Code team did), or outside the diff. Count rounds to a clean pass. Old lines call for a written bar or flagging classes of bugs; fix lines call for a definition of done with tests. Either way, write down where you stop.

Sources, all read on 21 October 2026; this text describes them as of that date. OpenAI: code review, Codex in GitHub, Codex in GitLab, prompting, Codex guide, Codex Security scans, full docs export, code review rules post, review rubric, issue #4710, request #5547. GitHub: Copilot code review, using it, pull request lifecycle, changelog of 11 September and 18 September. CodeRabbit: pull request reviews, automatic reviews, review commands, FAQ. Cursor: Bugbot. Anthropic: Code Review setup, pull requests, customizing, costs, /code-review, Claude Code team post. Sigma: homepage and replies and rechecks.