Codex CLI auto-review and what it catches

Run it before the human does

Codex CLI auto-review works best as a pre-push step, not a replacement for a reviewer. The pattern we teach: finish your branch, ask Codex to review the diff against the base branch, fix what it flags, then open the pull request. Your teammate's time goes to design questions instead of a missing null check.

Point it at a diff rather than the whole repository. A prompt like "review the changes between this branch and main, focus on error handling and anything that touches the payments module" produces sharper output than "review my code". Scope is the single biggest lever on quality here.

What Codex CLI auto-review reliably finds

• Unhandled error paths, especially around IO and network calls that were pasted from a happy-path example.
• Off-by-one and boundary conditions in loops and slicing.
• Inconsistency with the surrounding file: a new function that ignores the module's existing logging or config pattern.
• Dead branches and variables left behind by an earlier iteration of the same change.
• Obvious injection and unescaped-input problems in code it can see end to end.

That last qualifier is doing a lot of work. The model reviews what is in context. A SQL string built safely in the file under review can still be unsafe because of a caller three modules away that never entered the window.

What it walks past

Three failure modes come up in almost every session we run.

First, intent. The review checks whether the code is internally coherent, not whether it does what the ticket asked. A function can be flawless and still solve the wrong problem. No automated reviewer will tell you that.

Second, cross-file invariants. If your codebase has an unwritten rule that every handler must call audit.record(), the reviewer will not know unless you say so. Put that rule in AGENTS.md. Written-down conventions get enforced; folklore does not.

Third, agreeableness. Ask "is this correct?" and you will often get reassurance. Ask "find the three most likely ways this breaks in production" and you get a real list. Adversarial framing changes the output more than any flag.

There is also volume. On a large diff the reviewer produces a long list where nine items are style and one is a genuine data-loss bug, ranked in no particular order. Reviewing in chunks of a few hundred lines keeps the signal readable.

Wiring it into a team

Make the review step a habit rather than a rule. We have watched mandatory-review policies die within a month because they added friction with no visible payoff. What sticks is a short shared prompt, checked into the repository, that everyone runs the same way. When someone finds a phrasing that surfaces better bugs, they update the file and the whole team gets it.

Keep the human review gate. Auto-review lowers the noise in a pull request. It does not carry accountability, and it cannot be asked why it approved something six months later.

What to do next

Take your last merged pull request, one you already know had a defect, and run the review against that diff. If it catches the bug, write down the prompt you used. If it misses, work out whether the missing information was context or convention, then fix the corresponding file.

If you want help putting this into practice, talk to us.