Complete Guide to Codex as a Code Reviewer (2026)

Codex can review code before a pull request exists or join a GitHub pull request as a managed reviewer. The useful distinction is control: local review lets a developer choose the scope and inspect the result privately, while GitHub review adds a shared, repeatable checkpoint to the team workflow.

I use @codex review in the daily CodeWalkers promotion flow as an exact-head second opinion before release. That experience makes the operational questions more valuable than a feature checklist: when to trigger it, what its P0 and P1 filter leaves out, how repository instructions shape the result, and how much permission the reviewer receives.

Codex Review at a Glance

Review Surface	Review Trigger	Available Context	Published Output
GitHub cloud	Pull-request comment	PR and repository	P0/P1 review
Local client	Developer prompt	Working tree	Private findings
codex-action workflow	Workflow event	Configured checkout	Workflow output file

The managed GitHub surface is the distinctive review product. OpenAI controls its review model and priority threshold, then posts findings through GitHub's normal review interface. Local Codex and codex-action offer more freedom, but the team owns the prompt, permissions, event filters, output publishing, and usage controls.

Two Review Surfaces

GitHub Review

Connect Codex cloud to a GitHub repository, then request a review with @codex review or enable automatic reviews in Codex settings. OpenAI's GitHub integration documentation says Codex posts a standard review and focuses its comments on P0 and P1 problems.

This surface suits a shared release checkpoint because the request, findings, replies, and follow-up commit remain attached to the pull request. A developer can verify a comment against the diff, answer with missing context, or start a separate Codex task to address a confirmed problem.

Local Review

Local review works earlier in the change. A developer can ask Codex to inspect uncommitted work, a branch diff, a specific commit, or a narrow set of files before opening the pull request. The prompt can name requirements, threat boundaries, and known invariants without placing those notes in a public review thread.

The local path also supports an iterative loop: review the diff, investigate the finding, change the code, run the repository checks, and ask for a fresh pass. Preserve the original requirement throughout that loop because a model can improve an implementation while drifting away from the requested behavior.

Scope the first pass to the artifact a developer can verify. A staged diff exposes the proposed commit, while a branch comparison shows the complete change against its base. Naming the base and the required behavior prevents unrelated working-tree files from becoming accidental review scope.

Keep review and repair as distinct requests by asking Codex to report findings with file references, impact, and evidence first. After a developer confirms one, a new task can implement the smallest fix and run the relevant checks. That separation preserves the original code long enough to evaluate the diagnosis.

Local output needs a handoff when it affects team approval. Carry the confirmed finding, evidence, and resulting test into the pull request instead of citing an invisible private session. Shared reviewers can then evaluate the same facts without trusting a summary of what the model said.

How GitHub Review Works

The manual trigger is a literal pull-request comment:

@codex review

Keep the trigger on its own line when the repository's bot parser requires a standalone command.

OpenAI also documents automatic reviews for repositories that need consistent coverage. Manual triggering gives a team tighter spend control and a clearer review moment, especially when a pull request receives several small fix commits. Automatic mode is easier to administer after the review has earned a stable place in the workflow.

Codex reads the pull-request change and applicable repository instructions, then publishes only findings that meet its managed threshold. The completed review can return without any published findings. A clean review means the model did not identify a P0 or P1 issue in the available context; tests, human review, and lower-severity engineering checks still have their own jobs.

After a developer confirms the finding and approves a write-enabled task, a follow-up comment can hand the problem back to Codex:

@codex fix the P1 issue

That command starts a separate agent task; it does not turn the reviewer into an invisible auto-fixer. The repository connection must allow the task to write, and the resulting commit needs the same build, test, and exact-head review gates as any other change.

What the P0 and P1 Scope Means

OpenAI's stated priority filter keeps the managed review centered on consequential failures. P0 covers urgent defects that can block release or cause severe harm. P1 covers high-priority defects that deserve attention before merge, including security vulnerabilities, crashes, data loss, and logic errors with a credible production path.

The filter gives the comment stream a strong signal-to-noise advantage. Naming preferences, cosmetic refactors, speculative abstractions, and routine style issues should stay out of the review. Deterministic formatting and type checks belong in CI, where the result is repeatable and cheaper.

The same filter creates a deliberate coverage gap. Duplicated code, unclear boundaries, weak tests, confusing APIs, and accumulating maintenance cost may matter without reaching P1. A human reviewer or a separate architecture-focused pass must examine those dimensions when the pull request warrants them.

Every priority label also requires verification against the actual code. A plausible warning becomes actionable only after a developer confirms the execution path, checks the surrounding contract, and reproduces the risk where practical. Incorrect P1 labels should be dismissed with a reason so the team keeps severity language meaningful.

Add Repository Rules with AGENTS.md

OpenAI's AGENTS.md guide describes a layered instruction system. Codex reads global guidance, then walks from the repository root toward the current file. A deeper AGENTS.md can replace broader instructions for the subtree it owns.

Review rules work best when they describe a costly failure and the accepted safe path. The following pattern was recovered from the longer historical version of this page and tightened around review outcomes:

## Code Review Rules

- Flag authorization checks performed after protected data is read.
- Require idempotency for retryable payment and webhook handlers.
- Treat destructive schema changes without a rollback path as P1.
- Leave formatting, imports, and generated files to CI.

These rules give Codex domain facts that the diff cannot supply. A nested billing service could add currency and retry rules, while an API directory could state compatibility guarantees. Keep the list short enough that each rule remains visible during review.

Rules need maintenance when the architecture changes. Remove obsolete warnings, encode newly discovered failure modes, and test a changed rule against a representative pull request. An instruction file that preserves every historical concern eventually obscures the risks that still matter.

A Trigger Flow from Daily Use

In the CodeWalkers promotion flow, Codex review runs on the exact pull-request head. The sequence matters because a valid fix changes the reviewed artifact, and a green result from the previous SHA cannot describe the new code.

1. Push the completed change and wait for the repository's deterministic checks.
2. Post @codex review as its own trigger comment.
3. Verify each finding against the current diff and project requirements.
4. Apply a confirmed fix as a normal follow-up commit.
5. Run the checks again and request a fresh review on the new head.

The standalone trigger keeps bot parsing predictable. The exact-head rerun prevents an old review from becoming borrowed confidence after the code changes. This discipline costs an additional review, so reserve the loop for findings that alter code; replies that only clarify intent do not need another run.

Verify and Resolve Findings

Start with the execution path Codex describes by opening the cited lines, tracing the relevant caller, and checking guards outside the diff. Compare the behavior with the requirement or repository rule before accepting the severity. A concrete reproduction, failing test, or source-backed contract turns the comment into evidence.

When the finding is correct, prefer the smallest change that removes the failure. Add a regression test where one can reproduce the defect deterministically. Then run the repository's normal checks and inspect the resulting diff before requesting another Codex review.

When the finding is wrong, reply with the missing fact. The explanation helps the human reviewers and can reveal an instruction the repository should encode. Stable exceptions belong in AGENTS.md; one-off context can stay in the pull-request thread.

A review with no findings still needs a recorded outcome. Confirm that Codex ran on the current SHA, inspect any failed or cancelled check, and keep human approval independent. An absent comment should never stand in for proof that the reviewer completed successfully.

Use codex-action for a Custom Pipeline

OpenAI's official Codex GitHub Action documentation says codex-action runs Codex inside a GitHub Actions workflow. It can read a prompt from workflow input, operate in a read-only sandbox, and write its final response to a file for a later step to process.

This route supports event filters and prompts that the managed reviewer does not expose. A workflow could run only when authentication files change, inspect a migration plan, or compare a release diff against a checklist. The action supplies the agent runtime; the repository still owns the review design.

Workflow security starts with the GitHub permissions granted to each job. Give the workflow read access when it only analyzes code, keep untrusted pull-request content away from privileged credentials, and separate result publishing from agent execution. If a later job posts a comment, that job should consume the output through a narrow interface.

Pin the action to a reviewed commit SHA and inspect future updates before changing that pin. An immutable reference protects the workflow from an upstream tag move, while a version comment can record the release that the SHA represents.

Cost and Model Facts

Managed Codex review draws from the shared Codex usage and credit pool on supported ChatGPT plans. OpenAI's rate card prices usage in credits per million input, cached-input, and output tokens by model; the current lineup is the GPT-5.6 family, and the card no longer publishes a separate code-review model line, so budget from the meter after a real review rather than a per-model estimate.

Review Input	Review Model	Billing Unit	Primary Budget Driver
Managed review	Not separately named	Agentic credits	Tokens and context
codex-action	Configured API model	API tokens	Prompt and output

OpenAI released GPT-5.6 Sol, Terra, and Luna on July 9, 2026 across the Codex product, and its rate card now prices that family directly, with GPT-5.3-Codex-Spark listed as a research preview. The review documentation no longer names a dedicated reviewer model, so treat any specific model claim for GitHub review as unverified until OpenAI publishes one.

Actual spend varies with diff size, repository context, cached input, and response length. A useful pilot records credits beside verified findings. That ratio is more informative than estimating one universal price per pull request.

Limits to Plan Around

• Priority coverage: managed review intentionally omits most lower-severity maintainability feedback.
• Available context: external services, production state, and unstated business rules can remain invisible.
• Shared usage: automatic reviews consume the same broader agentic pool used by other eligible Codex work.
• Permission expansion: asking Codex to fix a finding can move the task from read access to branch writes.
• Probabilistic output: a rerun may phrase, prioritize, or discover findings differently.

The strongest control is separation of duties. CI establishes deterministic facts, Codex searches for serious defects, and a developer owns the merge decision. Repository rules improve the search without transferring accountability to the model.

Add Exact-Head Checks to the Hub Pilot

Use the hub's four-week method for the common sample and outcome labels. For Codex, record the reviewed head SHA, credits used, and whether an AGENTS.md rule contributed to each accepted or dismissed finding.

Any code-changing fix invalidates the earlier review result. Run the repository checks, post a fresh standalone trigger on the new head, and keep human approval independent. This exact-head loop is Codex's tool-specific adoption test.

Where Codex Fits: The Verdict

Codex fits a release lane that wants few comments and a high severity threshold. Its value is the exact-head checkpoint: encode costly failures in AGENTS.md, verify every P0 or P1 against the code, and rerun after a fix changes the SHA. Teams seeking broader maintainability feedback should use a different primary reviewer.

FAQ

Does Codex code review use GPT-5.6?

OpenAI no longer names a specific model for the managed GitHub reviewer. Its current pricing pages list the GPT-5.6 family (Sol, Terra, Luna) across Codex, with GPT-5.3-Codex-Spark as a research preview, and review runs draw from the shared Codex usage pool. Check the linked rate card for the current lineup.

What do P0 and P1 mean in a Codex review?

P0 and P1 are the priority levels Codex uses for consequential findings. OpenAI describes this scope as critical or blocking problems such as security flaws, crashes, data loss, and risky logic errors. Lower-priority maintainability and style comments usually fall outside the managed review's stated focus.

Can Codex fix a finding after review?

Codex can start a follow-up cloud task from a pull-request comment, such as @codex fix the P1 issue. The task can modify the branch when the repository connection grants write permission. Review access and branch-write access should remain separate security decisions.

How do AGENTS.md rules apply to a review?

Codex reads AGENTS.md files from the repository root toward the file it is reviewing, with closer instructions overriding broader ones. A root file can state shared review rules while a nested file adds service-specific concerns such as authorization, migration safety, or API compatibility.

Can codex-action run a read-only review?

OpenAI's codex-action can run in a read-only sandbox and write output that later workflow steps publish. Keep the action's GitHub token permissions minimal, pin the action to a reviewed commit SHA, and grant write access only when the workflow must change repository state.

Product, model, and rate-card details were checked against official OpenAI sources on July 28, 2026.