One Codex Writes, Another Reviews: Two Threads, Evidence of Completion

You can watch Codex through every step of a difficult task, or give another Codex thread the job of checking its work. Opening another window is the easy part. The useful change is giving the two threads different responsibilities—and asking the reviewer to show what it actually verified.

1. The Worker and Supervisor Have Different Jobs

For a complex task, you can ask the main thread to delegate the implementation and keep responsibility for checking it:

Write a clear task for a worker subagent and delegate the implementation to it. You supervise: compare its progress with the goal, check the results, and send back specific findings when something is missing. Report what was verified and what remains unresolved.

This uses Codex's subagent delegation where that capability is available. It doesn't make any two open chats communicate automatically. You can also open a separate chat yourself and carry the task, relevant files, and findings between them.

The worker writes code, changes files, and runs commands. The supervisor keeps the goal in view: did the implementation miss a requirement, drift into a different task, or stop at a version that merely looks usable? Agree on who may edit which files so the checking role doesn't become a second writer changing the same code underneath the first.

For example, suppose the worker reports that a feature is finished. The supervisor compares it with the requirements and finds that only the normal path was tested. The error path still has no result to inspect. Sending that specific gap back gives the worker something concrete to test and fix.

2. Self-Review Can Repeat the Same Assumptions

Why do more than ask the coding thread to check carefully?

The thread that chose an approach can carry its assumptions into the review. “The requirements are covered.” “That case shouldn't happen.” “The existing tests should be enough.” Those statements can sound like conclusions while leaving the original assumptions untested.

“It should work” and “this check passed” tell you different things.

A separate reviewer can start with the requirements and the current code, then form its own questions. That gives it an opportunity to challenge the implementation. A fresh context doesn't guarantee an independent judgment, though. Give it the author's conclusions as settled facts, and it may repeat them. Let it inspect the requirements, code, and results before reading the author's case for why everything is fine.

3. The Number of Findings Isn't the Point

A reviewer's list can include cautious warnings, low-value comments, and outright mistakes. It may also contain the finding that matters: an unhandled edge case, a test described in a document but never run, an unchecked environment assumption, or a required branch that doesn't exist in the code.

Judge the review by whether it moves the task from written code to checked behavior. Ten speculative comments are less useful than one reproducible failure tied to a requirement.

4. Two Ways to Divide the Work

Supervision: the main thread breaks down the goal, gives the worker a task, and checks its progress. When the worker gets stuck or drifts, the supervisor sends back a specific question or finding. With subagents, the main thread can collect their results; with manually opened chats, you carry those messages yourself.

Independent acceptance: the main thread implements the change first. A new reviewer that didn't write it then checks the requirements, runs the available checks, and returns findings without editing the implementation. The author fixes the problems, and the reviewer checks the revised result.

The second arrangement resembles development and testing as separate responsibilities. The reviewer needs enough context to understand the requirement, but the author's confidence isn't evidence that the requirement was met.

You can use a prompt like this when subagent delegation is available:

Plan and implement this task. When the implementation is ready, delegate an acceptance review to a subagent that didn't write it. Give the reviewer the requirements and the exact files or revision to inspect. The reviewer must not change the implementation.

Check requirements completeness, logical correctness, edge cases, code quality, test coverage, and actual runtime behavior. Run the relevant tests or program where access and the environment allow. For each finding, identify the requirement, the affected location, and the observed failure or reason it needs checking. Return the commands run, their results, and any checks that could not be run.

Fix confirmed problems, then ask the reviewer to check the affected behavior again on the updated version. Report unresolved failures or blocked checks rather than calling them complete. If the same failure persists or progress is blocked, stop and explain what decision or access is needed.

Those six areas guide the review. They aren't proof that every possible failure has been covered, and the prompt doesn't create an unlimited automatic loop.

5. Ask for the Evidence

One request makes the handoff more useful: show the verification evidence.

Without it, the reviewer can read the code and return another polished summary saying it looks finished. Ask instead what it ran, which version it ran against, what happened, and which requirement that result supports. If it couldn't run the program, that belongs in the report as an unverified item. Asking for evidence gives you a way to inspect the claim; it doesn't guarantee the agent has the access to obtain it.

6. A Third Role, When the Task Warrants It

You can separate three responsibilities:

1. The Builder implements the change.
2. The Critic challenges the approach and looks for failures.
3. The Evaluator compares the evidence with the original goal and decides what is complete or still unresolved.

More roles add communication, time, and token costs. A worker and reviewer may be enough for an ordinary feature. A large refactor, a change spanning several modules, or a long task that's hard to assess as a whole may justify separating criticism from the final evaluation. The roles earn their place by answering different questions, not by adding more votes of approval.

7. A Lighter Alternative: Review in a New Chat

You can also bring the work to a new window for one final review. Give it the original requirements, the code or diff, and the results available so far.

Copying the entire conversation is possible, but it carries the earlier reasoning and assumptions with it. The new chat then has that history in its context; it isn't a blind review. A smaller handoff can let the reviewer inspect the work before reading the author's explanation. Either way, a fresh window can still miss a bug or agree with a mistaken premise.

With supported delegation, an agent can ask another agent to implement or examine a task and use the returned findings to continue. With separate user-opened chats, the handoff is manual. Neither arrangement is infinite self-improvement, and two threads don't guarantee a correct result. Check the tests and observed behavior, including what neither thread managed to verify.

8. What Changes

The question moves from “Did it finish writing the code?” to “Can someone who didn't implement this show which requirements were checked on this version?”

A first implementation gives the reviewer something to examine. A useful finish has an author who resolves the findings, a reviewer who checks the fixes, and evidence you can read for yourself.