Connect Codex and OpenCode for code review

You can have OpenCode review a Codex implementation, or Codex review an OpenCode implementation, by routing a focused request through Scout. Give the reviewer a stable commit range and the intended behavior. Scout records the request and returns a reference you can use to read the result and clarify findings.

A second tool needs more than a copy of the diff: it needs the behavior the change is meant to preserve, the exact revision to inspect, and a way to return findings you can assess. This guide gives you a reusable brief and follows it through review, clarification, and correction.

This guide uses a hypothetical pagination change: the implementation replaces an offset with a cursor. The scenario illustrates what a useful review packet contains; it makes no claim about findings produced by a past run. Start with the runtime check, fill in the review brief, then send it to OpenCode.

Check the tools and selected model

Follow the Codex setup guide, OpenCode setup guide, and Scout quickstart. The receiving machine needs the relevant harness installed and authenticated, a healthy broker, and access to the checkout:

OpenCode is a harness with configurable model providers. Its name alone does not identify the model reviewing your change. If you want another model's perspective, inspect the actual provider and model configuration. A different interface can still use the same model family. To pin one, add --model with an OpenCode model id that scout runtimes --json lists; the provider still has to grant access to it. OpenCode provider documentation↗.

This workflow uses the provider accounts configured for those runtimes. A local Scout broker keeps coordination local; it does not make model inference local. OpenScout's current posture is a high-trust developer pilot.

Choose a review boundary you can explain

For the pagination example, a useful goal is “find conditions under which a cursor skips or repeats a record.” A broad request to “review everything” spreads attention across unrelated style and architecture questions.

For a small uncommitted diff, pause writes for the duration of the review. For longer work, use committed revisions and a separate review checkout. A branch name can move; record the commit the reviewer actually inspected.

Prepare a reusable review brief

Replace the illustrative requirements with the behavior your product actually promises:

Task: correctness review of the cursor-pagination change.
Checkout: /absolute/path/to/review-checkout
Base: BASE_SHA
Head: HEAD_SHA
Intent: replace offset pagination while preserving documented ordering.
Requirements:
- Explain what happens when two records share the ordering timestamp.
- Check cursor validation and handling of deleted boundary records.
- Compare the implementation with our documented insertion policy.
- Identify any caller compatibility changes.
Scope: changed code plus callers and definitions needed to assess it.
Actions: read-only; do not edit, merge, deploy, or run tests.
Return:
- Revision inspected and review scope.
- Findings with file/line, triggering input, and user-visible consequence.
- Assumptions, unchecked behavior, and proposed focused checks.
- Explicit no-findings statement if no actionable issues were identified.

Give the reviewer requirements and relevant decisions without pasting an entire implementation conversation. The brief should allow the reviewer to inspect the code and form its own explanation. Include product decisions that would otherwise be impossible to infer.

“Read-only” in the prompt is an instruction, rather than a sandbox guarantee. Configure the destination's permissions when stronger enforcement is required. OpenCode supports per-agent permissions: its built-in Plan agent asks before file edits and shell commands by default, and custom agents can be configured further. A Scout harness request does not automatically select Plan or your custom reviewer. OpenCode agent documentation↗.

Send the Codex change to OpenCode

Save the completed brief as a UTF-8 file. Replace both paths below; --prompt-file sends the brief’s contents as the request. The receiving checkout must contain the base and head commits:

Project routing resolves or launches a suitable worker. It does not automatically continue whichever OpenCode terminal you last used. If a particular existing session matters, use its verified Scout target instead of guessing a name.

Save the ref: handle from the receipt. The receipt means Scout accepted the request; the review can still be queued, running, or waiting for attention.

Read the result and ask for evidence

Replace ref:REVIEW with that exact handle:

Use the new receipt returned by the clarification request to wait for that answer. The original review reference keeps the conversation connected; each follow-up has its own result to check.

A wait timeout ends only the wait; it does not cancel or fail the task. Wait on the same handle again and address any authentication or permission issue reported by the destination. Sending the original ask again can create duplicate reviews.

For the pagination example, suppose records A, B, and C share a timestamp and the first page returns A and B. A useful finding would point to a strict timestamp comparison that drops C from the next page, explain the expected ordering, and identify the relevant line. This is an illustrative failure condition: the reviewer must establish it from your actual implementation. A generic warning that “cursors are tricky” is too vague to justify a patch.

“No findings” is also a valid result. Ask what was inspected and what remains unverified; it should not be presented as proof that every execution path is correct.

Bring accepted findings back to the implementer

Assess each finding against the requirements and code. Record whether it is accepted, rejected with a reason, or awaiting clarification. Assign accepted fixes to one owner so the reviewer and implementer do not both change the same files.

If you have the original Scout implementation reference, continue that work:

Replace the placeholders and retain the new receipt for this correction. An implementation started directly in Codex may have no Scout reference. Continue it in that original client, or create an explicitly scoped new task with the necessary context. Do not invent a reference or assume a new session knows the prior decisions.

After the correction, give the reviewer the new revision and ask whether the specific issue is resolved. Record any additional changes that need fresh review. A review of the old commit cannot establish the quality of the new one.

Reverse the direction: OpenCode implements, Codex reviews

Keep the same brief and select Codex as the destination:

Use this request's own reference for waiting and follow-up. Roles can change by task. Codex also has native subagents for delegated work within its own harness; using OpenCode adds a separate environment and provider configuration that you must supply and understand. Codex subagent documentation↗.

If the review does not reach a useful result

Two peers, different connection mechanisms

The interfaces are asymmetric even when the agents are peers. Codex exposes an app-server protocol; OpenCode has client/server and ACP paths. The bridge translates requests and lifecycle events between the selected interfaces. It does not need to label one tool the permanent implementer or reviewer.

OpenCode V2's detached service is particularly useful for understanding ownership: the UI and execution process have separate lifetimes. Current upstream clients and Scout's pinned beta adapter are different versions. Scout's ordinary --harness opencode examples use its configured route; they do not establish that you attached to a V2 service. See the V2 adapter's compatibility table↗.

The field guide's mechanism comparison explains stdio, local IPC, detached services, permission handling, and reconnection. The review above is one task these peers can exchange in either direction.

Keep the workflow small enough to inspect

Start with one change, one reviewer, and one integration owner. Additional reviewers are useful when each has a distinct question, such as API compatibility or migration behavior. Repeating the same broad prompt across several tools can create more opinions without making the decision clearer.

For cross-machine work, ensure the destination contains the actual revision and brief. Scout reachability does not synchronize Git checkouts, credentials, or external transcripts. Separate worktrees isolate files; shared databases and ports remain shared unless you arrange otherwise.

The outcome to retain is concrete: reviewed revision, findings, dispositions, corrected revision, and checks actually performed. Configure Codex and OpenCode to try one handoff. Compare the Claude Code–Codex review workflow, or use the collaboration guide to choose the next path.