How do you use GPT-5-Codex for code review?

A code review is the step where someone other than the author reads a proposed change before it joins the main code. On GitHub, that change arrives as a pull request (PR): a bundle of edits with a description of what they are meant to do. Good reviews catch bugs early, but thorough ones take time, and busy teams often skim.

On September 15, OpenAI released GPT-5-Codex, which is GPT-5 trained further on real software work, and made it the default model for Codex code review. OpenAI says the model doesn't just read the changed lines. It compares the PR's description with the actual changes, looks through the rest of the codebase for code that depends on them, and can run the code and its tests in a sandbox to see what really happens.

Setting it up

Codex comes with the paid ChatGPT plans: Plus, Pro, Business, Edu and Enterprise. Code review runs in the cloud and is set up through Codex on the web, connected to your GitHub account.

1. Connect the repository. In Codex, link your GitHub account and give it access to the repository you want reviewed.
2. Turn on code review for that repository in Codex's settings.
3. Choose how reviews start. Once it is on, Codex reviews a PR automatically when it moves from draft to "ready for review" and posts its findings on the PR. You can also ask for a review at any time by writing a comment that mentions @codex review.
4. Focus the review when it helps. Add a few words after the mention to say what to look for:

@codex review for security vulnerabilities
@codex review for outdated dependencies
@codex review: does this change keep the public API backward compatible?

If Codex suggests changes, you can reply in the same thread and ask it to make them, then review its fix like any other change.

A worked pull request

Suppose a teammate opens a PR titled "Apply member discount at checkout." The description says members get 10% off orders over $50. The key change looks like this:

def order_total(items, is_member):
    subtotal = sum(item.price * item.quantity for item in items)
    if is_member and subtotal > 50:
        subtotal = subtotal * 0.10
    return round(subtotal, 2)

A quick human glance might pass it: the condition is right and the number 0.10 matches the description. A review comment of the kind Codex is designed to produce would point out the real problem. The example below is illustrative, not actual Codex output:

Bug (high): subtotal * 0.10 charges members 10% of the price instead of giving 10% off. The PR description says members get a discount, so this should be subtotal * 0.90. The existing test test_member_total does not cover orders above $50, which is why it still passes. Suggest adding a test for a $60 member order (expected $54.00).

That comment shows what makes an automated review useful: it ties the code to the stated intent, explains why the tests didn't catch it, and proposes a check. OpenAI reports that in its evaluation on commits from popular open-source projects, experienced engineers rated each review comment for correctness and importance, and found GPT-5-Codex's comments less likely to be wrong or trivial. That matters because a reviewer who flags too much trivia gets ignored.

Getting better reviews

Write a real PR description. Codex checks the change against what the PR says it should do. "Fix stuff" gives it nothing to compare; "Members get 10% off orders over $50" gives it a clear target.

Keep instructions in the repository. Codex reads AGENTS.md, a plain text file in your repository for instructions to the agent, and OpenAI says GPT-5-Codex follows those instructions more closely than earlier models. Notes such as how to run the tests or which folders hold generated code help it work like a member of your team.

Keep PRs small. One change per PR makes it easier for both Codex and people to see what matters.

Know the safety model. By default Codex works in an isolated sandbox with network access turned off, which limits what code under review can do and reduces the risk of hidden instructions in the code steering the agent.

What should a human reviewer still check?

OpenAI's own advice is to treat Codex as one more reviewer on the team, never as a substitute for people. Codex is good at tracing logic and running tests; people know things that are not written in the code.

A human reviewer should still check:

• The purpose. Is this the right change at all? Does it solve the problem users actually have, and does it match product decisions made in meetings and documents the agent never saw?
• Design and maintainability. Will the team understand this code in a year? Does it fit the way the system is meant to grow?
• Security in context. Who can reach this code, what data passes through it, and what would an attacker try? An automated review can flag patterns; a person knows which risks matter for this product.
• The review itself. Read Codex's comments critically. A confident comment can still be wrong, and a missing comment does not prove the code is safe.
• The final decision. Approving and merging should remain a person's responsibility, with their name on it.

Used this way, Codex catches more mechanical mistakes before a person looks, and human reviewers spend their attention on the questions only they can answer.