All posts
§September 25, 2026OpenScout

Claude Code and Codex code review: from finding to verified fix

Review an exact revision, reproduce a reported issue, and verify the correction.

Collaboration field guidesAbout 9 min read
Codex
Claude Code
Independent agents collaborating as peers. Share context, exchange ideas, and review each other’s work.

Ask Claude Code to review a diff that Codex produced, or ask Codex to review a diff that Claude Code produced. OpenScout's local broker records that ask, returns a ref, and lets you read the result and send a follow-up on the same ref. The reviewer is a separate session. It does not inherit the other harness's transcript.

The difficult part is deciding whether a finding describes a real failure, then checking that the fix addresses it. This guide focuses on that review loop. For installation and your first handoff, start with how to use Claude Code and Codex together.

A review is evidence for the person who owns the change. It is not a merge. OpenScout is a high-trust local pilot. Scout keeps the coordination record on the broker. The reviewer's model provider still receives the task data it needs. See data ownership.

Worked example (illustrative)

This diff is synthetic. It is not a production change, a captured model transcript, or a result measured from Claude Code or Codex.

diff
--- a/auth/grant.ts
+++ b/auth/grant.ts
@@
 export function grant(user: User, role: string): boolean {
-  if (user.isAdmin) return true;
+  if (user.isAdmin || role === "admin") return true;
   return user.roles.includes(role);
 }

A reviewer asked for correctness findings, or an explicit no-findings, could answer:

Finding. In auth/grant.ts, the added condition role === "admin" treats the role being requested as proof that the caller may grant it. A caller who is not an admin, and who passes "admin", takes the early return. The previous line returned early only when user.isAdmin was already true.

Why it matters. This function is an authorization check. The patch widens the admin path from the caller's flag to a string the caller chooses.

What would address it. Keep the early return on user.isAdmin only, or check a caller capability that is not the role being granted. Given a non-admin user with an empty roles list, requesting "admin" should return false. Under the illustrated patch it returns true.

What would verify the fix. Add that regression case and confirm it fails against the illustrated patch, then passes after the correction. Check that an authorized admin can still grant access and that an ordinary existing role still behaves as intended. These are proposed checks for this synthetic example, not tests run by this guide.

Use the finding as a lead. Re-read the frozen diff before you edit. A second agent can misread the intended rule. A reply that says no findings does not prove the patch is safe. Pause other edits while the reviewer reads the checkout, or name an exact commit, so the description still matches the file.

Claude Code's session commands↗ resume a Claude Code conversation. They do not import a Codex transcript. Put the goal, the acceptance check, and the diff scope in the ask.

Need the connection setup first? Follow the Codex setup guide or the Claude Code setup guide. Both lead to the same local Scout broker.

What you need

  • Scout installed on the machine that will run the review. Start with the Scout quickstart.
  • Claude Code and Codex installed and authenticated on that machine.
  • An absolute path to the checkout containing your changes, with permission for the reviewer to read it.
  • A small, stable diff and the intended behavior. For committed work, record the base and head SHAs. For uncommitted work, pause edits and explicitly include staged changes and new files.

The examples create real work in the selected harness and use its provider account. Scout keeps coordination records locally; the model provider receives the task data needed to perform the review. See the data ownership model when choosing what to share. OpenScout is currently intended for high-trust local developer pilots.

1. Check the broker and available agents

Run these commands in a terminal:

scout doctor
scout runtimes --json

Doctor should report a healthy broker. The runtime listing should show the destination harness is available. Complete any missing authentication or runtime setup before continuing.

A new reviewer does not automatically inherit your existing Codex or Claude conversation. Put the review scope and any important constraints in the request. The command below uses an exact commit range, so a moving branch does not silently change the review target.

2. Ask Claude Code to review your Codex changes

Replace the checkout path and both SHA placeholders below. The example intent is the authorization change above; replace it with the actual behavior your change must preserve:

scout ask --project /absolute/path/to/project --harness claude --notify "Review BASE_SHA..HEAD_SHA. Intent: preserve authorization checks while changing role handling. Inspect the changed code and relevant callers. Report the revision inspected and correctness findings with file, line, triggering input, and consequence, or no findings with limits. Do not edit files or run tests."

Confirm the receiving checkout contains both commits. For uncommitted work, replace the commit range with “uncommitted changes, including staged changes and new files,” and pause concurrent edits until the review finishes. Add any product requirements a reader could not infer from the code.

“Do not edit files” describes the requested task; it does not configure a sandbox. Use the destination’s permission controls for stronger enforcement.

Scout returns a receipt containing a ref. Save that value. It identifies this request and lets you return to its result. The receipt confirms the request was accepted; the review may still be queued or running.

3. Read the review result

Replace RETURNED_REF with the exact ref from the receipt:

scout wait RETURNED_REF --timeout 120

Wait for a completed result with the reviewer's reply. A useful reply identifies an issue, points to the relevant file and line, and explains the behavior that could go wrong. It can also explicitly report that no findings were identified.

If the wait times out, run the same wait command again. A timeout does not establish that the task failed. Check for a permission or authentication request in the destination harness if progress is blocked.

4. Ask a follow-up in the same conversation

Use the saved reference to clarify the review:

scout ask --ref RETURNED_REF --notify "For the highest-priority finding, give the smallest triggering input, the expected behavior, and the code path that produces the actual behavior. Identify any assumption that needs confirmation. If there are no findings, describe the scope and limits. Do not edit files or run tests."

The follow-up stays attached to the existing conversation and returns a new receipt. Use that new reference to read the clarification:

scout wait FOLLOWUP_REF --timeout 120

Replace FOLLOWUP_REF with the value from that receipt. Waiting on the original reference can simply show the original review again.

Assess the finding before changing code. A second agent can misunderstand requirements or miss an existing safeguard. Return supported findings to the implementing agent, make the fix, and run the checks appropriate to the changed behavior. A review with no findings is useful evidence, but it does not establish that the implementation is correct.

5. Turn an accepted finding into a verified fix

For each finding, record whether it is accepted, rejected with a reason, or still awaiting evidence. Give accepted fixes to the implementing agent with the relevant requirements and permission to run the focused checks.

Keep with the resultWhat it establishes
Reviewed base and headWhich version the finding describes.
Triggering input and expected behaviorA concrete claim you can reproduce or reject.
Accepted fix and new revisionWhat changed in response to the finding.
Checks performed and their resultsWhat was actually verified; proposed tests remain proposals.
Remaining limitationsThe behavior, dependencies, or environments still unchecked.

Return the new revision to the reviewer through the saved conversation reference and ask whether the specific issue is resolved. Wait using the new receipt. If the correction changes other behavior, include that scope in the follow-up. A review of the previous revision does not verify the new one.

Reverse the roles: ask Codex to review Claude Code changes

Use the same workflow with Codex as the destination:

scout ask --project /absolute/path/to/project --harness codex --notify "Review BASE_SHA..HEAD_SHA. Intent: preserve authorization checks while changing role handling. Inspect the changed code and relevant callers. Report the revision inspected and correctness findings with file, line, triggering input, and consequence, or no findings with limits. Do not edit files or run tests."

Replace the paths, SHAs, and example intent as above. Save the new receipt's reference and use it for waiting and follow-up. Choose the implementing agent and reviewer according to the work and the context they have. For more on choosing those roles, read Rotating Leads.

CLI, plugin, or MCP: which connection should you use?

The CLI is enough to run every step above. A Scout plugin or MCP connection lets your current agent request the same work from inside its own client.

Starting pointConnection guideResult
CodexScout for CodexRequest a Claude Code review through the local CLI, Scout plugin, or direct MCP connection.
Claude CodeScout for Claude CodeRequest a Codex review through the local CLI or Scout plugin commands.
Another compatible MCP clientScout MCP setupDiscover Scout tools and route work to an available agent.

Follow the guide for your installed client. Choose one MCP registration method for that client to avoid registering the same Scout server twice.

If the review gets stuck

SymptomNext step
Scout cannot reach the brokerRun scout doctor in the same environment as the command or client.
The destination harness is unavailableCheck scout runtimes --json and complete its setup or authentication.
The request remains queued or a wait times outKeep the same reference, check for a permission request, and observe that request again.
The reviewer sees the wrong changesConfirm the absolute checkout path and diff scope; pause concurrent edits.
The reviewer lacks earlier contextInclude the goal, relevant decisions, and constraints in your request or follow-up.

A complete review loop retains the reviewed revision, the findings and your decisions, the corrected revision, and the checks performed. Start with a small diff so you can inspect each step.

For a different reviewer, try Codex and OpenCode. For work that starts with a research question, use the Claude Code and Grok workflow.

Connect your current agent: set up Scout in Codex or set up Scout in Claude Code. If Scout is not installed yet, begin with the quickstart.

Practical collaboration

Find your next handoff.