Composing Claude Code + Codex + Grok Build into one workflow — what actually works (July 2026)

Why this is in the vault

The founder asked whether RDCO can widen its harness by driving Codex and Grok Build alongside Claude Code on subscriptions he already pays for; this note records which integration mechanisms are documented and working versus which are blog-fiction, so the build decision rests on verified commands rather than plausible ones.

1. The patterns people actually run

Six recur across practitioner threads and official tooling. Ranked by evidence quality.

A. Cross-model adversarial review (strongest evidence, most copied). One model writes; a second model reviews the diff without ever seeing the first model's reasoning. OpenAI ships this as a first-party product: the codex-plugin-cc plugin for Claude Code exposes /codex:review (read-only) and /codex:adversarial-review (steerable challenge). Drew Hyde's "super-review" skill runs the same shape by hand — Claude reviews across eight dimensions, then Codex reviews independently, then Claude synthesizes both into one report. Claimed benefit: catching the class of bug Claude produces "with absolute confidence."

B. Convergence-gated review loop. HN user bicepjai reports Claude plans and executes, Codex reviews, and the work is not done until Codex returns no issues on three consecutive runs against the current diff, plus coverage thresholds. This is the only quantified stopping rule I found — most people eyeball it.

C. Plan → cross-validate → implement → post-commit review. HN user kevinsync ($100 Claude + $20 Codex): Claude /plan, then /co-validate ships the plan file to Codex for amendment, then Claude implements the amended plan and commits, then a Codex skill reviews the commit for gaps and missed edge cases. Handoff artifact is a markdown plan file on disk (.claude/plans/*.md). Tooling: the claude-co-commands plugin (SnakeO/claude-co-commands).

D. Parallel attempts, pick a winner. johannesjo/parallel-code (~892 stars) launches Claude Code, Codex CLI, Gemini CLI, Copilot CLI and Antigravity CLI each in its own git worktree on the same task, symlinks node_modules, then gives you a diff viewer and a merge-the-winner button. Agents do not talk to each other at all — isolation is the whole product. just-every/code does the racing variant: /plan takes a Claude+Gemini+GPT-5 consensus, /solve races them and the fastest wins.

E. Split by strength / task routing. HN user wek (Max on both) routes new features and mockups to Claude, deep fact-checking to Codex, and has each check the other. cmrdporcupine uses Claude as author and a cheap $20 Codex seat as reviewer/planner/tester — the second seat exists purely to extract more value from the first.

F. Redundancy, not quality. hulk-konen runs ~$50/mo across three harnesses explicitly so a vendor outage or a rate-limit wall doesn't stop work. Under-discussed but the most defensible reason to hold two subscriptions.

Spec-first (one agent writes the tests, the other implements, so the implementer can't cheat the tests) appears in shakacode's docs as a recommended pattern but I found no practitioner reporting real results from it.

2. Integration mechanics — how they actually talk

Five distinct mechanisms. All five are real; they differ sharply in coupling.

MCP, Codex as server (confirmed). codex mcp-server starts Codex as a stdio MCP server. OpenAI documents it on the Codex Agents-SDK page, and it exposes exactly two tools: codex (args include prompt, model, sandbox, approval-policy, cwd, config) and codex-reply (prompt + threadId, for continuing a thread). Wiring from Claude Code, as practitioners post it:

claude mcp add codex -- codex mcp-server
claude mcp add codex-high -- codex -c model_reasoning_effort="high" -m "gpt-5-codex" mcp-server

The tool then surfaces in Claude Code as mcp__codex__codex. Note codex mcp serve does not exist — codex mcp is client-side server management (list|get|add|remove|login|logout). Symmetrically, claude mcp serve is documented, so Claude Code can be the server and Codex the client.

Subprocess (codex exec) driven from a skill (confirmed). Claude Code shells out and reads stdout. This is what the founder's framing implies and it is the cleanest fit for RDCO. A real headless invocation posted by HN user zuzululu:

codex exec --json --skip-git-repo-check --ephemeral -s read-only \
  --disable memories -m gpt-5.5 -c model_reasoning_effort=high "<task>"

HN user w-m describes a skill that instructs the orchestrator to spawn subshells each running codex exec, used as a subagent substitute. HN user azuanrb built an internal review tool on codex exec plus worktrees, reviewing the whole codebase rather than the diff.

Official plugin (subprocess under a slash-command skin). openai/codex-plugin-cc — published by OpenAI, installed with /plugin marketplace add openai/codex-plugin-cc, /plugin install codex@openai-codex, then /codex:setup. It wraps the Codex app server and delegates through the local codex CLI; it is not MCP. Commands: /codex:review, /codex:adversarial-review, /codex:rescue (delegate a task), /codex:transfer (persistent Codex thread), plus /codex:status, /codex:result, /codex:cancel for background jobs.

Files on disk. The lowest-tech and most widely used surface: AGENTS.md as the shared instruction file (Codex reads it natively), symlinked to or duplicated into CLAUDE.md; a plan markdown file as the handoff packet; a CHANGES.log both agents read on start and append on finish. Cheap, inspectable, no protocol risk.

Git worktrees. The isolation substrate under every parallel pattern. Claude Code documents worktree sessions officially. shakacode's guidance is blunt: use worktrees whenever two agents run at once, because same-directory agents silently overwrite each other.

ACP (Agent Client Protocol). JSON-RPC over stdio, originated at Zed, Apache-2.0, protocol version 1 stable. Designed as editor-to-agent ("LSP for agents"), but the published client list includes multi-agent orchestrators and chat bridges, so agent-to-agent is viable in practice. Grok Build supports it first-party (grok agent stdio); Codex and Claude reach ACP only through third-party adapters. For RDCO this is a worse bet than MCP or plain subprocess.

3. Headless viability — the cron question, per tool

Nothing here is interactive-only. All three are cron-drivable today.

Not confirmed: I did not find documented per-run wall-clock timeouts for codex exec or grok -p, and shakacode's doc explicitly notes no timeouts are documented. Assume you must impose your own via the calling shell.

4. Authentication reality — does the subscription actually buy unattended compute?

Codex: yes, with a real caveat. Codex CLI authenticates two ways that bill completely differently. Signing in with ChatGPT draws on the plan's included usage; an API key bills every token through the OpenAI Platform account at standard API rates and does not touch plan credits. OpenAI's non-interactive doc says saved CLI auth is reused automatically, and describes using the ChatGPT-account auth.json for CI/CD while warning against it for public repos (a secret-handling warning, not a licensing one). So a locally-authenticated Mac mini running codex exec from cron does consume the ChatGPT plan, not API credits.

The caveat: every Codex surface draws from one pool. CLI, IDE extension and cloud tasks share the same 5-hour rolling window and the same weekly cap. An unattended review loop competes directly with the founder's interactive Codex use, and will silently starve it.

Grok Build: yes, but partially inferred — flagging this. xAI documents four auth methods: browser OIDC (grok login, the default), device code (grok login --device-auth, for headless boxes), an external auth provider, and an API key (XAI_API_KEY or model.api_key) which the docs describe as best for scripts, CI/CD and headless automation and note is non-refreshable. Login-path traffic routes through an inference proxy; api.x.ai is only needed for the API-key path. Separately, the Grok FAQ says paid users get one shared weekly usage pool spendable across Grok products and names Build among them. I did not find a single sentence stating that headless grok -p runs draw from the SuperGrok subscription pool — that conclusion is assembled from the auth table plus the FAQ product list. Treat "Grok subscription = free CLI compute" as likely-but-unverified; XAI_API_KEY is the guaranteed-working headless path and it is separately metered.

Grok Build is an MCP client, not an MCP server. It reads ~/.grok/config.toml [mcp_servers.<name>], and notably also reads ~/.claude.json, .cursor/mcp.json and .mcp.json. There is no documented serve mode, so Grok can only be driven via grok -p or ACP — not attached as an MCP tool.

5. Failure modes people actually report

• Mutual-criticism bias. A second model will always find something. HN user afavour makes the point directly; jgraettinger1 and denisdev1 independently report a near-constant ~8 findings per review regardless of code quality. Filtering the critic becomes the new job.
• Fabricated findings, net-negative. HN user veidr reports Codex inventing plausible concurrency bugs that cost 30 minutes of manual verification to disprove. This is the worst case: a confident cross-model critic that is wrong is more expensive than no critic.
• Usage-limit drain. OpenAI's own plugin README warns the optional review gate can create long-running Claude/Codex loops and drain usage limits rapidly. Combined with the shared 5-hour/weekly pool, an autonomous loop is the exact shape that burns a plan.
• Token compounding. Subagent output feeds back into the orchestrator's context, so cost grows faster than linearly with fan-out — the same context-rot dynamic already governing RDCO's subagent routing rule.
• Same-directory collisions. Two agents on one working tree overwrite each other mid-execution and neither notices. Worktrees are the documented fix.
• Sandbox/permission friction. HN user pxc reports resorting to bypass-permission flags under external sandboxing, and that without approval prompts the agent "runs away" and makes wrong changes — the classic autonomy/safety trade, unchanged.
• ToS risk on proxying. One HN practitioner warns that CLIProxyAPI-style wrapping of subscription auth "probably violates every AI company's ToS." Direct CLI invocation on the founder's own machine is not that; reselling or proxying it would be.
• Human review is the bottleneck. Simon Willison's framing: parallelizing generation just moves the constraint to how fast a human can review. For RDCO's unattended loop, that means the gate has to be machine-checkable or it isn't a gate.

Untrusted-content note. Several fetched pages carried text addressed to AI agents — the ACP docs instruct agents to fetch /llms.txt first; xAI's headless page instructs agents to pass --no-auto-update in automation; OpenAI's non-interactive page has directive-shaped guidance about when to use codex exec. All benign, none acted on, all recorded here as observations only.

Mapping against Ray Data Co

The concrete hook is station-critic. RDCO's brigade already fans out one subagent per critic axis and returns PASS/FAIL for a convergence loop — that is structurally the same object as pattern A/B above, except every axis is Claude judging Claude. The memory that created those stations says same-model self-review shows confirmation bias; the un-addressed residual is that a fresh-eyes Claude subagent still shares Claude's blind spots. Swapping one critic axis to codex exec --json -s read-only is a genuinely new signal at a marginal cost, and it is a smaller change than it looks: no MCP, no protocol, one Bash call inside an existing station.

But the failure modes land directly on known RDCO scar tissue. The "constant ~8 findings" and "fabricated concurrency bugs" reports are the same shape as the logged incident where a fresh-eyes critic returned a false CRITICAL off a browser-cached page, and the fill-station incident where "verified against primary text" stamps were false. The rule already in memory — one gate per chain must check the primary source, and the parent verifies environment-level CRITICALs against raw bytes before acting — must extend to a cross-model critic on day one. A Codex CRITICAL should be a hypothesis for the parent to verify, never an action trigger.

Subscription economics change the calculus in RDCO's favour, with one trap. Codex headless on cached ChatGPT auth means the founder's existing Codex seat is real unattended compute for the Mac mini — no new API line item. The trap is the shared 5-hour and weekly pool: a nightly cron loop competes with his own daytime Codex use and will drain it silently. Any wiring needs a budget guard (cap invocations per window, prefer diff-scoped over whole-repo reviews) before it goes on a schedule. Grok is the weaker case: headless is confirmed, but subscription coverage of Build CLI runs is inferred, not documented, so the honest first step is a single manual grok -p run to observe which meter it debits, not a build.

Two existing RDCO rules bind this work. No secrets on disk means XAI_API_KEY / CODEX_API_KEY (if ever used) go through the 1Password wrapper-script pattern, never a .env. And the PR-only workflow plus the worktree evidence above point the same direction: if two agents ever act on the same repo concurrently, they get separate worktrees and separate branches, not a shared checkout.

What I would not build yet. The parallel-attempts pattern (D) is the most-blogged and the least useful here — RDCO's bottleneck is not generating three candidate implementations, it is verification quality on a single artifact. And ACP is a worse interop bet than plain subprocess for our case: Codex and Claude only reach it through third-party adapters, so it adds a dependency without adding a capability we lack.

Related

• [[2026-05-10-agent-harness-landscape]] — the May harness survey covering Claude Code, Cursor, Codex and Devin; this note is the "how do you compose two of them" follow-up it left open.
• [[2026-04-21-indydevdan-one-agent-is-not-enough]] — the domain-locking argument that more agents are safer if each is scoped; the cross-vendor critic is the same claim with vendor diversity as the scoping axis.
• [[2026-06-02-thariq-dynamic-workflows-harness-for-every-task]] — Anthropic's dynamic-workflow framing, where control flow is deterministic code and only the work inside each step is model-powered; a codex exec call is just another step in that shape.
• [[2026-04-15-thariq-claude-code-session-management-1m-context]] — the context-rot source behind RDCO's subagent-routing rule, which is also why fan-out token compounding is a real cost here.
• [[2026-05-24-openai-workspace-agents-vs-claude-substrate-30day-check]] — the prior read on OpenAI as a substrate alternative; this note argues the better framing is OpenAI as a second opinion inside a Claude substrate, not a replacement for it.