# Have a second AI agent review code changes: a search race fix

> Have a second AI agent review code changes: hand a Claude Code fix to a Codex reviewer with a factual brief, then make the final call yourself.

Published 2026-09-25 on the Starkomand blog: https://starkomand.com/blog/review-search-race-condition-with-second-agent/

A search box passes the obvious check: type “canvas” and matching results appear. But what happens when an earlier request for “can” finishes afterward and paints its results over the ones you asked for?

Suppose an agent reports that it has fixed exactly that race. This is where I would have a second AI agent review code changes: a separate session with its own context, asked a concrete question instead of “does this look good?”. This walkthrough shows how I set that up in [Starkomand](https://starkomand.com/), with Claude Code as the implementer and Codex as the reviewer. The search bug is an illustrative example, and the terminal output in the captures is scripted.

## Why shouldn't the agent that wrote the fix review it?

The implementing agent has already explained the bug to itself. Its conversation holds the hypothesis (responses arrive out of order), the change it chose and the test that proves that change. Asking the same session to review its diff mostly replays that reasoning.

A fix is a hypothesis until something outside that reasoning tries to break it. A reviewer that starts from the requirement and the diff, without the implementer's narrative, is free to ask what happens when the query is cleared or the old request fails. It may still miss those cases, but it is not anchored to the first explanation. That is why review in Starkomand is its own step, not a prompt typed into the same window.

## Start with a reproducible problem

Give the implementer the sequence that exposes the failure:

> Fix stale search results overwriting the current query's results. Reproduce this sequence: request A starts for “can”; request B starts for “canvas”; B completes first; A completes afterward. The UI must still show the results for “canvas”. Preserve the existing debounce behavior. Add a regression check that controls response order.

Let the agent investigate and finish. When it reports back, keep the original requirement in view: that, not the agent's summary, is what the review checks.

## How to hand the change to a second agent for review

In the implementer's window header, open **Agent actions** (the ⋯ button) and choose **Hand off…**. The card asks *What should the next agent do?* Pick **Review**, which the app describes as “Fresh perspective on the diff and goal. No edits.” Under **New agent**, the receiving agent starts as the one saved for the Review workflow; here that is Codex, with its model and effort. **Only this handoff uses these choices**, so picking a different reviewer for one fix leaves the saved default alone. Using Codex to review a Claude Code change is a workflow choice, not a claim that one model reviews better.

![Felix's Claude Code window with the Hand off card open: Review is selected, Codex is the receiving agent on the Astra model at high effort, and Return fixes to the implementer is left off.](https://starkomand.com/assets/blog/review-search-race-condition-with-second-agent/review-handoff.jpg)

*Agent actions → Hand off… with Review selected. Captured from the app with scripted terminal output; the repository and file names are illustrative.*

When you press **Hand off**, the implementer writes the context for the next agent, and for a review it writes a different kind of brief. Starkomand asks it for a factual review brief in three parts: the comparison base (a commit hash or diff range), the scope (which changes and which requirement to inspect), and the constraints that still apply. It is told to leave out its implementation reasoning, self-review, test results and earlier verdicts, so the reviewer forms its own findings first. The server refuses a review handoff that arrives without that brief.

The reviewer launches once, after the implementer's turn has finished, in a new window wired to the implementer's. It starts outside the implementer's squad, so the squad's shared notes, which reach every member's prompt, are not passed to it, and it wears no squad colour. Notes from earlier handoffs are listed in the task's history as excluded from review context.

## Findings only, or a bounded review-and-fix loop?

The single **Review** workflow stops at findings. Its saved instructions end with “Do not edit files”, and nothing returns to the implementer unless you decide it should: the right default when you want to read the report before anything else changes.

If you would rather let the agents iterate, tick **Return fixes to the implementer** on the same card; its hint reads “Runs the saved review loop. Leave off for findings only.” The option needs a reviewer that can return a structured verdict, as Claude Code and Codex can. Required fixes then go back into the original implementation conversation, the reviewer checks again, and an optional QA stage can follow a passing review. The loop is bounded: three review rounds by default. To choose the limit for one run, open the model chip in the implementer's header, choose **Change stage →**, tick **Run configured loop until ready for human review** and set **Review rounds** anywhere from 1 to 8.

![The stage picker opened from Felix's model chip. Run configured loop until ready for human review is checked, the loop reads review, implement, qa, and Review rounds is set to 3.](https://starkomand.com/assets/blog/review-search-race-condition-with-second-agent/review-loop.jpg)

*The review loop options in the stage picker. Captured from the app; the terminal text is scripted.*

The loop pauses for you on a blocker, when the same findings survive a fix, or at its round limit. The reviewer, its model and its instructions live in **Workflows** (open it from **Edit workflows →** or **Change saved defaults**), as shared defaults or as an override for one project.

## What evidence should the reviewing agent return?

“Looks good” is hard to evaluate. A finding such as “clearing the query lets the previous request repopulate the list” tells you what to reproduce and why the change needs another pass.

For this example, ask about three outcomes:

1. **Responses finish out of order.** The results still match the latest query.
2. **The query is cleared.** A pending response does not bring back the old results.
3. **An old request fails.** Its error does not replace a newer successful result.

Ask the reviewer to separate checks it ran from cases it only read in code. In the scripted review below, the out-of-order case was run and passes, the cleared query was reproduced, and the failing old request was only inspected.

![Felix's Claude Code window wired to Nora's Codex window. The wire's tag reads Reviewing, finished, review. Nora lists a passing out-of-order check, finding R1 for the cleared query and finding R2 for the old request failing, each with a file location.](https://starkomand.com/assets/blog/review-search-race-condition-with-second-agent/review-wire.jpg)

*A scripted review of the example fix. Captured from the app with a mocked terminal session; the commit, file locations and findings are illustrative.*

Findings only describe the code they were made against. In a review loop, each verdict is recorded with its evidence, findings and repository revision, which the task's history shows beside every result. Before the loop moves on, Starkomand checks that the files still match that revision. If anything changed during review or QA, it pauses and asks for a fresh review instead of carrying an old verdict forward.

## Who decides the fix is done?

You do. A second agent can surface a missed case; its presence does not prove the implementation is correct, and its approval does not finish the work. When a review loop passes, the task reaches **Ready for human review** with the note that agent approval is not human acceptance.

Click the wire's tag and choose **Open in Work →** to see the saved brief, the handoff history and each recorded result. Read the findings alongside the diff and the checks. The task becomes complete only when you mark it so with **Mark completed**.

## The Starkomand features in this walkthrough

- **Agent actions → Hand off… → Review**: [hand a change to a separate review agent with a focused brief](https://starkomand.com/#scene-handoff-title).
- **An independent reviewer**: a factual review brief, a fresh window outside the implementer's squad, and [the issue-to-review workflow on one canvas](https://starkomand.com/#workflow).
- **Return fixes to the implementer** and **Review rounds**: [bounded review loops that check files before continuing](https://starkomand.com/#features).
- **Recorded revisions and Ready for human review**: [why an approved review does not accept the task for you](https://starkomand.com/#faq).
- **Claude Code and Codex side by side**: [the coding agents Starkomand runs on your Mac](https://starkomand.com/#agents).

When the requirements need settling before anyone writes code, [plan a feature in Claude Code and hand the implementation to Codex](https://starkomand.com/blog/handoff-csv-export-claude-code-to-codex/). When the implementer and the reviewer are two of several agents you left running, [pick up each session from its recap](https://starkomand.com/blog/resume-two-projects-with-agent-recaps/). For the reasoning behind the layout, read [why I put coding agents on an infinite canvas](https://starkomand.com/blog/why-i-put-coding-agents-on-an-infinite-canvas/).

To try this on your next fix, [start the free 3-day Starkomand trial for Mac](https://starkomand.com/) and hand the change to a reviewer with one failure sequence it must check.