The Codex CLI ships with a code reviewer built in. You type /review, it reads a diff, and it hands back prioritized findings without touching your working tree. That much is in OpenAI’s CLI docs. What the docs don’t tell you is what the reviewer is instructed to do — which turns out to explain most of the behavior people find surprising, starting with the reviews that come back empty.

The CLI is Apache-2.0 and developed in the open, so we read it. Everything below is checked against the openai/codex repository at rust-v0.147.0, released August 7, 2026, plus the official docs.

One disclosure up front: this is a documentation and source read, not a fresh hands-on run. We tested the CLI itself for our Codex CLI review in July; we did not re-run /review against a live repo for this piece, and we don’t print output we didn’t produce.

Key takeaways

• /review offers four targets: uncommitted changes, a base-branch diff, a single commit, or custom instructions.
• The reviewer runs as a separate agent thread with its own model, and it never writes to your files.
• It’s told to flag only bugs the change introduced. Pre-existing bugs in the same file are out of scope on purpose.
• It’s also told to return nothing rather than list findings you wouldn’t act on, so an empty review is a real verdict.
• Web search and image viewing are switched off inside review threads, whatever your global settings say.
• codex review --base main runs the same review non-interactively, which is the CI path.

What does /review do in the Codex CLI?

/review starts a second, read-only Codex agent that reads a diff and reports findings. It doesn’t edit files and it doesn’t commit. It’s spun up as its own thread with its own prompt, so it reads the change the way a reviewer would rather than the way the author does.

The four targets you can point it at:

Target	In a session	What it reads
Uncommitted changes	/review → preset	Staged, unstaged, and untracked files
Base branch	/review → preset	git diff from the merge base with that branch
A commit	/review → preset	The changes that commit introduced
Custom	/review → your own text	Whatever you tell it to look at

The base-branch target is the one worth understanding. Codex resolves the merge base between your branch and the target first, then reviews git diff <merge-base-sha>. You get the changes you would actually merge, not every commit that landed on main while you were working.

What is Codex’s reviewer told to look for?

The review thread runs on a rubric that ships in the repo as prompts/templates/review/rubric.md. It’s the clearest statement of what this tool considers a bug, and it’s public. Eight conditions have to hold before something gets flagged. The ones that change how you use the tool:

• The issue meaningfully affects accuracy, performance, security, or maintainability.
• It’s discrete and actionable — not “this module is a mess.”
• Fixing it doesn’t demand more rigor than the rest of the codebase shows. A repo of one-off scripts doesn’t get graded on input validation.
• The bug was introduced in the change under review. Pre-existing bugs are explicitly not flagged.
• Speculation doesn’t count. To call something a bug, the reviewer has to name the other code it provably breaks.

Findings come back tagged [P0] through [P3], from drop-everything down to nice-to-have, and the review closes with an overall correctness verdict on whether the patch is safe to ship. Style, formatting, typos, and docs are excluded from that verdict by instruction.

Two of those rules explain the complaint you’ll find in every thread about this feature: it didn’t find my bug. If the bug was already in the file before you touched it, the reviewer was told to leave it alone. And on volume, the rubric is blunt — output every finding the author would fix, but if nothing clears that bar, output nothing. A clean review is an answer in itself.

What can’t the Codex reviewer see?

Review threads run with web search and image viewing disabled, regardless of your global configuration. That’s set in the CLI’s own review code path, not something you toggle. So the reviewer won’t look up a CVE, check whether a dependency version is current, or read a screenshot you drop in. It reasons about the diff and the repo in front of it, full stop.

It also can’t fix anything. Findings are text; applying them is your turn, or a follow-up ask in the main session. If you want the review and the fix in one motion, that’s two steps by design — which is the right call, because a reviewer that edits the code it’s grading isn’t a reviewer.

Can you use a heavier model just for reviews?

Yes, and it’s the highest-value knob here. One line in ~/.codex/config.toml:

review_model = "gpt-5.6-sol"

Every review thread then uses that model instead of your session model, so you can run day-to-day work on something fast and cheap and still get a serious model reading your diff before you push. Use whichever slug your plan exposes; /model in a session lists them.

One wrinkle. If the review model doesn’t support the reasoning effort your session is set to, Codex doesn’t error — it picks a supported level for that model and carries on. Handy, but the effort you think you set isn’t always the effort the review ran at.

Your AGENTS.md shapes the review

The rubric tells the reviewer to apply your project’s instruction files to the changed paths, with AGENTS.override.md taking precedence over AGENTS.md, and more specific guidance winning over general. When a finding rests on one of your rules, it’s supposed to cite the file and the lines that back it.

That’s a real reason to keep an AGENTS.md even if you find the file tedious: it’s the only way to teach this reviewer your conventions. It’s also fenced — the rubric says not to invent findings just because a rule file exists, and not to suppress ordinary bugs either.

Running Codex review in CI

The same review runs without the interactive UI, through a top-level subcommand:

codex review --base main
codex review --uncommitted
codex review --commit 9f2c1ab --title "Cache eviction"
codex review "Focus on the SQL, skip test files"

Those four forms are mutually exclusive — pick a target or write a prompt, not both. Under the hood the subcommand runs on Codex’s non-interactive exec path, which is what makes it usable from a pipeline step or a pre-push hook. What comes back is structured, not prose. The rubric pins the reviewer to a JSON schema: every finding carries a title, a Markdown body, a confidence_score, a numeric priority from 0 to 3, and a code_location with an absolute path and a line range. Above the array sit overall_correctness — the literal string "patch is correct" or "patch is incorrect" — plus a one-to-three-sentence explanation and a confidence score. That verdict field is the thing to gate a pipeline on. We haven’t confirmed whether the command itself exits nonzero when findings land, so don’t assume the exit code will fail your build for you.

Compare that to the hosted services in our AI code review tools comparison: those post comments on your PR, this one runs before the PR exists, on your machine, at your plan’s cost.

auto_review is not automatic code review

A naming trap that’s easy to fall into. Codex’s config has auto_review and approvals_reviewer keys, and a codex-auto-review model in models.json. None of the three has anything to do with /review. They govern the guardian, the subagent that decides whether to approve escalated permission requests: sandbox escapes, blocked network access, MCP prompts. Version 0.147.0 added an --approve-for-me flag on that same machinery.

Setting approvals_reviewer = "auto_review" hands your approval prompts to a model. It does not review a line of your code.

Does /review cost extra?

There’s no separate price for /review. It isn’t free either: the review is a full agent turn on its own thread, so it spends whatever a Codex turn spends, meaning plan usage on a ChatGPT subscription or tokens on an API key. Point review_model at a heavier model and reviews get more expensive in exactly the way you’d expect.

Is it worth using?

For the price of one command before you push, yes — with a clear-eyed view of the boundary. The scope rule is the whole story: /review grades the change you made, against the conventions you wrote down, using a rubric you can read. It’s not a codebase audit, it won’t reach the internet, and it can’t tell you the file it’s reading was already broken before you got there.

That makes it a complement to a hosted PR reviewer, not a replacement — and a fair fight with Claude Code, whose equivalent flow is a fresh session on your diff rather than a purpose-built rubric. If you’re already deciding between the two ecosystems, our Claude vs Codex comparison covers the rest of the surface. More developer guides here.

• codex
• openai
• code-review
• cli

Frequently asked questions

How do I run a code review in the Codex CLI?

Type /review inside a Codex session and pick one of four targets: your uncommitted changes, a diff against a base branch, a single commit, or custom instructions you write yourself. Outside a session, the same four targets are flags on the codex review subcommand — codex review --uncommitted, --base main, --commit <sha>, or a plain prompt string.

Why did /review find nothing in my code?

Two rules in Codex's own review rubric explain most empty reviews. The reviewer is told to flag only bugs introduced by the change under review, so a pre-existing bug in a file you edited is out of scope by design. And it's told that if no finding is one a person would definitely want to fix, it should return nothing rather than pad the list. An empty review means the diff looked clean, not that the repo is.

Can I use a different model for /review than for the session?

Yes. Set review_model in ~/.codex/config.toml to any model slug your plan exposes and every review thread uses it instead of your session model. If that model doesn't support the reasoning effort your session is on, Codex picks a supported level for you rather than failing.

Is Codex CLI code review free?

There's no separate charge for /review, but the review runs as its own agent thread, so it consumes the same plan usage or API tokens as any other Codex turn. On a ChatGPT plan it draws down your message limits; on an API key you pay per token at standard rates.