How to Automate Code Reviews with OpenAI Codex CLI

Linters catch style. Tests catch regressions. Neither catches “this retry loop will hammer the API” or “this migration drops a column.” That is the gap OpenAI Codex CLI can fill if you feed it the right input.

Short answer: pipe a git diff into Codex CLI in read-only mode with an explicit review checklist, then run it headless in CI. Reviewing a diff is far cheaper and more reliable than asking it to review a whole repository.

Why review the diff instead of the repo?

A full-repo review pulls in thousands of files and produces comments about code nobody touched. A diff review is scoped, fast, and produces findings the author can act on immediately.

Codex CLI already thinks in diffs because it lives in git. Pointing it at git diff main...HEAD gives it exactly the change set.

How do you run a diff review?

1. Generate the diff: git diff main...HEAD > /tmp/pr.diff.
2. Run Codex in read-only mode so it cannot edit while reviewing.
3. Supply a checklist in the prompt so findings are consistent across runs.
4. Ask for output grouped by severity, not by file.
5. Post the result as a comment on the pull request.

codex --approval-mode suggest \
  "Review this diff. Report only: (1) bugs that would break at runtime, (2) security issues, (3) missing tests. Ignore style. Group by severity." < /tmp/pr.diff

What should the review checklist contain?

Consistency matters more than cleverness. A fixed checklist keeps the agent from writing an essay about naming conventions.

Category	What to ask for
Bugs	Null paths, off-by-one, race conditions
Security	Injection, secrets in code, auth bypass
Tests	Changed logic without a new test
Explicitly ignore	Formatting, naming, comment style

Naming what to ignore is as important as naming what to look for. Without it, agents flood the review with trivia.

How do you run this in CI?

Codex CLI supports non-interactive execution, so it drops into a pipeline step. Set OPENAI_API_KEY as a secret and run it on every pull request after tests pass.

Two practical notes. Cap the diff size — a 5,000-line diff yields shallow comments, so split large PRs. And treat the output as advisory: post it as a comment, never as a required status check, or the agent will block merges with false positives.

Where does AI review fall short?

It is weak on intent. If a change is correct but surprising, the agent may flag it as a bug because it lacks the ticket context. It also cannot judge performance without profiling data — it will guess at complexity rather than measure.

False positives run high on generated code, config files, and migrations. Expect to spend time tuning the checklist in the first two weeks; after that, review noise drops sharply.

This workflow fits teams with real review backlogs and consistent codebases. It is wasted effort on a two-person project where everyone already reads every line.

Quick Summary

• Review the diff, not the repo — smaller input, sharper findings.
• Use read-only mode and an explicit checklist that names what to ignore.
• Group findings by severity so the author can triage quickly.
• Run headless in CI but keep the output advisory, not blocking.
• Expect false positives in the first two weeks while you tune the prompt.