Codex Code Review: Check a Diff and Verify Each Finding

A Codex review needs a specific diff and a way to verify its findings. On September 20, 2026, we checked the official review documentation and the local CLI help for the commands below. This is a workflow guide, not a measurement of bug-detection accuracy.

Choose the change set

The official review guide documents /review and scopes including a base branch, uncommitted changes, and a selected commit. Choose deliberately: unrelated local edits can change what the reviewer sees.

The local CLI's codex review --help also exposes these non-interactive forms. Check your installed version before running them:

codex review --help
codex review --uncommitted
codex review --base main

The last two commands are alternatives. Use your actual base branch in place of main. The uncommitted scope includes staged, unstaged, and untracked files. A review may send repository context to the configured service; use a project and account authorized for that code.

Do not edit the same files while the review runs. If the head changes, record the new version and review the relevant changes again.

Give the reviewer a failure to look for

Our suggested review request describes behavior and consequences:

Review the selected diff without modifying files.
Focus on whether one signed-in user can change another user's record.
For each finding, give the file and line, triggering request,
expected behavior, actual behavior, and evidence from the code.
Separate confirmed defects from questions requiring more context.

Replace the example boundary with your project's real invariant. “Find every bug” has no observable stopping condition. A focused review is easier to check, but can miss unrelated problems; retain your broader checks and human review.

Request a GitHub PR review

The official GitHub integration guide requires repository setup in Codex cloud and access to review settings. After enabling review for the repository, request it in a PR comment:

@codex review

Automatic reviews can also be configured in Codex settings. Verify that a review actually completed against the intended change; posting a comment alone is not a completed review. Availability and account setup should be checked in the linked official guide.

Turn findings into evidence

For each finding, open the cited code and follow the relevant caller. Construct the smallest request or test that exhibits the claimed behavior. For the ownership example, the check needs two distinct users and a record owned by one of them. A happy-path request by the owner cannot establish that isolation works.

Record one disposition: reproduced, refuted with evidence, or unresolved because context is missing. Ask for missing context before making a speculative fix. Avoid changing code merely because the comment sounds confident.

Once a defect is reproduced, add a check that fails on the old behavior, apply the fix, and rerun it. Preserve the original scenario so the final check exercises the reported problem. The benchmark guide can help keep the input and starting state consistent.

Keep recurring checks near the code

For GitHub reviews, OpenAI documents a Code Review Rules section in the applicable AGENTS.md. See the project instructions guide for an approach to keeping rules testable.

An example rule for a multi-user application could require that every record mutation verifies ownership before writing, with an explicit exception for authorized administrator operations. This is an editorial example: validate it against your own authorization model before adopting it.

Before merging

A review with no findings still leaves questions: did the relevant code enter the scope, did tests execute, and were external dependencies available? Keep a short release record containing the reviewed commit, finding dispositions, check results, and remaining gaps. Repeat the review when new changes invalidate that evidence.