Codex reviews every PR including mine — is that acceptable, and what is the trigger surface?

[simonoppowa]

Part of #1023

Question

Codex reviews every PR, including mine. Is that acceptable — and what is the actual trigger surface?

Rewritten after #1034 chose Codex. The original question was how to express author != simonoppowa. That is not expressible: Codex has no author filter, and the only author-scoped setting is the inverse ("Review my pull requests"). So the scope decision this map opened with is reversed, and the real question is what to do about the overlap.

Decide:

• Is reviewing my own PRs tolerable, or actively bad? /code-review already runs locally on my branches, so this is duplicated work on the majority of traffic — I author most PRs here. It costs quota (shared 5-hour rolling windows with all other Codex usage) and adds a second opinion I did not ask for on work I already reviewed. Against that: a second pass is not worthless, and there is no way to switch it off per-author anyway.
• The trigger surface. Establish precisely what the connected-repo settings expose: the "Automatic reviews" toggle, and the per-repo Auto code review / Review trigger overrides. Is automatic-on-open all-or-nothing, or is there a middle setting?
• Mention-only as a deliberate choice. If automatic proves too noisy or too costly, @codex review on demand is the fallback — but it surrenders the unattended property that justified this whole map. Decide what would make that trade worth it.
• Draft PRs — reviewed or not.
• Dependabot. 11 open, all targeting develop, all created 2026-08-21 to 08-30. A bump diff has little to read and Dependabot rebases often. Does Codex review them, can it be stopped from doing so, and does each rebase burn another review?
• Backfill. docs(readme): name every contact in What leaves your device #989 #1010 and feat: add scan and create-custom actions to no-results search state (#578) #995 are open and unreviewed. Does enabling automatic reviews reach existing open PRs, or only new ones?

Quota context from #1026's sibling research: reviews draw the same budget as all other Codex usage on 5-hour rolling windows; at the limit reviews simply stop, and Plus can buy credits.

[simonoppowa]

A case this ticket should cover, surfaced while resolving #1029.

Since Codex has no author filter, it will also review your own release/* → main PRs — the most sensitive ones in the repo. The review rules written in #1029 are deliberately contributor-shaped: a five-finding ceiling, "write for that person", observations rather than demands. That is the wrong posture for a release PR, where you want completeness over gentleness and there is no stranger to protect.

It was left out of the rules section rather than spending ~200 bytes on a case with no worked example yet. Decide here whether it needs its own paragraph in AGENTS.md, a per-PR @codex review for ... comment when it matters, or nothing at all.

Worth weighing alongside: an empty 2.2.0 release has actually shipped from this repo before, so the release path has a track record of quiet failures that a thorough reviewer might have caught.

[simonoppowa]

Decision: automatic reviews on, for everything — trigger "On PR open", policy "Review all PRs"

Accept the 80.5%. Three of the four options are eliminated on evidence, and the survivor's real cost is smaller than the raw split suggests.

The narrowing that exists all points the wrong way

The App exposes exactly three "when" controls: a repo Code review master toggle, a binary Automatic reviews toggle, and two dropdowns — an author policy (Review all PRs / Review my PRs / Review team PRs / Follow personal preferences) and a trigger event (On PR open / On every push / Smart Trigger).

The author axis is the trap. Worked against 161 / 24 / 15, every value that drops my own PRs drops the outside PRs too, or first:

• Review my PRs — selects exactly the 80.5% to skip. Worse, @codex review says “create a Codex account and connect to GitHub” although Codex web can access the repo openai/codex#30168 (2026-06-26) reports it also gates which PRs Codex may run on at all, which would silently kill the manual mention path on the outside PRs this effort exists to serve. Single unverified report, total downside. Leave the policy on "Review all PRs".
• Review team PRs — means ChatGPT workspace members; on a solo Plus account it collapses into Review my PRs.
• Follow personal preferences — defers to each PR author's own Codex settings. Fork contributors on a public AGPL repo have none, so it reviews almost nothing.

There is no exclude-my-PRs, no author denylist, no external-contributors-only. Branch/label/bot filters were requested in openai/codex#13597 and closed not_planned (2026-04-03). Bot coverage is deliberate, not an oversight: #5669 "Include Dependabot-authored PRs" shipped completed 2025-10-25. No path or glob triggering exists anywhere. AGENTS.md governs what is checked, never whether a review runs.

Why not mention-only — the closest thing to a controlled experiment

danny-avila/LibreChat runs Codex with automatic reviews off, driven entirely by hand: 44 of 44 Codex-touched PRs preceded by a human @codex review, all 16 untouched PRs with zero mentions. Perfect separation. Its coverage:

author class	reviewed
OWNER	33/38 (87%)
COLLABORATOR	8/8 (100%)
outside	1/10 (10%)

A maintainer in the same structural position, with five people available to type the trigger, reviews 10% of outside PRs. Human triggers track attention — and attention is exactly what failed here: #1010 and #995 have been open, non-draft and unreviewed since 2026-09-01. Mention-only does not fix that failure, it formalises it.

Why not the clever workflow

Posting @codex review from a workflow when pull_request.user.login != 'simonoppowa' would reconstruct the missing filter with no secret. It is dead today, on two independent counts, and the second is the ugly one:

1. A fork-triggered pull_request run gets a read-only GITHUB_TOKEN and cannot comment at all. Fixable — pull_request_target runs in the trusted base context and is documented for exactly "label or comment on pull requests from forks", safe here because the job would never check out PR head.
2. Codex refuses github-actions[bot]. The gate is not repo permission but whether the commenting account resolves to a Codex workspace with this repo enabled. Seven bot-posted triggers across Extelligence-ai/bagel Bug: App allows saving a food with nonsensical or inconsistent nutritional information #213–Data import issues with FoodData Central #222 (2026-09-02/03) each drew "To use Codex here, create a Codex account and connect to github" within 6–10 seconds, while human triggers on the same PRs produced real reviews.

That is worse than silently doing nothing — it posts a junk refusal onto every outside contributor's PR, the first thing a new contributor here would see. Not permanent, though: it worked on 2026-05-22 (cosmopolitan033/SAGIN-Framework-RL#8, plain GITHUB_TOKEN + pull_request_target, comment 03:21:10 → real review 03:22:25). Vendor behaviour change, ~10 minutes to retest. The PAT variant works today but costs a 27th unprotected repo-level Actions secret — the exact thing #1032 just spent effort reducing.

Why not switch back to CodeRabbit

Considered seriously, since the volume split was measured after the tool choice. Rejected because the 80% costs quota and ignorable noise, not effort — nothing obliges reading Codex's opinion on a branch already reviewed locally. Against that: a fresh evaluation, a second bot on a public repo, a .coderabbit.yaml, and writing off the ## Code Review Rules work already done in #1029. And the cost premise is shaky — see the open question below.

Actions, in order of value

1. Trigger = "On PR open", never On every push. The single largest real lever: 200 reviews per 90 days instead of 200 × average pushes per PR. It also avoids the unbounded review-then-repair loop documented in #42130 (2026-09-01) when auto-review-on-push meets a Codex fix task.
2. Group the Dependabot updates. .github/dependabot.yml runs four ecosystems weekly with open-pull-requests-limit: 10 and no groups: key (verified — zero occurrences), so all four fan out in the same window. Grouping collapses each ecosystem to one PR, cutting the 12% slice at source and — more importantly — killing the weekly burst. This is the cheapest change available and needs nothing from the vendor.
3. Backfill docs(readme): name every contact in What leaves your device #989 #1010 and feat: add scan and create-custom actions to no-results search state (#578) #995 by hand. Enabling automatic review will not reach them; it is webhook-driven on opened / ready_for_review, and both fired days ago with the feature off. Post @codex review on each. Keep it on one line in exactly that form — anything else after @codex starts a cloud chat instead.
4. Drafts are exempt from automatic review — fixed behaviour, not a setting (5/31 drafts touched vs 484/649 non-drafts, and all five exceptions explained). Opening my own branches as drafts and marking ready at merge shields much of the 80.5% for free. A habit worth having, not a process to build on; Let Codex review draft PRs before they are ready for human review openai/codex#40721 is a live request to change it.

Risks accepted, recorded rather than hidden

• Silent drops. Automatic coverage plateaus around 75% with no error, no comment, no annotation — and since the App holds checks: read, a missing review is invisible to CI too. Roughly one outside PR in four may simply not get reviewed. Glance for the artifact; mention manually if absent.
• Burst starvation. openai/openai-node's Dependabot opens 9–10 PRs in three minutes and about half are dropped. Action 2 fixes the shape here.
• Toggle unreliability. #26911 reports credits drained with Code review disabled; #38110 finds the only reliable kill switch is removing the repo from the App installation. Do not assume an off state is real.
• Coverage auditing is a trap. Codex leaves two artifacts — a formal review, and/or a top-level comment starting <!-- codex-pull-request-review-summary -->. GitHub's reviewed-by: qualifier catches only the first, so any search-derived number is a floor.
• Outside contributors probably cannot self-serve a review on their own PR — the identity gate again. No unattended contributor coverage, but also no stranger-driven quota drain.

What would change this decision

1. Code-review quota confirmed shared with the coding budget and a real limit hit mid-session → move to CodeRabbit's ignore_usernames, not to mention-only, since only CodeRabbit keeps the unattended property while cutting the 80%.
2. Two outside PRs in a row arriving unreviewed under automatic mode → the 75% plateau is biting where it matters, and the tool comparison reopens.
3. The github-actions[bot] refusal reverting on retest → workflow-triggered becomes the best option on the board.

Not a reason to revisit: discovering more absent vendor settings. That question is closed.