The post half — scoped review, plus the job the diff cannot do

Two jobs, and the second matters more:

1. findings — defects inside the paths you name. Each carries a defect_class: the general shape it is an instance of, stated independently of the file it was found in, so you can sweep every sibling surface at once instead of meeting the same shape again next pass.
2. unreached_consumers — surfaces outside those paths that consume what changed and did not move. Codex derives these from the repository's consumer map (CONSUMERS.md, if present — see the map skill) and by grepping the identifiers the change introduced — never from the diff, because the diff cannot contain what its author forgot. Treat this list as the real output.

Steps

1. Run it, scoped. Name exactly the paths this change touched:

   "${CLAUDE_PLUGIN_ROOT}/scripts/codex-failsafe.sh" post <path> [<path>...]
   "${CLAUDE_PLUGIN_ROOT}/scripts/codex-failsafe.sh" post --staged
   "${CLAUDE_PLUGIN_ROOT}/scripts/codex-failsafe.sh" post --since main

   Scope is not optional. The worktree may hold unrelated uncommitted work; an unscoped review attributes it to this change and makes every finding unresolvable.

   The returned reviewed_paths echoes the scope back, and the runner compares that echo against the scope it resolved and exits 3 on any mismatch. Displaying the echo is not enough: an empty or substituted array satisfies the schema and prints without complaint, so the run that reviewed nothing and the run that found nothing are the same two lines on a terminal — and a reader who has just seen a clean findings list is the least likely person to check. On exit 3, adjudicate nothing from the run; the raw file is still written, because evidence of a scope violation is worth keeping.

2. Read unreached_consumers first. Each entry names the consumer, what it consumes, and a command whose output would show it is already consistent. Run that command. Either the consumer moves in this change, or the entry is refuted with the command's output — nothing in between.
3. Adjudicate every finding per reference/adjudication.md: confirmed / refuted (with evidence) / governed / out-of-scope / open. "I disagree" is not a disposition.
4. Write the ledger entry beside the raw claims file (same stamp, .json instead of .codex.json) — the task, the scope, each claim with its disposition and evidence. The raw *.codex.json is evidence and is never rewritten.
5. Then commit. A confirmed claim routes as: fix, plus extend the test or check that should have caught it, plus sweep its defect_class across every sibling surface before the next pass.

How many passes, and when to stop

The post half is cheap enough to repeat, and that is the trap. Run repeatedly against a tree you keep editing, it measures when you stopped changing things rather than when the work became sound — and a rule phrased as "consecutive clean passes" is then counting your own edits, not the reviewer's agreement. Clean is also weak evidence on its own: a run can go clean twice in the middle and produce its deepest finding several passes later.

1. Stop after one clean pass over a tree you have not edited since. A fix owes exactly one more pass — the fix is the new target, and one clean read of it is the whole of what another pass buys.
2. A claim you have already adjudicated does not make a pass unclean. An open item re-derived on five consecutive passes is one gap with five independent derivations behind it, which is evidence rather than five findings. Record the count in the ledger and let the pass count as clean.
3. Budget six passes per target. Blowing it is a finding about the scope, not about the change: two targets are interleaved, or one is too large to review as a unit. Say which in the ledger, and stop.

Reviewing the code the review asked for

A confirmed finding often routes to "extend the test or check", so that code is written during the review — and it is then reviewed as though it were part of the original change. It is not. It is a second target, with its own defect density, and a review can spend half its findings on code that did not exist when it began.

Three habits cost most of that, and all are the author's rather than the tool's:

• Growing a check arm by arm. Each comparison added under review pressure is fresh surface, and the next pass finds a defect in it. Settle the whole scope in one decision — the pre half's consumers list usually already names it — then write it once, then review it once.
• Not aiming a pass at it. An unscoped pass over deliverable-plus-new-check reasons from the deliverable, because that is where the argument is, and it re-derives the same claim while the new code sits unread. Run one pass scoped to the new code alone. The second target needs its own pass, not a share of one.
• Letting the reviewer find instance two. A second model reporting the second occurrence of a shape you already fixed costs a full cycle and teaches nothing the first occurrence did not. That is what defect_class is for.

When each half runs

Nothing fires either half automatically; running the post half is a step inside committing, decided each time. (An optional fail-open pre-commit hook ships in optional/hooks/ for those who want the mechanical reminder — read its header for why it is not the default.)