Claude Plans. Codex Builds. Show Me That It Works.

Sep 11, 2026 · Tim De Vallee · claude-codecodexworkflowverification

When I tell an AI agent to build something, I do not want a pile of suggestions. I want it to read the project, understand the problem, make the changes, test them, fix what breaks, and show me the result.

Two models are only useful when the handoff is clear

That is why the Claude Code and Codex combination is useful. Give Claude responsibility for the brief, architecture, taste, and final review. Give Codex a bounded implementation job. Then make the work pass through a verification gate before it reaches you.

Build it. Check it. Fix what fails. Show me what works.

The value is separation of responsibility. One model translates the business outcome into an assignment. Another model executes it. The first model reviews the result against the original requirements and sends the worker back when the evidence does not hold up.

Define. State the outcome the user should be able to see or complete.
Specify. Write the acceptance criteria and protect the boundaries that must remain intact.
Build. Give the worker the smallest complete implementation it can finish and verify.
Review. Run the real feature and compare its behavior with the original brief.
Correct. Return exact failures to the same worker until the criteria pass.

Manager: Claude Code

Reads the situation, sets scope, makes architecture and design calls, writes the brief, and reviews the result.

Worker: OpenAI Codex

Inspects the repository, implements the assigned change, runs the requested checks, and returns evidence.

Revision gate: the work is judged against behavior

A summary is a pointer. A passing test, rendered page, denied unauthorized request, correct calculation, or verified deployment is evidence.

Install the tools and prove the connection

You need Claude Code, the Codex CLI, and the official Codex plugin for Claude Code. Current plugin requirements include Node.js 18.18 or later and either a ChatGPT subscription or an OpenAI API key.

Claude Code. Install and authenticate it on the machine where you work.
OpenAI Codex CLI. Install it globally and sign into the intended account.
Codex plugin. Install the official plugin from OpenAI’s Claude Code marketplace.

npm install -g @anthropic-ai/claude-code
claude doctor

npm install -g @openai/codex
codex login

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

Get the connection working before adding routing rules. The setup command checks whether Codex is ready. Check the current plugin README before installing because tooling and command names can change.

Point Codex at the model you want doing the work

This workflow routes its hardest work to GPT-6 Astra with high reasoning. Put the settings below in ~/.codex/config.toml, or add them to the relevant profile if you already maintain several Codex profiles.

model = "gpt-6-astra"
model_reasoning_effort = "high"

Run a small command and confirm the model shown in the Codex header.

codex exec "say hi"

Model access varies by account. If GPT-6 Astra is unavailable, choose a model your account can use. The workflow matters more than the name in the configuration.

Tell the manager how work moves through the system

Claude Code reads CLAUDE.md as project guidance. Put broad operating rules in ~/.claude/CLAUDE.md. Put repository-specific rules in the project’s own CLAUDE.md.

Claude or Fable 5.1 — planning and review. Planning, architecture, acceptance criteria, product judgment, copy, and final review.
GPT-6 Astra — complex implementation. Difficult implementation, multi-file refactors, computer-use work, and failed escalations.
GPT-5.6 Sol — routine implementation. Routine builds, tests, debugging, repository research, boilerplate, and brief-driven drafts.

This operating block turns the plan-build-review workflow into rules for real client work: repository instructions, ownership, existing changes, privacy, and evidence.

# Manager and workers
Claude is the manager. It reads the project, defines the outcome,
writes acceptance criteria, makes architecture and design calls,
and reviews the finished work.
Implementation goes to a Codex worker when delegation improves
speed, focus, or review quality. Small conversational replies and
pure judgment calls can stay inline.
## Before work starts
1. Read the repository instructions and the existing implementation.
2. Confirm the working directory, branch, and relevant application paths.
3. Identify user changes already in the worktree and preserve them.
4. Define what the user will be able to do when the task is complete.
5. Name the checks that will prove the result.
## Model routing
| Model | Use for |
|---|---|
| Claude / Fable 5.1 | Planning, architecture, product judgment, copy, final review |
| GPT-6 Astra | Complex implementation, multi-file refactors, computer-use work, failed escalations |
| GPT-5.6 Sol | Routine builds, tests, debugging, repo research, boilerplate, brief-driven drafts |
These are defaults. Judge the work by the result. Escalate when the
current model misses the bar.
## Worker brief
Every worker receives:
- The exact repository path.
- The problem and expected user behavior.
- The files or modules it owns.
- Relevant constraints and existing conventions.
- The checks it must run before reporting.
- The evidence required in its final response.
If several workers are active, separate file ownership or use isolated
worktrees. Tell every worker that other people or agents may be editing
the project. A worker never reverts changes it does not own.
## Revision gate
Every worker deliverable gets reviewed before it is accepted.
Run the real feature. Do not approve the work from a summary or diff alone.
- For interface work, inspect the actual page at the required sizes.
- For access control, test allowed and denied requests.
- For calculations, compare known inputs with expected outputs.
- For deployment work, verify the deployed route separately.
When a check fails, return the exact error, reproduction steps, and
expected behavior to the same worker. Continue until the acceptance
criteria pass or a concrete blocker remains.
Never remove, narrow, or substitute a requirement just to make a check pass.
## Completion report
Return a concise report with:
- What changed.
- Where it changed.
- What was tested and the result.
- What remains blocked or unverified.
Distinguish local implementation, deployment, and live verification.
Only claim the state supported by evidence.
Never print, echo, or write secrets, credentials, private customer data,
or production records into prompts, logs, screenshots, or reports.

Give the worker a job it can actually finish

Dispatch Codex with a repository path, a model, a sandbox, and a concrete task. Replace every placeholder and quote repository paths that contain spaces.

codex exec </dev/null -s workspace-write -c approval_policy="never" -c model="gpt-6-astra" \
  -c model_reasoning_effort=high -C <repo> "<task: files to touch, what done looks like, the commands to run before reporting>"

A real assignment should describe behavior, boundaries, checks, and evidence.

codex exec </dev/null \
  -s workspace-write \
  -c approval_policy="never" \
  -c model="gpt-6-astra" \
  -c model_reasoning_effort=high \
  -C "/absolute/path/to/project" \
  "Read the repository instructions and inspect the existing shipment
  dashboard. Implement the missing empty and error states using the
  current UI conventions. Keep all existing authorization checks.
  Preserve unrelated changes. Run the relevant project checks and
  inspect the affected page if browser access is available. Report
  changed files, verification results, and anything still unverified."

A useful brief answers five questions: What is wrong? What should the user experience instead? Where may the worker change code? What must remain intact? Which checks prove the work?

The workspace-write setting confines writes to the workspace. An approval policy of never means the worker cannot stop and request broader execution permission, so blocked actions can fail. Use a policy that fits your environment.

Keep the correction attached to the same work

When a check fails, send the exact failure back to the same Codex session. That keeps the repository context and the decisions already made.

codex exec </dev/null resume --last -c approval_policy="never" "<exact error text or next chunk>"

When several sessions exist, use the exact session ID. It removes ambiguity.

codex exec </dev/null resume SESSION_ID \
  -c approval_policy="never" \
  "The shipment page crashes when the query returns no records.
  Reproduce the failure, add the missing empty state, and rerun the
  relevant checks. Report the result with file and route pointers."

Stay inside Claude Code when that is where the job started

The official plugin exposes review, adversarial review, rescue, status, and result commands. Use review when you want Codex to challenge current work without changing it. Use rescue when you want Codex to investigate or implement.

# Hand a concrete implementation problem to Codex
/codex:rescue investigate the failing shipment dashboard and fix the cause
# Run a normal read-only review
/codex:review --background
# Challenge architecture, assumptions, and risk
/codex:adversarial-review --background look for authorization gaps and race conditions
# Check the job and retrieve its report
/codex:status
/codex:result

Make done mean something

A successful build is one signal. It does not prove that the feature works, that the right records appear, that access is restricted, or that the deployed route matches the local checkout.

Interface — inspect the page. Check the real route at desktop and mobile widths. Exercise loading, empty, error, and successful states.
Authorization — test both sides. Prove that an allowed user succeeds and a user outside the tenant or account is denied.
Data — use known inputs. Compare calculations, imports, and transformations with expected results you can verify independently.
Deployment — verify the live route. Local implementation, successful deployment, and working production behavior are separate claims.

Tell me what changed, point me to where it changed, show me what passed, and say exactly what remains unverified.

Current documentation

Installation and plugin behavior should be checked against the official repositories because tooling changes.

OpenAI Codex CLI — installation, configuration, authentication, and current CLI documentation.
Codex plugin for Claude Code — current installation sequence and the complete plugin command reference.
Claude Code setup — Anthropic’s current setup, authentication, and installation guidance.

Start with one useful job

Choose a contained improvement with an outcome you can see. Run it through planning, implementation, review, and correction. Tighten the handoff where information gets lost. Then expand the workflow.

Build it. Check it. Fix what fails. Show what works.

For the checks that belong in that revision gate, read Verification Is Not Typecheck.

Want all of this in your repo? Run npx hackerx init — drops CLAUDE.md and .claude/skills/ui-pattern-picker/ into your project. Open Claude Code. Watch the next vague request get three options.

← Back to blog