Skip to main content
Lesson 11 of 20 · Codex: AI-Assisted Development

Automated Code Review

Lesson 11 of 20 Updated November 3, 2026 Developer
On this page
  1. Improve Code Quality with AI Reviews
  2. Run a Review on a PR
  3. Target Reviews to a Domain
  4. Automate Reviews in GitHub
  5. Self-Review Before Opening the PR
  6. Set Your Standards in AGENTS.md
  7. Key Takeaways

Updated November 3, 2026 based on the Code Review and Use Codex in GitHub pages in the Codex documentation and CLI help version 0.166.0: reviews trigger via @codex review or automatic review enabled in settings, locally via codex review --uncommitted or /review; the AGENTS.md section is titled ## Code Review Rules. The “Codex: Review Changes” extension command and the codex.openai.com URL have been removed, and the report example is presented as an illustration. Sources: Code review · Use Codex in GitHub.

Improve Code Quality with AI Reviews

In most teams, code review has become the bottleneck in the delivery pipeline: pull requests pile up because skilled reviewers are busy writing code themselves. Codex doesn’t replace human reviewers; it handles the first pass—catching obvious oversights, deviations from the existing architecture, and untested edge cases. When a developer finally opens the PR, they no longer need to flag missing error-path tests; they can focus their attention on decisions that require business judgment.

Run a Review on a PR

On GitHub, the most direct approach is to mention Codex in a pull request comment: @codex review. Codex reacts (👀), then posts its review in the PR. In the desktop app, the Code Review module displays the PR description, changed files, comments, and checks, letting you query Codex about the change. In both cases, report quality depends on request precision: name the areas to cover.

"Review PR #142. Check:
- Consistency with existing architecture
- Potential security issues
- Test coverage
- TypeScript code quality
- Unhandled edge cases"

Codex analyzes the diff, but it also reads the context of modified files—not just the changed lines—then delivers a structured report. Here’s an example of the kind of report you might expect for a PR adding notifications:

## Review PR #142 — Notification System Addition

### Security
⚠️ src/api/routes/notifications.ts:34
  The userId parameter comes from the request body without 
  validation. A user could send notifications on behalf of 
  another. Use req.user.id from the authentication middleware.

### Architecture
✅ The service follows the same pattern as other services
⚠️ The notification.service.ts file is already 200 lines.
  Consider separating channels (email, webhook) into 
  distinct files.

### Tests
❌ No test for when the email service is 
   unavailable (timeout/network error)
⚠️ Tests mock the DB but not the email service

### Code quality
💡 The sendBatch function could use Promise.allSettled 
   instead of Promise.all to avoid failing if one 
   notification out of 50 fails.

Pay attention to the nature of the comments rather than their formatting. The userId vulnerability is exactly what a rushed reviewer misses on a Friday evening: the code compiles, tests pass, yet any user can write on behalf of another. The Promise.allSettled suggestion reflects an understanding of expected behavior—a batch send shouldn’t fail because one address out of fifty bounces—not mechanical application of a style rule.

Target Reviews to a Domain

General reviews dilute attention across five topics at once. When preparing a sensitive production release, request a specialized pass on a narrow scope instead. For security, the prompt looks like this:

"Security review on files modified in 
src/api/ over the last 5 commits. Look for:
- SQL injections
- Potential XSS  
- Missing authentication
- Exposed sensitive data
- Unchecked permissions"

Codex knows common vulnerability patterns and can spot them in your code, even when hidden behind a custom abstraction layer. The same principle applies to performance, except you’re hunting for very different symptoms—not a flaw, but a query running a hundred times where one would suffice:

"Analyze performance of src/services/report.service.ts.
Identify:
- N+1 database queries
- Loops that could be parallelized
- Loaded but unused data
- Calculations that could be cached"

Automate Reviews in GitHub

Once the practice is established in the team, make it systematic rather than dependent on individual memory. Codex documentation describes the setup as follows:

  1. Connect your GitHub repository to Codex (you need push or admin rights on its settings).
  2. Open the code review settings.
  3. Select the repository, then enable Automatic review under Review code.

Everyone can also enable automatic review for their own PRs in their personal preferences and choose when it triggers (Review trigger), without having to type @codex review. This cloud review doesn’t require creating a Codex Cloud environment. Comments appear directly in the GitHub PR, in the same place as human reviewer comments—a detail that drives adoption: a remark that forces people to open another tool won’t get read. GitLab merge request review also exists, in preview.

Self-Review Before Opening the PR

The best time to fix a problem is before anyone else sees it. From the IDE or CLI, a self-review on uncommitted changes takes seconds and saves you a full review round-trip:

# From CLI, non-interactive: review uncommitted changes
codex review --uncommitted

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

In an interactive session, the /review command does the same thing on your working tree; in the desktop app, Code Review also offers to review local changes.

Try it on your next branch before pushing: you’ll find that half the comments you usually get from colleagues are already addressed, and the review conversation starts at a more interesting level.

Set Your Standards in AGENTS.md

A review only has value if it applies your team’s criteria, not those of some imaginary project. Codex looks for AGENTS.md files in the repository and follows their review rules: add a ## Code Review Rules section to the file closest to the relevant code, with ### subheadings to group checks.

## Code Review Rules

### API
- Every API route must verify authentication
- User data must be validated with Zod
- No TypeScript any (use unknown + type guard)
- Errors must be logged with context
- Functions > 50 lines must be broken down
- TODO comments must have an associated ticket

Codex applies these standards to every review, with a consistency no human reviewer maintains across three hundred consecutive pull requests.

Key Takeaways

  • Codex performs a first pass review to filter obvious issues
  • Reviews can be specialized: security, performance, architecture
  • GitHub integration enables automatic reviews on every PR
  • Use review before creating the PR to save time
  • Document your standards in AGENTS.md for consistent reviews