Automated GitHub Code Review

Before any toggles, fix the mental model: Codex code review is the same cloud agent you already delegate tasks to — pointed at a pull request instead of a prompt box.

When you comment @codex review on a PR (or let it run automatically), GitHub hands the diff and PR context to a Codex cloud task. That task reads the changed files, applies your repo's review guidelines, reasons about what could break, and writes back a standard GitHub review — the same kind of review a human teammate posts, with inline comments anchored to specific lines.

Two things make this practical rather than noisy, and they're the heart of the lesson:

• It only speaks up when it matters. In GitHub, Codex flags only P0 and P1 issues — critical and high-priority. Lower-severity nitpicks are suppressed so the review stays signal, not noise.
• It follows your house rules. Codex reads the ## Review guidelines section of the closest AGENTS.md to each changed file, so the review reflects your standards, not generic advice.

Everything else — the enable toggles, focused variants, fix follow-ups, the CI Action — is plumbing around that one idea: a cloud reviewer, scoped to your PR, tuned by your AGENTS.md.

Code review is not a separate product — it rides on the GitHub ↔ Codex cloud connection. So the prerequisite is: Codex cloud must already be set up for the repository (your GitHub account connected, repo access granted). Once that's true, enabling review is two toggles.

Steps:

1. Set up Codex cloud for the repository (connect GitHub, grant repo access).
2. Go to chatgpt.com/codex/settings/code-review.
3. Toggle Code review ON for the target repo.
4. (Optional) Toggle Automatic reviews ON in the same panel.

The two toggles do different jobs:

Think of Code review as the master switch (manual triggering on) and Automatic reviews as the "don't make me ask" upgrade. With Automatic reviews on, you get a review on every PR with no @codex mention needed; with only Code review on, you opt in per PR by commenting.

There are two ways a review fires — you ask, or it runs automatically.

Manual trigger. Comment @codex review on the pull request. Codex acknowledges by reacting to your comment with the 👀 (eyes) emoji, runs the review as a cloud task, then posts a standard GitHub review back on the PR. The eyes emoji is your signal that it's working — if you don't see it, the trigger didn't land (check the repo is enabled and Codex cloud is connected).

Automatic trigger. When Automatic reviews is enabled, you skip the comment entirely: Codex reviews every new PR as it's opened, and again as it moves from draft → ready, posting its analysis with no mention needed.

The review flow in both cases:

  @codex review (or new PR, if automatic)
        │
        ▼
  Codex reacts with 👀  ──►  cloud task reads the diff + PR context
        │
        ▼
  Applies ## Review guidelines from the closest AGENTS.md per file
        │
        ▼
  Posts a standard GitHub review  ──►  inline comments, P0/P1 only

Because the review is a cloud task, it runs in the background in its own sandbox — you don't block your terminal or IDE waiting for it, and several PRs can be reviewed in parallel.

A reviewer that comments on everything gets muted. Codex avoids that by only flagging P0 and P1 issues in GitHub — the critical and high-priority problems — and suppressing lower-severity nitpicks. The goal is a review you actually read, where every comment is worth acting on.

Focusing a review. Sometimes you want Codex to look hard at one dimension. Add the concern to the trigger as a one-off:

• @codex review for security regressions
• @codex review for missing tests
• @codex review for outdated dependencies
• @codex review for risky behavior changes

The focused phrasing steers what Codex prioritizes for that single review without changing your repo's standing guidelines. Use it when a PR touches something sensitive (auth, payments, a dependency bump) and you want the review pointed straight at the risk.

A review that only points at problems is half the value. Codex can also fix what it flagged. After a review posts, comment a fix follow-up and Codex starts a cloud task that edits the code and pushes the fix to the PR branch:

• @codex fix it — fix the flagged problem(s).
• @codex fix the P1 issue — target a specific flagged issue.
• @codex fix the CI failures — start a cloud task to make the build pass.

The key mental split:

That last row is the general rule worth internalizing: review is the only special verb. Any other @codex mention on a PR or issue — @codex add a test for the edge case, @codex explain this regression — spins up an ordinary cloud task that already has the PR's diff and discussion as context. The reviewer and the task-runner are the same agent; you're just choosing what to ask it.

The single highest-leverage lever over review quality is AGENTS.md — Codex's cross-tool instructions file (the analogue of Claude Code's CLAUDE.md). Codex reads it across the repo and pays special attention to a section literally headed ## Review guidelines.

What to know:

• Codex applies the guidance from the closest AGENTS.md to each changed file. A nested packages/api/AGENTS.md governs changes under packages/api/, while the root AGENTS.md governs the rest. Package-level rules "just work" because the closest file wins per file.
• The section is plain Markdown — short, concrete, imperative rules beat long vague essays.

Example root AGENTS.md:

## Review guidelines
- Don't log PII.
- Verify that authentication middleware wraps every route.
- Flag any new dependency that isn't pinned to an exact version.
- Require a test for every new public function.

With those rules in place, a PR that adds an unpinned dependency or an unprotected route gets called out on every review — manual or automatic — without anyone retyping a focus. This is why standing priorities belong in ## Review guidelines, and one-off concerns belong in @codex review for ….

The @codex chat integration is the easy path, but it ties review to GitHub comments and the cloud connection. When you want review (or any Codex step) to run inside your own CI pipeline — gated by your workflow rules, your secrets, your triggers — there's a first-party GitHub Action: openai/codex-action@v1.

What it does: installs the Codex CLI and runs codex exec (the headless, non-interactive Codex) inside a workflow step, so you can post reviews, apply patches, or run repeatable checks as part of CI.

Key inputs include openai-api-key, prompt or prompt-file, model, effort, sandbox (workspace-write / read-only / danger-full-access), and safety-strategy (drop-sudo / unprivileged-user / unsafe). Because the Action runs with your API key on your runner, the security posture is on you:

• Keep safety-strategy: drop-sudo (the default) — use unsafe only where you must (e.g. Windows).
• Restrict who/what can trigger the workflow and sanitize any prompt inputs (untrusted PR text is a prompt-injection vector).
• Pin @v1 (or a commit SHA) so a future release can't silently change behavior.

The two paths aren't mutually exclusive: many teams use @codex review for interactive PR feedback and the Action for a deterministic CI gate.