Review Codex work without becoming the bottleneck

A Codex review strategy decides how much human attention a change gets before Codex starts, not after. Each task gets a risk class (low, medium, high or critical), and the class sets the permission preset, the evidence Codex must hand back, the automated review it passes, and who signs off. Human code reading goes only to high and critical paths.

This page is for developers who run several Codex threads at once and for tech leads who set the rule for the team. Five threads finish before lunch, each with a multi-file diff. Read them all and you are the bottleneck. Merge them on trust and you hit the other failure. Faros AI’s AI Engineering Report 2026 (April 2026), built on telemetry from 22,000 developers on Faros’s platform, measured median time in review up 441.5% and pull requests merged without any review up 31.3%. The strategy below avoids both. Commands were checked against Codex CLI 0.157.1.

What you’ll walk away with from a risk-based Codex review strategy

• A four-class table that maps every Codex task to a permission preset, required evidence, automated review and sign-off.
• The /permissions presets and CLI flags that limit what Codex can touch before it runs, so there is less to review afterwards.
• An evidence report every thread hands back, so you triage from facts instead of from the diff.
• A queue routine for clearing many finished threads in one sitting.
• Four copy-paste prompts and a path check that catches misclassified changes.

If you have never reviewed a single Codex change, start with reviewing Codex’s changes before you commit. This page assumes that loop and scales it.

How much review does a Codex change need?

The answer depends on what the change can break, not on how large the diff is. Assign the class from the paths a task will touch, before you write the prompt. These are classes of change, not maturity levels; the evidence-based review model explains why a human reads evidence first and code only where evidence is weak.

Risk class	Typical Codex tasks	Permission before the run	Automated review	Human sign-off
Low	Docs, copy, lint fixes, dependency patch bumps, generated clients	Default preset, or --approve-for-me when unattended	codex exec review on a different model, no P0 or P1	You, from the evidence report; the tech lead samples a few each week
Medium	Feature or bug fix inside one module with strong tests	Default preset in a worktree	Same as low	One reviewer reads the evidence report, and code only where evidence is thin
High	Public APIs, shared libraries, cross-module or performance-sensitive changes	Read Only for the plan, then Default in a worktree	Medium, plus @codex review with a focus on the pull request	The code owner through CODEOWNERS
Critical	Authentication, money, schema and data migrations, privacy, and the oracle: tests, CI, lint and type config	Read Only for the plan; implement only after a human approves it	High, plus @codex security review where auth, input or secrets change	Two named humans who read the code, plus a rehearsed rollback

Two rules keep the table honest. A task takes the class of the riskiest path it touches, so a “small refactor” that edits src/auth/ is critical. And any change to tests or CI is critical, because it changes what “green” means for every other change; see protecting the oracle.

For the team version of this table, with review lanes, WIP caps and load balancing across reviewers, see running the review queue when agents open the pull requests.

Set the risk class before Codex starts

Control you apply before the run is cheaper than review after it. A task that cannot write outside its worktree, or cannot write at all during planning, produces a diff with fewer places to look.

The /permissions picker in the Codex CLI 0.157.1 TUI offers three presets. Their descriptions, as the 0.157.1 binary shows them:

Preset	What Codex can do	Use it for
Read Only	“Codex can read files in the current workspace. Approval is required to edit files or access the internet.”	Planning high and critical work; codebase questions
Default	“Codex can read and edit files in the current workspace, and run commands. Approval is required to access the internet or edit other files.”	Implementing low, medium and approved high or critical work
Full Access	“Codex can edit files outside this workspace and access the internet without asking for approval. Exercise caution when using.”	Only inside a disposable, network-restricted sandbox, never on your laptop’s main checkout

From the terminal, the same choices are flags on codex:

# Critical or high: plan in a read-only permission profile (beta in 0.157.1)
codex -c default_permissions=":read-only" "Plan the change described in docs/tasks/refund-idempotency.md"

# Medium and above: implement in a new managed Git worktree, one per thread
codex --worktree "Implement the approved plan in docs/tasks/refund-idempotency.md"

# Low, unattended: route approval requests through automatic review in the workspace-write sandbox
codex --approve-for-me "Fix every oxlint warning in src/components/ without changing behavior"

OpenAI recommends permission profiles for new setups. It also says the profile and legacy --sandbox systems “do not compose”, so pick one mechanism per command. Do not add --sandbox or --approve-for-me to a command that sets default_permissions. The legacy equivalent of the first line is codex --sandbox read-only. The trade-offs between profiles, sandboxes and approval policies across tools are on permissions and sandboxing for agents, and worktree mechanics on Codex worktrees.

Full access removes the boundary your review relies on

--dangerously-bypass-approvals-and-sandbox and the Full Access preset skip every approval prompt. Use them only in a disposable, network-restricted sandbox with no production credentials. A class-based strategy assumes the permission boundary held; without it, the diff is no longer the whole story.

Write the class into the task prompt itself. Codex then knows which paths it may touch and which evidence it owes, and a class mismatch surfaces before any code exists.

Copy-paste prompt: start a task with its risk class

Risk class: medium. Task: add cursor-based pagination to GET /api/orders.
You may edit src/api/orders/ and tests/api/orders/ only. Do not edit anything under
src/auth/, src/billing/, db/migrations/, .github/ or any existing test outside
tests/api/orders/. If the task cannot be done inside those paths, stop and tell me
which path you need and why, and treat the task as high risk from then on.
Before you finish, run the test suite, the type check and the linter, and end with the
evidence report I will ask for.

Make every Codex thread hand back the same evidence

When five threads finish, you triage from five reports, not five diffs. Ask for the same report every time, so a missing line is visible at a glance. The full manifest schema that a pull request should carry is the evidence bundle; the prompt below is the short form for a local thread. So that every thread owes the report without a paste, put the requirement in a section of the project AGENTS.md, or in a project skill under .agents/skills/; see setting up AGENTS.md for Codex.

Copy-paste prompt: the evidence report for this thread

Do not change any code in this turn. Write an evidence report for your change:
1. Risk class you were given, and the class the change actually needs, judged by the
   paths it touches. Say "unchanged" if they match.
2. Every file you changed, with one line on why.
3. The exact commands you ran to verify the change, each with its exit code. Do not
   report a command you did not run.
4. Every test you added, changed, skipped or deleted, with the file and test name.
5. Every changed path under src/auth/, src/billing/, db/migrations/, tests/, .github/
   or any lint, type or CI config file.
6. Behavior the tests do not cover, written as the test that is missing.
End with one line: READY FOR REVIEW, or NOT READY and the reason.

Then check the two lines an agent is most likely to get wrong, without reading any code:

git diff --stat origin/main...HEAD -- tests/     # did the thread touch tests it was not asked to?
git diff --name-only origin/main...HEAD | grep -E \
  '^(src/auth|src/billing|db/migrations|tests|\.github)/|(^|/)(tsconfig[^/]*\.json|\.?oxlintrc[^/]*|eslint[^/]*|vite\.config\.[jt]s)$|\.(test|spec)\.[jt]sx?$'

Run both in the thread’s worktree. The second command prints every critical path the branch changed, including root lint, type and build config and tests that sit next to source files. If it prints anything for a task classed low or medium, reclassify before you read further. Edit the pattern to match your repository’s escalation paths, config files and test globs. The first command sees only a top-level tests/ directory, so rely on the second for co-located tests.

Route each class to the right Codex review

Each class adds a review layer on top of the one below it. Stop at the layer the class requires.

1. Every class: a separate review pass. Run the review as a script so the output lands in a file you can scan:

   codex exec review --base origin/main -c review_model=REVIEW_MODEL -o .codex-review.md

   REVIEW_MODEL is a model ID other than the one that wrote the change, taken from your /model list; the models hub lists the current line-up. A reviewer on the author’s model tends to share its blind spots. The review tags each finding P0 to P3; fix every P0 and P1 before the change moves on. How to tune the rules it cites, and how to measure what it catches, is on code review with Codex.

2. Medium and above: a reviewer reads the evidence report. Open code only where the report is thin: a behavior with no test, a finding that was disputed, a path that surprised you.

3. High and above: review on the pull request. Comment @codex review with a short focus on the risk that made the change high, for example backward compatibility of a public route. Branch protection with “Require review from Code Owners” routes the approval to the owner of the path.

4. Critical: a focused local review, a security pass and two human readers. codex review reads custom instructions from stdin when you pass -, which keeps a long checklist in a file:

   codex review -c review_model=REVIEW_MODEL - < .codex/review-critical.txt

   A scope flag and a custom prompt do not combine in 0.157.1 (codex review --base main "…" fails), so name the scope inside the instructions. codex exec review also accepts -m to pick the model directly. On the pull request, add @codex security review when authentication, input handling or secrets change (OpenAI’s GitHub integration guide, verified 2026-08-28). Two named people then read the code, and the deploy has a rollback someone has run; see deployment automation with Codex.

Copy-paste prompt: critical-path review instructions (.codex/review-critical.txt)

Review the changes on this branch against origin/main. This change is risk class
critical. Report only defects you can tie to a specific line, tagged P0 to P3:
- Authorization: any route or job that reads or writes data without checking the
  caller's tenant and role.
- Money: floating-point arithmetic on amounts, rounding in more than one place, and
  any payment or refund call that is not safe to retry.
- Migrations: statements that cannot run twice, drop or rewrite data the previous
  release still reads, or lock a large table.
- Tests and CI: any assertion removed or loosened, any test skipped, any CI step
  removed or made non-blocking.
Ignore formatting and naming. End with "patch is correct" or "patch is incorrect".

The same layers in GitHub Actions, with the Codex findings gate running in a read-only permission profile, are on running Codex in CI/CD.

Clear a queue of finished Codex threads in one sitting

Reviewing each thread the moment it finishes turns your day into interruptions. Let threads finish, then clear the queue in class order.

1. List what is waiting. codex agents browses every session on the local app-server daemon, and git worktree list shows each thread’s branch. If you work in the desktop app (codex app, macOS and Windows only), see Codex desktop app mastery for its thread view.
2. Collect the evidence reports. A thread without a report goes back with the evidence prompt, before anyone reads anything.
3. Clear low first. A low-class thread with a clean report, no P0 or P1 and no critical paths merges on evidence.
4. Batch medium by module. Two threads that touch the same module get reviewed together, so conflicts show up before the merge, not after.
5. Book time for high and critical. They need owners who are not you; open the pull requests and assign them, rather than holding them in your queue.
6. Stop starting. When more than about one working session’s worth of threads is waiting, start no new ones until the queue drains. Running the review queue when agents open the pull requests turns that into a WIP cap for a team.

Copy-paste prompt: triage the queue from a read-only session

Do not edit any files. Run `git worktree list`. For every worktree except the main
checkout, compare its branch with origin/main and report one row per branch:
branch name, files changed, lines added and removed, whether any changed path is under
src/auth/, src/billing/, db/migrations/, tests/ or .github/, and whether the branch has
an evidence report in its last commit message or in docs/evidence/. Sort the rows by
risk: critical paths first, then branches over 400 changed lines, then the rest.
Flag any branch whose diff touches a path its task prompt did not allow.

Start that session with codex -c default_permissions=":read-only" so the triage itself cannot change a branch. The rules for splitting work into lanes in the first place are on Codex multi-agent workflows.

How do you know the review strategy works without reading every line?

A strategy that lets bugs through looks the same as one that works, until production says otherwise. Track four numbers per risk class, monthly, and let them move classes up or down.

Signal	How to get it	What it tells you	Owner
Escaped defects and reverts per class	Tag incidents and reverts with the class of the change that caused them	A class whose changes escape defects needs a heavier review layer	Tech lead
Reclassification rate	Count threads where the path check or the evidence report moved the class up	High rates mean tasks are being scoped loosely	Tech lead
Seeded-bug catch rate of the Codex reviewer	The seeded-bug check on code review with Codex	Whether the automated layer finds the defects you care about	Owner of the review rules
Time in review per class	Pull request timestamps from your Git host	Whether low-class work is actually flowing, and where the queue forms	Tech lead

A class of change earns a lighter review only after a run of merges with no reverts and no escaped defects, and loses it after one. The trust-transfer protocol describes that staging. The sign-off never moves to Codex: a person or the pipeline you configured owns every merge, and the table at the top of this page names which.

What breaks when you scale Codex review by risk?

A low-class task quietly touches a critical path. The prompt allowed it, or Codex asked for approval and someone clicked yes. Recovery: run the path check above on every branch before review, and make it a required CI job that fails when a critical path changes without the code owner’s approval.

The review finds nothing on a large diff. The scope is wrong: --uncommitted misses commits the thread already made. Recovery: review with --base origin/main for anything that lives on a branch. For the critical-path review, which takes custom instructions, name origin/main inside the instructions file instead, as in step 4 of the routing steps.

The reviewer agrees with the author every time. A same-session review shares the author’s model and context. Recovery: set review_model to a different model and run the review in a fresh process, as in the routing steps; keep the seeded-bug check as the proof.

Tests pass because the thread changed them. Any edit under tests/ makes the change critical, whatever the task was. Recovery: check git diff --stat on test directories first, and put tests and CI config under CODEOWNERS.

--approve-for-me approved more than you expected. Automatic review decides approval requests at the sandbox boundary; it does not review the code. Recovery: keep it for low-class work in the workspace-write sandbox, and use /approve to retry a single denied action rather than widening permissions for the session.

The queue keeps growing. More threads start than you can clear. Recovery: stop starting new threads, cut tasks smaller (small batches are one of the capabilities in the DORA AI Capabilities Model, Google Cloud, 2025-09-23), and move more work into low only through the trust-transfer staging, never by skipping review.

A permission flag errors or has no effect. A profile and --sandbox do not compose, and codex -a accepts only on-request and never in 0.157.1. Recovery: use one mechanism per command, and drop -a from codex exec, which has no such flag and already runs with approval never.

Where to go next with Codex review

Code review with Codex Tune the review rules in AGENTS.md and measure what the reviewer catches.

Review an agent's pull request without reading every line The six-step triage and the escalation classes a human still reads.

Pull request automation with Codex Take a thread from worktree to merged pull request.

Running the review queue when agents open the pull requests WIP caps, review lanes and load balancing for a whole team.

Running another agent as well? The same strategy applies with different controls in review automation with Claude Code and pull request routing and approval in Cursor.