Use Codex Subagents to Review Code in a Small Team

You have a large pull request and only two people available to review it. Codex Subagents can split the reading into independent threads: one looks for correctness risks, one checks tests, and one compares the change with documentation. In about 30 to 45 minutes, you can have a list of findings with locations and evidence for your team lead to verify. You need a Git repository, access to Codex, and a change with a clear review scope.

This is a way to run several research threads, not an instruction to have three agents edit the same file. OpenAI's Subagents guide recommends starting with read heavy work such as code exploration, testing, triage, and summaries. Each subagent uses its own resources, so a parallel review can consume more tokens than a single session.

Prepare

Open the repository in the Codex desktop app, CLI, or IDE extension. Current documentation says these surfaces support subagent workflows, although their thread views differ. If the terminal is new to you, start with the Codex CLI guide to reading, editing, and verifying an unfamiliar repository.

Decide which branch to review, which test command to trust, and which documentation applies. Run git status and record any uncommitted changes before delegating.

The team needs shared rules for reporting bugs and severity. You can keep them in AGENTS.md; see how to align a team's working rules in Codex. Ask for concrete evidence rather than accepting “this looks dangerous” as a finding. If you need the basics, this introduction to AI agents explains how they differ from chatbots.

Step by step

1. Separate questions that can be answered independently

For a pull request that changes sign in and notifications, do not tell three subagents to “review everything and fix it.” Give them three questions that do not depend on one another:

1. Correctness and security: Does sign in skip an access check, expose data, or mishandle an error?
2. Tests and regression: Which cases are covered or missing? Would the current tests actually catch the suspected bug?
3. Documentation and external behavior: Does the change match the API, framework documentation, and expected user behavior?

Give each thread the same report format: finding, file and line, evidence, impact, and uncertainty. Each thread only reads. The main agent waits for all results and combines them. A small change may need only one Codex session.

2. Delegate in parallel with a precise request

In a Codex desktop or IDE chat, or an interactive CLI session, send a direct request. Replace the square brackets with your project details:

Use three Codex subagents to review [branch or pull request] against [base branch].
Agent 1 should examine only correctness, access control, and bugs that could affect users.
Agent 2 should examine only test gaps and regression risks. It may read or run existing tests, but must not edit files.
Agent 3 should compare the changed code only with the official documentation for [framework or API]. If the documentation is unavailable, state that limitation.
The agents must not edit code, commit, push a branch, or write results to the same file.
Every finding must include a file path, location, evidence, and a way to check it again. If no bug is found, say what was checked and what remains open.
Wait for all three agents, merge duplicate findings, rank them by impact, and suggest changes only after verification.

OpenAI gives a similar pull request example, with separate agents for security, test gaps, and maintainability. In the CLI, /agent lets you inspect and switch between agent threads. In the desktop app and IDE, you can open each subagent thread from the interface. If a finding could change a release decision, read its thread rather than trusting only the main thread's conclusion.

3. Respect permission and resource boundaries

A subagent inherits the main session's sandbox policy. Creating another thread does not grant permissions the main session lacks. Check the chosen permission mode and available tools before delegating. If a thread only needs to read, say “do not edit” in the request; a custom agent can also be configured as read only.

Some actions require approval. In an interactive CLI session, an approval request from another thread may appear while you are viewing the main thread. Check its thread label before deciding. In a noninteractive flow, an action needing fresh approval can fail, and the error returns to the main workflow. Do not broaden permissions merely to make parallel work run smoothly.

Each subagent uses resources. Splitting work too finely can increase cost. Unless configured otherwise, a child inherits the parent's model and reasoning effort.

4. Treat the results as a draft audit

When all threads finish, ask the main agent to merge duplicates and flag contradictions. One agent might say there is no test for an expired session while another finds one in a different directory. Do not choose whichever conclusion sounds more certain. Open the test, read what it asserts, rerun it if needed, and record the result.

You can ask for a synthesis:

Combine the findings from the three subagents for [pull request].
For each finding, include impact, file and line, evidence from code or tests, the result of checking it again, and who must decide.
Mark an inference as “unverified.” Remove duplicate findings.
Do not edit code yet. End with three manual checks to complete before approval.

Open high impact code yourself, rerun the relevant tests, and inspect the diff. The guide to a verified Codex Cloud pull request shows how to compare a result before handing it to a reviewer. The team retains the decision to approve.

5. Assign edits only after verification

Choose a verified finding. Assign an owner, a test that demonstrates the bug, and a limited set of files to change. If Codex makes the fix, keep that step separate from the review. Give one person or thread ownership of each code area. Several threads editing the same working tree can conflict or make tests read changing state.

After the fix, run tests, inspect git diff, and ask another person to review sensitive code. If a test is unstable, report that the finding remains unverified.

Example result

Suppose a fictional pull request adds notifications for sign ins from a new device. The three subagents report:

This is an illustration, not a guaranteed Codex result. The useful output is a reproduced issue, an evidenced test gap, and a decision the team still needs to make.

Tips for better results

Assign questions, not vague job titles. “Be a security expert” does not say what to inspect. State the scope, output, and how to report missing information.

Use one finding template. File, line, evidence, reproduction, impact, and uncertainty make results easier to combine. For repeated reviews, put the template in team instructions and improve it based on real mistakes.

Allow “nothing found.” A subagent need not invent an issue to justify its role. Ask it to name what it inspected and what access limits remained.

Measure usefulness. Track valid findings, false alarms, and verification time. If results do not improve, change how the work is divided.

Limitations

Three agent reviews do not equal three independent people accountable for the result. Agents can share a wrong assumption or rely on weak tests. A human reviewer must verify findings that affect security, data, or user behavior. Test results can differ across environments and fixtures.

The OpenAI Subagents documentation distinguishes ChatGPT Work's hosted environment from local Codex. This article is about Codex working in a repository. Do not apply Claude Code commands or configuration to Codex.

Do not send private source code, secrets, or customer data to an external source without team approval. If the research thread cannot reach current documentation, report “source not checked” rather than guessing about the API.

FAQ

Do subagents automatically appear when I open Codex? Current Codex releases support subagent workflows, but how they start depends on the surface and applicable instructions. Ask for parallel delegation directly; do not assume Codex will always split the work itself.

How many subagents should I use for one pull request? Match the number of genuinely independent questions. For a small team, two or three reading threads are often easier to manage than a thread per file. Measure results and actual cost.

Does a child agent get more permissions than the main session? No. It inherits the main sandbox policy, and its tools and actions remain subject to relevant limits. Check the permission mode before delegating.

Can three agents edit code at once to go faster? Some independent write tasks can run in parallel, but conflicts become more likely. In this review workflow, let them read and report evidence. Assign edits after verification, with clear file ownership.

What if the three conclusions conflict? Do not pick one immediately. Open the relevant code and tests, compare official documentation, reproduce the case where possible, and record remaining uncertainty for the reviewer.

Main sources: Subagents, Code review, and AGENTS.md, OpenAI Learn. Checked October 5, 2026. #Codex #Subagents #CodeReview #VibeCoding