/codex:review caps findings at ~3 — add configurable max or return all material findings

[coolk8]

Problem

Native /codex:review consistently returns at most 2–3 findings per run, regardless of diff size. On a ~1000-line refactor touching 13 files, the reviewer found real P1/P2 bugs — but only 2–3 per iteration. It took 8 sequential review→fix cycles to surface ~20 legitimate issues that were all present in the original diff.

This forces a tedious manual loop:

1. /codex:review → get 3 findings
2. Fix them
3. /codex:review → get 3 more
4. Fix them
5. Repeat 6+ more times

Each cycle costs tokens and wall-clock time. The reviewer clearly can find more issues — it just stops early.

Expected behavior

The reviewer should return all material findings it discovers, not an arbitrary subset. At minimum, provide a way to configure the cap:

/codex:review --max-findings 10

or a setting in /codex:setup:

{ "reviewMaxFindings": 10 }

Context

• /codex:adversarial-review uses a local prompt (prompts/adversarial-review.md) without a hard cap — but native review goes through the review/start server API where the limit appears to be baked in.
• Issue Feature: infra-aware adversarial review prompts + auto-scaling by diff size #6 mentions "Top 3 focus areas only" for diffs <50 lines, but this cap seems to apply universally regardless of diff size.
• A reasonable default could scale with diff size (as Feature: infra-aware adversarial review prompts + auto-scaling by diff size #6 proposes), but even a static configurable max would be a big improvement.

Workaround

Currently using iterative review→fix loops, which works but is slow and expensive.

---

This issue was co-authored with Claude Code (Opus 4.6) during a real review session where the 3-finding cap was the bottleneck.

[dhruvac29]

I checked this against the current main branch (v1.0.4). From the plugin side, /codex:review calls the native reviewer through review/start in plugins/codex/scripts/lib/codex.mjs.

The generated app-server type for ReviewStartParams currently only includes:

{
  threadId: string;
  target: ReviewTarget;
  delivery?: ReviewDelivery | null;
}

So I don’t think a plugin-only --max-findings flag can change the reviewer behavior yet, unless the app-server already supports an unexposed field.

Would maintainers be open to exposing something like maxFindings on review/start? If that API exists or gets added, I’d be happy to contribute the plugin-side CLI plumbing, docs, and tests for:

/codex:review --max-findings 10

Until then, the only public plugin-side workaround I see is documenting /codex:adversarial-review for cases where users need a less constrained review pass.

Small note: I generated local app-server types with npm run prebuild to verify the protocol. That created plugins/codex/.generated/...; don’t include that generated directory in a PR unless the repo expects it.