Review in Codex is a separate role, not a polite request to praise the diff. A good review looks for real behavioral risk: what will break, which branches are uncovered, where public behavior changed, rather than restating what is already visible in the changes. Locally the review is started with the /review command inside the session or a separate non-interactive codex review. The difference between "restate the diff" and "find what can break here" is the difference between decoration and a real check.
The key distinction of roles is who writes and who checks. It helps to separate the model that wrote the code from the model reviewing it: a review by a separate role tasked with finding risk gives more than asking the same agent to judge its own work. But even here it matters not to fall into false confidence: a review by the same model finds omissions, yet shares the same blind spots with the author, so it does not replace a test, a static analyzer and the person responsible for the merge.
Prioritizing findings matters more than their number. A long list of remarks where a critical vulnerability sits next to a stylistic nitpick does not help make a decision. A good review ranks: first what changes behavior or opens risk, then what is worth fixing, and only at the end cosmetics. The review's task is not to rack up more remarks but to show what really needs attention before the merge, and not to drown it in the noise of trifles.
It helps to see how the review is started in two forms once. Below is the interactive /review inside the session and a separate codex review --uncommitted for a non-interactive run. The exact set of flags is always checked via codex review --help: the CLI reference supports reviewing uncommitted changes, a diff against a base branch, a specific commit and a review with custom instructions. The form is chosen for the task, not run the same way always.
The non-interactive codex review is handy where the review is embedded in a process. Reviewing uncommitted changes suits a check before a commit; a diff against a base branch - a check of a whole branch before a PR; reviewing a specific commit - a pointed analysis. Custom instructions let you focus the review on what matters to this project specifically - for example, on payment security or API compatibility, rather than on a general "look at the code".
False confidence is the main trap of review, and it is worth remembering separately. A green review from the model is not independent evidence of correctness: it is useful as another layer of attention but not as a final stamp. The evidence remains a passed test and observation of real behavior, not the agent agreeing with itself. The person responsible for the merge does not go anywhere - the review helps them but does not take the decision off them.
The review is built into the same evidence cycle as all the work. A review's findings are hypotheses about risk that are checked the same way as any claim: by a test that reproduces the problem, a static check, observation of behavior. A review that found a potential race is valuable not by itself but by setting a direction for verification. Taking a review's remark on faith is as wrong as taking "fixed" from the author on faith.
The typical review failures are predictable. Asking for a restatement of the diff instead of a search for behavioral risk. Getting a long unranked list where the important drowns in cosmetics. Taking a green review from the same model for independent evidence and passing the merge without a test and a person. And running one form of review always without choosing for the task. Start the review as a separate role, rank the findings, check them with evidence and keep a human at the merge - the review strengthens attention but does not replace verification.
# Interactively, inside the session
/review
# A separate non-interactive review
codex review --uncommitted # uncommitted changes
# also: a diff against a base branch, a specific commit, custom instructions
codex review --help # the exact set of flags