Codex Code Review: How to Let AI Review PRs Without Letting It Rewrite Everything

An 800-line PR lands with the title fix and a description that says only “fixed some issues.” You are staring at the diff, unsure where the real risk is, and you do not want to read every changed file line by line. Someone leaves a PR comment: @codex review for auth bypass and PII logging. A few minutes later, an inline comment points at logger.info(user.email).

Now you have to decide whether Codex should fix it, whether you should change it yourself, or whether someone on the product or compliance side needs to confirm the logging policy first. This guide walks through the trigger conditions, Review guidelines, P0/P1 meaning, triage flow, and human confirmation boundary.

@codex review Is Not a Magic Spell

@codex review is not a switch that lets AI rewrite the PR. It asks Codex to read the PR diff and publish review comments according to your rules. Whether it triggers, what it checks, and how you respond to the results still depend on setup and human judgment.

GitHub Cloud Triggers and Settings

To use Codex for code review, the repository needs Codex Cloud set up, and you need access to the code review settings. There are two trigger paths: write @codex review in a PR comment, or enable Automatic reviews in settings so Codex publishes a review when a new PR is opened for review.

After it triggers, Codex reads the PR diff, follows the repository guidance, usually the Review guidelines in AGENTS.md, and posts inline comments as a standard GitHub code review. @codex review is not an approval, and Automatic reviews are not automatic approval. Sensitive changes such as auth, payment, or data migration still need human confirmation.

You can combine PR triggers and CI workflows with branch protection rules so AI review is only one check in the process. For PR trigger setup, see the earlier guide on GitHub Actions PR triggers.

Focus on P0/P1, Not a Running Commentary

By default, Codex marks only P0/P1 priority issues. P0 is for blocking problems such as security regressions, auth bypass, or data loss. P1 is for issues that need fixing, such as performance problems, concurrency bugs, or logging sensitive data.

Alibaba Cloud - Top choice for developers, exclusive 15% off for Lighthouse servers

Get 15% Discount →Ad

That focus keeps review comments from exploding, preserves signal, and reduces low-value noise. You can override the default in the Review guidelines section of AGENTS.md. For example, ask Codex to focus on auth bypass, PII logging, and concurrency, while leaving code style to Prettier and minor performance concerns to humans unless they sit on a hot path. The next section shows how to write those guidelines.

Put Review Guidelines in AGENTS.md, Not in Every PR Comment

Review guidelines determine what Codex review should focus on and how it should prioritize findings. They belong in the repository’s AGENTS.md file, not repeated in every PR comment.

AGENTS.md Layering and Review Guidelines

Codex reads AGENTS.md before it starts work. It scans from the Git root down toward the current working directory, and the closer file is more specific. For example, an AGENTS.md file under auth/ can override project-wide rules and focus only on auth-related risks.

A typical Review guidelines section looks like this:

## Review guidelines

Focus only on these risks:
1. Security regressions(auth bypass、path traversal)
2. PII logging(user.email、phone number)
3. Concurrency issues(race condition、deadlock)

Do not focus on:
- Code style(automated by Prettier)
- Minor performance(non-hot paths)

This pattern gives every PR the same baseline rules, avoids repeated comments, and still lets AGENTS.md files near changed files be more specific.

One caveat: instruction files are limited by project_doc_max_bytes, which defaults to 32 KiB. Files that are too long may be truncated. A full AGENTS.md setup, including Project rules, Review guidelines, and Coding style, belongs in another Codex practice guide. This article stays focused on the structure and priority controls for Review guidelines.

Use the Codex App Review Pane to Inspect the Diff Before Deciding

The Codex app review pane does not only show suggested AI changes. It reflects the Git repository state. By default it focuses on uncommitted changes, and you can switch to all branch changes or last turn changes.

Inline Comments and PR Context

Inline comments in the review pane attach directly to diff lines. You can use that exact feedback to decide whether Codex should fix the issue, whether you should edit it yourself, or whether the finding is a false positive. After you run /review, the result appears as inline comments in the review pane.

If Codex has GitHub access and the current project is on a PR branch, the app can show PR context: reviewer feedback, changed files, and the PR description. This depends on GitHub CLI being installed and authenticated with gh auth login. Without it, PR details may not appear and you may only see the local diff.

Control the Granularity: Stage or Revert by File or Hunk

The review pane supports staging, unstaging, and reverting at the entire diff, file, or hunk level. Do not revert an entire commit the moment you see a finding, especially when the change spans several files. Hunk-level handling lets you keep safe changes and roll back only the risky part.

After a Review Finding, Check the Diff, CI, and Tests Before Asking @codex fix

When Codex finds a P0/P1 issue, do not immediately hand everything to @codex fix. First decide whether the finding is real, whether the proposed fix is reasonable, and whether the change touches a sensitive boundary that needs team confirmation.

Railway - Modern deployment platform, zero-config, go live in minutes

Start Now →Ad

Review Findings Triage Table

An Executable Flow for Handling Findings

Confirm whether the finding is real: inspect the diff line referenced by the inline comment and verify that the problem exists.

Decide the fix boundary: auth, payment, and data migration are sensitive changes and need human confirmation. Style and minor performance findings can often be ignored or left to the toolchain.

Choose a handling path:

• Ask Codex to fix it: comment @codex fix the P1 issue; Codex starts a cloud task from the PR context
• Fix it yourself: edit the code manually, run local tests, and push
• Ask for tests: open a follow-up issue or explain the missing coverage in a comment
• Mark a false positive: explain why in the comment so the same issue does not come back repeatedly

Inspect the diff and CI: even if @codex fix can push back to the PR branch, you still need to inspect the diff, CI result, and test coverage. A Codex fix is not an automatic merge, a CI pass, or a human reviewer approval.

Confirm sensitive changes with humans: auth bypass, payment flow, and data migration touch safety boundaries. A team reviewer still needs to sign off. Do not skip that step.

What Not to Do

• Do not auto push or auto merge: @codex fix asks AI to change code; it is not merge permission
• Do not skip CI: even after Codex fixes something, CI still needs to run and prove the change did not break other tests
• Do not ignore human reviewer feedback: AI review is a second check, not a replacement for the team reviewer
• Do not give Codex oversized permissions: main branch push, force push, and write access to sensitive directories should stay restricted

The security boundary for sensitive changes, permissions, and secrets belongs in a later Codex practice guide. For CI workflow basics, see the earlier GitHub Actions CI pipeline guide.

Let AI Draft Commit Messages and PR Descriptions, but Do Not Invent a Format

@codex generate commit message or @codex generate PR description can ask Codex to draft text from the diff and PR context. Review the output before using it, and do not commit it blindly. Commit messages should follow Conventional Commits instead of a format invented on the spot.

Conventional Commits and a Commit Message Template

The Conventional Commits format is <type>[optional scope]: <description>. Common types include fix for a PATCH version, feat for a MINOR version, and a BREAKING CHANGE footer or ! marker for a breaking change.

Example:

Vultr - High-performance NVMe VPS with 32 global locations, one-click Docker deploy

View Pricing →Ad

fix(auth): prevent bypass in login flow

- Add session validation before auth redirect
- Reject expired tokens within 5 minutes

Refs: #123

Conventional Commits are widely used because tooling such as semantic-release, auto-changelog, and commitlint can use the format to generate changelogs and infer version bumps. Inventing your own format breaks that automation and raises collaboration costs.

PR Description Template

A PR description should cover at least five parts:

1. Background: why the change exists, such as user feedback, a performance problem, or a security risk
2. Change scope: which modules are affected, such as auth, payment, or logging
3. Testing: verified scenarios, such as local tests, CI coverage, or manual checks
4. Risk: known boundary conditions, such as concurrent traffic or high-volume behavior
5. Rollback: how to roll back quickly, such as reverting a commit, disabling a feature flag, or changing config

After Codex generates the description, check whether all five parts are complete, whether the wording is accurate, and whether risk or rollback details are missing. Do not commit generated text directly, especially when the change touches a sensitive boundary.

For commit message and PR description generation, you can give a specific instruction in the PR comment, such as @codex generate commit message following Conventional Commits, so the AI follows the standard format.

Summary

Codex review is a second high-signal check, not merge permission. @codex review asks the AI to read the diff and publish inline comments. Automatic reviews only automate the trigger step; they are not approval or merge.

Core flow:

1. Put 1 or 2 focused risks in AGENTS.md Review guidelines, such as auth bypass, PII logging, or concurrency. Do not try to cover everything
2. P0/P1 is the default focus so review comments do not explode. P0 must be fixed; P1 needs a handling decision
3. After a finding appears, inspect the diff line referenced by the inline comment and confirm whether the issue is real. Sensitive changes such as auth, payment, or data migration require human confirmation
4. After @codex fix, still inspect the diff, CI result, test coverage, and human review. Do not auto push or merge, skip CI, or ignore team reviewer feedback
5. Use Conventional Commits for commit messages. Do not invent a format; tooling depends on the standard to generate changelogs and infer version bumps

Action plan:

• Add AGENTS.md to your repository and write a short Review guidelines section focused on 1 or 2 risks
• Try @codex review on the next PR and check whether the inline comments match your rules
• For sensitive changes, read the later Codex practice guides on permissions, secrets, and failure review before deciding whether to use @codex fix

Related Reading

• GitHub Actions PR triggers: configure PR triggers and branch protection rules
• GitHub Actions CI pipeline best practices: CI checks and human reviewer responsibilities
• AI coding assistant comparison: Claude Code vs Cursor vs Copilot: choosing AI coding tools