Codex Code Review Plugin: How to Review Pull Requests in Codex

Code Review is a Codex plugin, shipped September 29, 2026 on supported desktop and web surfaces, that opens a GitHub pull request's summary, diff, comments and checks inside Codex and lets you run a private Codex review before you post anything. The verdict: it is a reviewer's cockpit, not a review bot. Use it when a human still owns the approval, and pair it with @codex review or automatic cloud reviews when you want Codex to post comments on its own.

Last updated: October 17, 2026

What shipped on September 29#

OpenAI's ChatGPT release notes list "Review pull requests with Codex" under September 29, 2026:

Use Code Review in Codex to read pull-request summaries and diffs, review findings, and discuss changes. Open a pull request, inspect the changes, and ask Codex to explain a section or help address a potential issue before sharing feedback.

The same entry says it is "available through the Code Review plugin on supported desktop and web experiences" and that "access to a repository follows your connected account and workspace permissions." The note does not list plan tiers, so check what your own workspace exposes rather than assuming it matches another Codex feature.

The Code Review docs fill in the rest:

• The plugin shows a pull request's description, changed files, comments and checks.
• GitHub code review is generally available. GitLab merge request support in Code Review is in preview.
• The desktop app includes Code Review, and you can pin it to the app sidebar from your installed plugins.

It landed on the same day as Codex Cloud, Codex Security Cloud and interactive plugin extensions (plugins that can include panels, sidebar views and viewers or editors), which explains why it looks like a full panel rather than a chat command. If you have not used the unified desktop app yet, ChatGPT Work and the Codex desktop app covers where plugins live.

Three Codex review surfaces, and which one this is#

Codex now reviews code in three different places, and they are easy to confuse. The Code Review plugin is only one of them.

The important distinction is between the second and third rows. The docs say automatic cloud reviews "are separate from reviews you start in the pull request's chat." A cloud review posts comments for everyone to see. A plugin review stays in your chat until you choose to share something.

%% title: Two ways Codex reviews a pull request
flowchart TD
  PR[GitHub pull request] --> A{Who starts it?}
  A -->|You, in the app| B[Code Review plugin]
  A -->|Repo setting or @codex review| C[Cloud review]
  B --> D[Review with Codex chat]
  D --> E[Findings stay private]
  E --> F[You choose what to post]
  C --> G[P0 and P1 comments on GitHub]
  G --> H[Also visible in Code Review]

Why this matters: Codex's cloud review and Copilot code review both work as bots you add to a PR. They post, you triage. That works for catching obvious problems, but it shifts work onto the PR author and can add noise to a thread. The plugin flips the order. The reviewer investigates first, with Codex as a research assistant, and only verified concerns reach the author.

How to review a PR in the Code Review plugin#

These steps follow the Code Review docs. They apply to the desktop app and supported web experiences.

1. Open Code Review from the sidebar. If you do not see it, pin it from your installed plugins.
2. Connect your source account when prompted. Use an account that has access to the repository you want to review. Repository access follows that account and your workspace permissions.
3. Pick a pull request. Use the personal inbox: Assigned to me for reviews requested from you, Assigned to my team for team requests, or Authored by me to return to your own changes. You can also paste a PR link into the search field. Select the pin in a PR's toolbar to keep it under Pinned in the sidebar.
4. Read Summary. It holds the description, activity, comments and checks. When Code Review finds a stack of open dependent pull requests, a Stack section appears so you can jump to the related PRs. When Threads appears, it links to your earlier chats about this PR.
5. Open Changes. Inspect changed files and existing comments alongside the diff. Select Mark as viewed on each file as you finish it. Viewed markers apply to the displayed revision, so re-check them after a new push.
6. Start a review. Select Review with Codex to start a review in a new chat. If you already have a chat open beside the PR, ask about the change there instead.
7. Inspect findings. Select a finding to see its explanation and the relevant lines in Changes. Check it against the latest diff, the expected behavior and the tests before deciding it needs a fix. You can stop a running review from the review chat.
8. Ask for evidence. Do not take a finding on trust. Ask Codex to show the code path and the tests.
9. Draft the comment in chat. Ask Codex to write it up, then check the file and line references yourself.
10. Submit review. Choose Comment, Approve or Request changes, check the decision and text, and send it to the source provider.

The docs give a concrete example. A PR adds Open and Closed filters to an issue board, and you expect All to remain the default with an empty state when nothing matches. The walk-through prompt from the docs:

Walk me through this pull request. Focus on the default filter and what
happens when there are no matching issues. All should remain the default.

Then the evidence prompt:

Show me the code path and tests for the no-matches case. Explain what is
covered and what still needs verification.

Both prompts work because they state the expected behavior up front. "Review this PR" asks Codex to guess what matters. "All should remain the default" gives it a claim to verify. The docs also suggest using installed skills and connected sources to bring in your team's review guidelines or design documents, then asking Codex to summarize the change and explain the risks.

Once you have verified a concern, the docs' drafting prompt keeps the comment out of GitHub until you are ready:

Using the team review guidelines we discussed, draft a comment describing
the no-matches behavior we verified, what should happen instead, and the test
that would cover it. Keep the comment as a draft.

%% title: Reviewing a PR in the Code Review plugin
sequenceDiagram
  participant You
  participant Plugin as Code Review
  participant GH as GitHub
  participant Codex
  You->>Plugin: Open PR from inbox
  Plugin->>GH: Fetch summary, diff, checks
  You->>Codex: Review with Codex
  Codex-->>You: Findings linked to lines
  You->>Codex: Ask for evidence
  Codex-->>You: Code path and tests
  You->>Codex: Draft a comment
  You->>Plugin: Submit review
  Plugin->>GH: Comment, Approve or Request changes

If you are the PR author rather than the reviewer, the flow runs the other way: open your PR, ask Codex to address specific feedback, inspect the resulting changes and run the relevant tests. Before approving or merging, the docs recommend checking the latest revision, checks and outstanding feedback.

Customize the review#

There are two places to put review guidance, and they serve different people.

Personal review instructions. Select the Review instructions gear next to Review with Codex, or go to Settings > Code Review. These instructions apply to every review you start with Review with Codex, across repositories. If you edit them while a review is running, the change applies to your next review. The docs' sample:

Start with a short summary. Prioritize behavior changes, data loss, and
missing edge-case tests. For each finding, explain the triggering input,
expected behavior, and actual behavior. Use our team's concise review style.

There are also optional presets - Comic book, Visualization and PDF - that add a suggested instruction for explaining the change in that format. You edit the text, then select Save or Run review. For questions about one specific change, the docs recommend the PR chat instead of permanent instructions.

Repository review rules. Cloud reviews (@codex review and automatic reviews) follow ## Code Review Rules sections in AGENTS.md, per the GitHub integration docs. Codex applies the root file plus any more specific nested file that covers each changed file, so a rule in services/experiment_reporting/AGENTS.md only applies to changes under that path. The docs' example:

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

The docs recommend starting with two or three concise rules that encode checks reviewers often explain, stating the safe path or exception, preferring outcomes over function names that can change, and leaving formatting and lint to CI.

The practical split: plugin instructions are yours and follow you across repositories. AGENTS.md rules are the team's and travel with the code. If a rule matters for every reviewer, put it in AGENTS.md. If it is how you personally like findings formatted, put it in Review instructions.

Fix failing checks from the PR#

The plugin also handles a common reason a PR stalls: red CI. In Codex, select Fix in Checks on an open pull request. That attaches the failing checks to the chat as a prepared message, without sending it. Add your own prompt, send it, then inspect the resulting changes and rerun the relevant tests before pushing.

Available diagnostics depend on the check provider. For third-party CI, Codex can use the status and output reported to GitHub, so a CI system that reports only a pass/fail status gives Codex less to work with than one that posts full logs.

%% title: Fixing failing checks from Code Review
flowchart TD
  A[Open PR in Code Review] --> B[Checks shows a failure]
  B --> C[Select Fix]
  C --> D[Failing checks attached as unsent draft]
  D --> E[Add your prompt and send]
  E --> F[Codex investigates and proposes changes]
  F --> G[Inspect diff and rerun tests]
  G --> H{Tests pass?}
  H -->|Yes| I[Push the fix]
  H -->|No| E

On GitHub itself there is a separate path: after a cloud review, a comment like @codex fix the P1 issue starts a legacy cloud chat with the PR as context, and Codex can push a fix back to the branch when it has permission. That is a bot workflow; Fix in Checks keeps you in the loop before anything is pushed.

Local reviews and config#

The plugin works on pull requests. For changes that are not in a PR yet, Codex's built-in /review command reviews your Git checkout. It appears only when the open project is inside a Git repository, and it reports prioritized findings without changing your working tree.

The /review scopes in the CLI are:

• Review against a base branch - finds the merge base and reviews your branch diff.
• Review uncommitted changes - staged, unstaged and untracked files.
• Review a commit - the exact change set for a selected commit.
• Custom review instructions - focuses the review on criteria you provide.

The app and IDE extension offer the first two.

For scripts, the Codex CLI has a non-interactive codex review subcommand ("Run a code review non-interactively" in the openai/codex source). The scope flags are mutually exclusive, per the ReviewArgs definition in codex-rs/exec/src/cli.rs:

# Staged, unstaged, and untracked changes
codex review --uncommitted

# Your branch against a base branch
codex review --base main

# One commit, with an optional title for the summary
codex review --commit <sha> --title "Add issue board filters"

# Custom instructions (use - to read them from stdin)
codex review "Focus on the database migration and rollback path"

--title requires --commit, and --worktree is rejected for code review. For CI-driven reviews with codex exec and the GitHub Action, see the headless Codex guide.

To make reviews use a different model from your session, set review_model at the top level of config.toml. The source documents it as "Model used specifically for review sessions":

review_model = "<model-id>"

Use a model ID from your own model picker; the docs do not prescribe one. Delivery is configurable too. In the app, Settings > General > Code review > Detached starts a separate review chat instead of running the review in the current one. In the IDE extension, chatgpt.reviewDelivery defaults to inline and can be set to detached.

%% title: Picking the right Codex review surface
flowchart LR
  A{What are you reviewing?} -->|Local changes| B["/review or codex review"]
  A -->|Open PR, you own approval| C[Code Review plugin]
  A -->|Every PR, hands off| D[Automatic review]
  A -->|One PR, bot pass| E["@codex review"]
  B --> F[Findings stay local]
  C --> G[You post what you verified]
  D --> H[P0 and P1 comments on GitHub]
  E --> H

Gotchas and limits#

• Posting in Summary or Changes is immediate. A comment posted there goes to the source provider right away, without waiting for Submit review. Keep drafts in chat until you are ready.
• Chat reviews never act on their own. Reviewing a PR in chat does not post comments, approve or merge. That is the point, but it also means nothing happens until you act.
• Cloud findings and chat findings are separate. An automatic review's comments show in Code Review, but they are not the same run as a Review with Codex chat. Do not assume one replaces the other.
• Cloud reviews only flag P0 and P1 on GitHub. The GitHub integration docs say Codex "flags only P0 and P1 issues" there. If you want lower-priority observations, the private plugin chat is where to ask for them.
• GitLab is preview. GitHub code review is GA; GitLab merge request support in Code Review is in preview. For cloud reviews on GitLab, the docs point to the separate GitLab integration, which we cover in how to use Codex with GitLab.
• PR descriptions with images. Editing a PR description with attached images is not supported in Code Review. Edit those on GitHub.
• /review needs a Git repository. The command does not appear outside one, and the app's review pane will prompt you to create one.
• Fixes follow your sandbox. If you ask Codex to apply fixes, your normal sandbox and approval settings apply.
• Check every reference. The docs repeatedly tell you to check file and line references in drafts and to verify findings against the latest diff and tests.
• Rules are guidance, not gates. Per the docs, code review rules "don't replace tests, branch protections, or required approvals."

The last two points are the recurring theme. The model can find a lot, but someone still has to confirm it, which is why human verification is the real bottleneck in AI code review. The plugin's design leans into that rather than hiding it.

Code Review in Codex vs GitHub Copilot code review#

The closest alternative is GitHub Copilot code review. They overlap less than the names suggest: Copilot is a reviewer you add to the PR, and the Code Review plugin is a workspace for the human reviewer. Codex's own bot path (@codex review, automatic reviews) is the more direct Copilot equivalent.

What Copilot does well, on its documented capabilities: it lives wherever PRs already live, across more editors and surfaces than Codex covers. It has a request API with a per-request effort level, published per-review cost estimates, and Balanced has been the default effort level since September 28, 2026 per the October 2 changelog. Reading instructions and skills from the head branch means you can test a rule change in the same PR. Our Copilot effort levels breakdown covers Lite vs Balanced and the API in detail.

What the Codex plugin does well: it keeps the reviewer in control of what the author sees, lets you interrogate a finding before it becomes a comment, and puts Stack navigation, check fixing and your personal review style in one panel. The same tool also covers local /review and scripted codex review, so the reviewer workflow and the pre-PR workflow share configuration.

A reasonable split for a team already on both: let a bot (Copilot or @codex review) do the first automated pass on every PR, and use the Code Review plugin when a human reviewer needs to understand a change well enough to approve it. For the wider field of review tools, see the best AI code review tools in 2026.

FAQ#

Does the Code Review plugin post comments automatically?#

No. Reviewing a pull request in chat does not post comments, approve or merge. Two things do send to GitHub: posting a comment directly in Summary or Changes (which is immediate), and Submit review, where you choose Comment, Approve or Request changes. Automatic cloud reviews are a separate feature that does post comments.

Does it work with GitLab?#

Partly. GitHub code review is generally available, and GitLab merge request support in Code Review is in preview. To trigger cloud reviews from GitLab with @codex review or automatic merge request reviews, the docs point to the separate GitLab integration.

What is the difference between /review and the Code Review plugin?#

/review reviews changes in your local Git checkout - a base branch diff, uncommitted changes, a commit, or custom instructions in the CLI. The Code Review plugin works with open pull requests and their description, comments and checks. Use /review before you open a PR and the plugin after.

Can I use a different model for reviews?#

For /review and codex review, yes: set review_model at the top level of config.toml. The release note and Code Review docs do not document a separate model picker for the plugin's Review with Codex runs, so do not assume review_model changes those.

How do I make Codex follow my team's review rules?#

Use Review instructions (the gear next to Review with Codex, or Settings > Code Review) for your personal plugin reviews. For repository-triggered cloud reviews, add a ## Code Review Rules section to AGENTS.md, with root rules for the whole repo and nested files for specific services.

Sources#

• ChatGPT release notes - Review pull requests with Codex (September 29, 2026)
• Code review - ChatGPT Learn
• Review GitHub pull requests with Codex - ChatGPT Learn
• Developer settings - ChatGPT Learn
• openai/codex - codex-rs/exec/src/cli.rs (ReviewArgs)
• openai/codex - codex-rs/cli/src/main.rs (review subcommand)
• openai/codex - codex-rs/core/src/config/mod.rs (review_model)
• GitHub Copilot code review - GitHub Docs
• Copilot code review API support and new default effort level - GitHub Changelog

Continue Reading#

• GitHub Copilot Code Review Effort Levels Are GA: Lite vs Balanced - the Copilot side: effort levels, the request API and billing.
• Codex Exec in CI: Practical Guide to Headless OpenAI Agents - run Codex reviews without a human in the loop.
• ChatGPT Work and Codex Now Share One Desktop App: What Actually Changed - where Code Review lives in the unified desktop app.