Complete Guide to Codex as a Code Reviewer (2026)

Codex can review local code, GitHub pull requests and GitLab merge requests. GitLab’s native integration is in beta. 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 run @codex review in our release process as a second opinion on the latest code before release. I care about when to trigger it, what its P0 and P1 filter leaves out, how repository instructions shape the result and how much permission it receives.

For alternatives with different review coverage, see our AI code review recommendations.

Codex Review at a Glance

Surface	Trigger	Context	Output
Desktop Code Review view	Open the review view	PR or merge request	Your review, submitted
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 review is the distinctive review product. OpenAI controls its review model and priority threshold, then posts findings through GitHub's normal review interface.

The ChatGPT desktop app’s Code Review view provides summaries and diffs, and lets developers ask questions about a change. From that view a developer submits the review as Comment, Approve, or Request changes, and GitLab merge request support is in preview.

Local Codex and codex-action offer more freedom, but the team owns the prompt, permissions, event filters, output publishing, and usage controls.

Where Can Codex Review Your Code?

Codex can review GitHub pull requests and GitLab merge requests, inspect local changes or run inside a custom GitHub Actions workflow. The desktop review view also helps you examine and submit a review yourself. These routes have different permissions and usage limits.

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 flags P0 and P1 problems by default. Manual review can also request P2 findings. Automatic cloud reviews no longer require a cloud environment, and @codex security review requests a security-focused pass.

This mode 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.

The native GitLab integration supports GitLab.com and configured self-managed or Dedicated instances in beta. Manual GitLab reviews include P0, P1 and P2 findings by default; automatic reviews focus on P0 and P1. Do not assume GitHub’s default threshold applies to every Codex review mode.

Local Review

Local review works earlier in the change. In the CLI, /review or the non-interactive codex review inspects uncommitted work, a branch diff, or a specific commit without changing the working tree. OpenAI's pricing page says these local reviews count toward general Codex limits, while Code Review usage covers GitHub runs. The prompt can name requirements, threat boundaries, and known invariants without placing those notes in a public review thread.

Locally, you can review the diff, investigate a 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 behaviour.

Start with a specific diff that a developer can check. A staged diff exposes the proposed commit, while a branch comparison shows the complete change against its base. Name the base branch and expected behaviour so the review stays on the intended changes.

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 lets you check whether the reported bug exists before Codex changes the code.

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 Do You Request a Codex Review on GitHub?

Request a Codex GitHub review by commenting @codex review on a pull request in a connected repository with code review enabled:

@codex review

You can add a specific focus, such as @codex review for issues in the database migration.

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. The repository connection must allow the task to write, and the resulting commit needs the same build, test, and review checks on the updated code as any other change.

What Do P0 and P1 Mean in a Codex Review?

In a Codex review, P0 means an urgent blocker and P1 means a high-priority defect that should be fixed promptly. Managed GitHub review reports these two levels by default, including security vulnerabilities, crashes, data loss and logic errors with a credible production path. Manual reviews can also request lower-priority P2 findings.

The filter is intended to keep comments focused on serious defects; it does not guarantee every finding is correct. 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. Ask a human reviewer to check those design and maintenance concerns when they matter to the change.

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

Codex GitHub review follows applicable AGENTS.md guidance from the repository root and more-specific files covering the changed code. Put shared review rules at the root and service-specific rules near the service they govern.

Review rules work best when they describe a costly failure and the accepted safe path. A short rules block looks like this:

## Code Review Rules

- Flag authorisation 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 our release process, Codex review runs on the exact pull-request head. A fix changes the code. An earlier review does not cover those new edits.

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.

Request another review when a fix materially changes the code or introduces a new risk. A comment explaining existing behaviour does not need a fresh paid 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 behaviour with the requirement or repository rule before accepting the severity. Reproduce the problem, find a failing test or show which documented requirement the code breaks.

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 runs Codex, but your team decides what it checks and how to use the result.

Workflow security starts with the GitHub permissions granted to each job. Give the workflow read access when it only analyses 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.

How Much Does Codex Code Review Cost?

Codex code review uses the allowance or credits available on your supported ChatGPT plan; it does not have one universal price per pull request. GitHub review usage and local review usage are accounted for differently. Local reviews count towards general Codex usage, while a custom API-based workflow incurs API charges.

Record the usage shown after a representative review. Diff size, retrieved context, review frequency and your account terms affect the total. Automatic review can consume an allowance quickly on a busy repository.

What Are the Limits of Codex Code Review?

Codex GitHub review focuses on serious defects and can miss lower-priority design problems, unavailable context or bugs it fails to recognise. A clean review is useful feedback, not a guarantee.

• 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 applicable review allowance or credits under your account terms.
• Write access: asking Codex to fix a finding can move the task from read access to branch writes.
• Variable findings: a rerun may phrase, prioritise, or discover findings differently.

Give each check a clear job. CI runs repeatable tests, Codex looks for serious defects, and a developer decides whether to merge. Repository rules improve the search without transferring accountability to the model.

Test Codex on Your Own Pull Requests

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.

Earlier findings can remain valid after a fix, but the review does not cover newly introduced changes. Re-run the relevant checks and request another review when the remaining risk warrants it.

My Verdict

Codex fits a release workflow that wants few comments and a high severity threshold. I 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 will need an additional review process.

Frequently Asked Questions

Which model does Codex code review use?

OpenAI does not name a dedicated model for the managed GitHub reviewer in its review documentation. Models available for ordinary Codex tasks do not establish which model handles a managed review.

Can Codex fix a finding after review?

Codex can start a separate cloud task to fix a review finding when you request it in a pull-request comment, such as @codex fix the P1 issue. The task can change the branch only when it has the necessary write access. Check the resulting patch before merging.

Can codex-action run a read-only review?

OpenAI’s codex-action can run Codex in a read-only sandbox and write its result for a later workflow step to publish. The workflow still needs appropriately limited GitHub permissions, and any step that publishes comments needs its own permissions.