Aident AI

How to Use Codex Inside Claude Code for Code Review
Install OpenAI's official codex-plugin-cc marketplace in Claude Code, run /codex:setup, then use /codex:review --base main --background to have Codex review your branch without changing files. Use /codex:adversarial-review when you need a second model to challenge a risky design decision, not just inspect implementation details.
That is the shortest useful answer. The rest of this guide shows the complete setup, a repeatable review loop, the expected result, and the failure modes that matter before you make the workflow part of every pull request.
What the Official Codex Plugin Does
OpenAI's plugin calls the local Codex CLI and app server from inside Claude Code. It uses the same repository checkout, Codex authentication, and Codex configuration that you use on the machine already.
The review commands are deliberately read-only:
Command | Use it for | Changes files? |
|---|---|---|
| Reviewing uncommitted work or a branch diff | No |
| Challenging architecture, risk, and assumptions | No |
| Delegating an investigation or a fix | Can |
| Monitoring and retrieving background work | No |
The distinction matters. A review should produce evidence for a human or the implementing agent to verify. A rescue task is a work handoff and needs the same change review, tests, and permission boundaries as any other coding-agent task.
Prerequisites
You need:
Claude Code with plugin support;
Node.js 18.18 or later;
a ChatGPT subscription, including Free, or an OpenAI API key;
a Git repository with a focused diff to review;
the project's tests and static checks available locally.
Codex usage from the plugin counts toward your normal Codex limits. The official plugin also has an optional automatic review gate, but start with manual reviews. OpenAI warns that an unattended gate can create a long Claude and Codex loop and consume limits quickly.
Step 1: Install the Codex Plugin in Claude Code
Run these slash commands inside Claude Code:
Expected result: /codex:setup reports that Codex is installed and authenticated. Claude Code should list the Codex commands, and /agents should show the codex:codex-rescue subagent.
If setup says Codex is not authenticated, run this inside Claude Code and complete the login flow:
Do not paste API keys into a chat, repository file, shell history, or review prompt. Use the supported login flow or an existing securely managed environment.
Step 2: Define a Small Review Boundary
Before asking another model to review the code, confirm what is actually in scope:
Remove generated output, unrelated formatting, and accidental files. Then run the project's targeted tests. A reviewer is more useful when it sees one coherent change and knows which behavior is already covered.
For uncommitted work, the default command is enough:
For a feature branch, make the comparison explicit:
OpenAI recommends background mode for larger multi-file reviews. Check and retrieve the result with:
Expected result: Codex returns prioritized findings about the selected diff, or reports that it found no actionable issues. The review command does not edit the working tree.
Step 3: Use Adversarial Review for High-Risk Decisions
The normal review command does not accept custom focus text. Use the adversarial command when the important question is whether the approach is safe or sound:
Good targets include:
authentication and authorization changes;
database migrations and backfills;
retry, caching, and concurrency designs;
deletion or overwrite paths;
billing, secrets, and external side effects.
Avoid a vague request such as "be strict." Name the invariant that must hold and the failure modes that would make the change unsafe.
Step 4: Verify Findings Before Fixing Them
A second model is another reviewer, not an oracle. For each finding, require four pieces of evidence:
The file and line where the suspected problem begins.
A reachable code path to the failure or sensitive operation.
The missing check, invariant, or test.
A targeted reproduction that fails before the fix.
Ask Claude Code to inspect each finding against the repository before editing:
This step prevents plausible but irrelevant review comments from growing the diff. It also creates a clear record of which findings were confirmed, rejected, or deferred.
Step 5: Run One Bounded Review Loop
A practical loop is:
Claude Code implements a focused change.
The project's tests and checks pass.
Codex reviews the diff once.
Claude verifies the findings and fixes confirmed issues.
Tests run again.
A final Codex review checks only the updated diff.
Stop after the final clean pass or escalate unresolved tradeoffs to a human reviewer. Do not keep two models arguing until one gives up. More turns can increase cost without improving evidence.
Track three numbers for the first five reviews: findings reported, findings confirmed, and confirmed defects fixed before merge. That gives you a measurable signal about whether this review step is useful for your codebase.
Common Setup and Review Failures
/codex:setup Cannot Find Codex
Confirm the Codex CLI is visible in the environment that launched Claude Code:
If the command is missing, rerun /codex:setup and follow its installation prompt. If Codex works in one terminal but not Claude Code, restart Claude Code from a shell where the Codex binary is on PATH, then reload the plugin.
Codex Is Installed but Not Logged In
Run:
The plugin reuses local Codex authentication. It does not create a separate plugin account.
The Review Looks at the Wrong Changes
Use /codex:review for current uncommitted work. Use /codex:review --base main when the review should compare the whole branch to main. Check the diff yourself before starting so the target is not ambiguous.
A Large Review Appears to Hang
Prefer --background, then use /codex:status and /codex:result. Keep the diff narrow. As of July 23, 2026, the plugin's public issue tracker also contains open reports about foreground timeouts and stale background jobs. Check the current issue before assuming a local configuration problem, and cancel work that no longer has a useful boundary.
The Automatic Review Gate Burns Usage
Disable the gate and return to manual, bounded reviews:
Use the gate only for a monitored, high-risk change with a narrow target and a clear stop condition.
The Review Produces Too Many False Positives
Reduce the diff, state the system invariants, and require a reproduction for every proposed fix. Do not ask the normal review command for custom focus text because it does not accept it. Use /codex:adversarial-review for a steerable question.
Give Both Agents the Same Tool Boundary
Cross-model review is less useful if one agent can inspect the repository but cannot verify the external systems the change touches. Aident Loadout gives Claude Code and Codex a shared, scoped way to discover and run connected Actions without copying provider credentials into prompts.
Ask your coding agent:
Then connect only the systems required for the change, such as GitHub, an issue tracker, or observability. Keep read-only review Actions separate from write-capable implementation Actions, and require approval before external side effects.
For a deeper explanation of the tradeoff between local and remote tool access, read Local vs Remote MCP Servers. If your agent starts loading too many tools into every turn, use the techniques in How to Reduce MCP Token Usage in Claude Code and Codex.
Why This Workflow Works
The useful separation is not that one model is always better. It is that the reviewer starts from a different model and review objective. Claude Code keeps ownership of the implementation context; Codex gets a bounded diff and looks for defects or weak decisions; the tests decide whether the resulting change behaves correctly.
That separation only helps when the loop stays evidence-based. A second opinion can catch a blind spot, but two agreeing models can still be wrong. The repository, reproducible tests, and human risk judgment remain the source of truth.
Use Aident Loadout to give both coding agents the same scoped integrations. For your first measurable run, review one branch, record reported versus confirmed findings, and stop after one verification pass.
Sources
Refresh this guide when the plugin's install commands, review target selection, background-job behavior, or review-gate contract changes.


