How to review OpenAI Codex pull requests

Review a Codex pull request in this order: the environment it ran in, the AGENTS.md it was told to obey, the shape of the change, then one path traced end to end. Almost none of that is in the diff. OpenAI's Codex cloud documentation, read in September 2026, describes tasks running in isolated cloud environments you configure per repository, with logs you can watch and a summary and diff you inspect before a pull request exists at all. LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, put AI-assisted pull requests at 408 changed lines at the 75th percentile against 157 without assistance. The diff is the slowest door into a change that size.

What arrives when Codex opens a pull request

Codex work can start from the web, from GitHub, from GitLab, from Linear or from Slack, and each task gets its own environment with its own dependencies, variables and setup steps. You can watch the task logs or let it run in the background. When it finishes, OpenAI's documentation says you "inspect the summary and diff, request a follow-up, or open a pull request when the result is ready."

That last sentence cuts both ways.

Somebody looked at this before you did. A human read a summary and pressed a button, which is more human attention than most agent pull requests get. But what that person saw was the model's account of its own work, and they saw it in the moment when the run had just gone well. By the time it reaches you it has become the pull request description, and it will be the most confident-sounding thing in the thread.

The task summary is the author's account of the change, and the author is the thing under review.

The environment is half the evidence

A Codex environment is a real configuration: base image, setup script, installed dependencies, environment variables, and internet access that you decide to allow or not. Tests that passed passed in there.

So before you read code, answer three questions from the environment configuration rather than from the pull request.

Did the run reach the network? A task with internet access can install a package, hit a real API, or pull a fixture that will not exist in CI. A task without it can produce code whose only proof of life is a mock.

Did the setup script drift from CI? If the environment installs dependencies differently from .github/workflows, a green task and a red pipeline are both telling the truth about different machines. This is the quiet source of "works for Codex, fails in CI" and it is a five-second check.

Which secrets were in scope? A change that reads a new variable is a change to your deployment, whatever the diff says.

None of this takes long. It just has to happen before you form an opinion about the code, because it decides how much the code's own evidence is worth.

Read the AGENTS.md before you read the diff

Codex takes repository guidance from AGENTS.md. OpenAI extended that file into review in 2026 with Code Review rules: you put scoped review guidance in the AGENTS.md nearest the affected code, and Codex applies the rules that matter to a change and cites them in its findings. OpenAI's own post on the feature makes the case that this is most useful when contributors or coding agents are working in a part of the repository whose history they do not know.

For a reviewer, that file is doing two jobs at once. It is the brief the author worked from, and it is the rubric the review bot scores against. If it says "never add a new queue, use the existing job runner" and the pull request adds a queue, you have found the problem in under a minute and you have found it in the right place, which is the instruction rather than the code.

The reverse is more common and more annoying. The change looks wrong, you write a careful comment, and the reply is that AGENTS.md told it to do exactly that. Read the file first and that round trip does not happen.

Codex's review is not your review

As of September 2026, OpenAI's GitHub integration documentation describes three review behaviours: @codex review in a pull request comment, automatic reviews for every opened pull request if you turn them on, and @codex security review as a research preview for deeper security analysis. In GitHub, findings are limited to P0 and P1 issues so the thread stays short.

That limit is a good design decision and it is also the reason you cannot stop there. A change can be free of P0 and P1 defects and still be the wrong change: a second implementation of a helper that already exists two directories away, a new service where a function would do, a path that works and bypasses the rate limiter on the way. GitHub's own guidance on reviewing agent pull requests names code reuse blindness as one of five red flags, and duplication does not look like a bug to a diff reader. It looks like clean new code.

There is also the small structural problem that the same family of models wrote the change and graded it. Reviews from Codex are worth having in the thread. They are not the second opinion the thread needs.

Get the shape of the change before the lines

This is the pass that the summary keeps pretending to give you. The summary says what the run set out to do. What you need is what the change did to the system: which components are new, which were touched, which are gone, and what still calls them.

That is what PR Lens draws. It takes each pull request and posts animated architecture and data-flow diagrams as one comment inside the pull request itself, redrawn on every push. Green is new, amber is changed, red is gone and struck through, and the parts of the system nobody touched stay on the page, so you end up holding a model of the system rather than a patch. The comment nests drill-downs: the whole blast radius on top, then the new path, then what was retired.

Beside a Codex pull request that comment does a specific job. Codex tells you it added batch sending. The diagram shows you that the old per-recipient worker is still wired to the queue, or that it is gone and something else was calling it.

If Codex is the agent you already have open, it can draw the change from the session that made it. npx skills add coldteadotai/pr-lens installs the skill, and then "diagram the change you just made with PR Lens and attach it to the pull request" gets you the picture with the change rather than behind it. The skill reasons with the model the agent already runs, so there is no key to set up. There is also a GitHub App if you would rather every pull request in a repository is drawn without anybody remembering to ask.

The ten minutes, with Codex in the boxes

The clock is the same one from how to review a 400-line pull request in ten minutes. Codex only changes what fills each slot.

The last row is the one that moves. Most agents leave you nothing to check. Codex leaves task logs you can read, and a test run visible in them is real evidence in a way that "verified locally" in a description never is. Spend minute nine there.

Comment where the agent can hear you

OpenAI's documentation says an @codex mention that is not one of the review triggers starts a cloud chat with the pull request as context, and it can push a fix back to the branch when it has permission. @codex fix the P1 issue is a working sentence.

That makes review comments executable, which changes how you should write them. A comment about a line gets you a change to that line. If the real problem is that the change added a component that should not exist, say that, name the component, and name the thing it duplicates. Otherwise you get four small commits and the same architecture.

For the same reason, resist asking Codex to split the pull request into two unless you can name the seam. The shape of the change is where the seam is visible, which is the argument the complete guide to reviewing AI-generated pull requests makes at length.

If the change came from a session you or a teammate still has open, reviewing Claude Code pull requests covers the version of this where you can still interrogate the author. If the pull request arrived with a bot review already sitting in the thread, reviewing GitHub Copilot coding agent pull requests is the same method with that wrinkle worked through.