Review Code With Codex CLI

By Rogier Muller06.24.26

Use Codex CLI for code review by giving it a finished diff, asking for risks and tests, running verification, and saving a receipt in the pull request. Treat Codex as a reviewer that produces evidence, not an approver that replaces your team’s judgment.

OpenAI Codex works best in review when the workflow is boring and repeatable. Codex code review is a CLI workflow where Codex inspects a code change, explains likely issues, suggests verification, and leaves a human-readable trail your team can check.

For more Codex CLI workflows, keep this article near CLI workflows and use it as a small team exercise.

Start from a reviewable diff

Start with a real diff, not a broad request like “review my app.” In a production repo, that usually means you have a branch with scoped changes, a passing local build if possible, and a clear pull request goal.

Ask Codex CLI to review the current change set before asking it to edit. A useful prompt is: “Review the staged and unstaged changes for correctness, regressions, missing tests, and security-sensitive behavior. Do not modify files yet. Return findings with file paths and verification steps.”

This matters because a review should be anchored to evidence. Codex can reason across files, but it still needs the same thing a human reviewer needs: what changed, why it changed, and what would prove it works.

Don't turn review into open-ended development. If Codex starts rewriting the patch before it has described the risks, you lose the clean separation between review, fix, and verification.

As of the June 22, 2026 official changelog entry for Codex CLI 0.142.0, I’d use the version update as a workflow checkpoint: re-run your standard review path, confirm your AGENTS.md still applies, and make sure your team receipt is still easy to produce. The changelog is the source of truth for product changes; your review loop is the source of truth for whether your team can trust the output.

Teach Codex the review rules in AGENTS.md

Put durable review rules in AGENTS.md so every Codex review starts with the same expectations. For example, a payments service might tell Codex: “For billing changes, check idempotency, retry behavior, audit logging, migration reversibility, and test coverage for failed payment states.”

Use nested AGENTS.md files when rules are local. A repository-level file can describe language conventions and test commands, while services/billing/AGENTS.md can describe payment invariants and apps/admin/AGENTS.md can describe UI accessibility checks.

This is one of the easiest wins in Codex CLI training because it turns tribal knowledge into review context. Your codex team gets fewer “looks fine” summaries and more reviews that match the way your codebase actually breaks.

Don't write a giant policy document that nobody maintains. Keep AGENTS.md sharp. Prefer five rules the team will enforce over fifty rules Codex and humans both skim.

A team doc titled “how to use codex code review” should include the exact review prompt, the AGENTS.md locations that matter, the verification commands, and the PR receipt template. That is the difference between a nice demo and a workflow a busy engineer will actually use.

Verify before you accept the review

After Codex produces review findings, ask it for the smallest verification loop. In a TypeScript service, that might be pnpm lint, pnpm test -- payment, and pnpm typecheck. In a Python API, it might be ruff check, pytest tests/billing, and a migration dry run.

Then run the commands and keep the output. If Codex says a test should exist, either point it at the existing test or ask it to propose the missing one as a separate edit. If the command fails, the review is not done.

This matters because Codex review is strongest when paired with deterministic checks. The model can spot suspicious logic, but your CI and local tests decide whether the branch is in a shippable state.

Don't accept a polished explanation without command output. A confident review summary is not the same as a verified change.

If your workflow depends on GitHub, Jira, Slack, a database, or internal docs, check the integration boundary before you rely on it. For Codex MCP access, use a small preflight like Check Codex MCP Access so the review does not silently assume context it cannot actually read.

Use MCP and skills as boundaries

MCP is an integration layer that lets tools connect to external systems such as repositories, issue trackers, document stores, and private knowledge bases. In an OpenAI Codex CLI review, MCP should make context easier to fetch, not make approval easier to skip.

Give Codex only the access it needs for the review. Reading a GitHub pull request is different from writing comments. Reading a schema is different from mutating a database. Reading a runbook is different from changing an incident channel.

Skills are useful when your review pattern repeats. A team can package a “backend API review” skill with the right checklist, commands, and examples, then use that skill across services instead of pasting the same instructions into every session.

Watch for over-granting access because it feels convenient. A safer Codex MCP pattern is narrow permissions, explicit prompts, and receipts that say which systems Codex used.

Paste this review receipt into your PR

Use a small receipt so humans can audit the review quickly. Paste it into the pull request description or as a comment after the Codex review is complete.


## Codex review receipt

Change reviewed:
- Branch or PR:
- Main files changed:
- Intended behavior:

Codex review scope:
- Asked Codex CLI to review code changes before editing: yes / no
- AGENTS.md files considered:
  - /
  - services/<area>/
- MCP systems used, if any:
  - GitHub: read / write / not used
  - Jira: read / write / not used
  - Docs or knowledge base: read / write / not used

Findings:
- Blocking issues found:
- Non-blocking issues found:
- Security, privacy, or data concerns:
- Tests Codex expected to exist:

Verification run:
- Lint command and result:
- Test command and result:
- Typecheck/build command and result:
- Manual check, if needed:

Human follow-up:
- Changes made after Codex review:
- Reviewer questions still open:
- Reason this is ready for human review:

Keep the receipt short enough that engineers will use it. The goal is not ceremony. The goal is to make every codex review easy to challenge, reproduce, and improve.

Try this on one pull request

Pick one small PR this week and run the full loop: Codex review, AGENTS.md check, verification commands, and the receipt above. If the receipt feels annoying, fix the workflow before you scale it to the whole team.