Ultimate Agent Design to Awaken Claude × Codex [Latest Version]

Even if you are told "give more specific instructions," I want help starting from that very "specific part."

You have something you want to build, but your hands stop while doing the preliminary research needed to ask AI. This feels like a bad deal.

For example, suppose you want an app where you can register cases and sort them by approaching deadlines. You can say that much. But if you are asked about data storage methods or how to check for bugs, the amount of research suddenly increases.

While researching, you start cutting features you originally wanted to include, thinking "maybe it's okay without them this time." It's not because building them seems difficult, but because you want to keep everything within a scope you can manage yourself if something goes wrong.

I don't actually want to prepare every tiny instruction before asking. I want you to pick up on things I might have missed. It would be helpful if you could ask me to decide between two options in a clear way, and then proceed with the work based on those decisions.

The development team we assemble in this article is designed to get closer to that kind of request, using Claude Code and Codex.

• Claude Code: The point of contact for requests. Organizes necessary confirmations and division of labor.
• Codex: Handles implementation and inspection.

For a case management app, besides creating the screen, you also prepare verification tasks. What happens if you register with empty fields? Do records persist after reloading? If a bug isn't fixed, summarize the attempted fixes and remaining symptoms to hand over to another agent.

What humans do is make necessary judgments along the way and verify actual operations at the end. To facilitate this, create a structure where specifications, changes, and verification results return properly to your hands. Let's build this step by step, from connection methods to task handover and stopping conditions.

Assign Work to Codex While Keeping Claude Open

There is a way to pass requests from Claude Code to Codex without pasting previous answers into another AI. It is the "Codex plugin for Claude Code" released by OpenAI.

According to official documentation, it supports uses such as:

• Reviews inspecting current changes

• Delegation of investigation or fixes

• Conversation handovers

This article covers the procedure for using it from a local environment's Claude Code, based on official documents verified on October 16, 2026.

Prerequisites

• An environment where Claude Code is available

• Git

• Node.js (official requirement: 18.18 or later)

• A ChatGPT account authenticated with Codex, or an OpenAI API key

The plugin calls your local Codex. Connecting does not mean Codex runs on Claude's usage quota; Codex usage consumes Codex's own quota.

Also, although this setup handles local files, AI inference does not necessarily complete entirely within your PC. Start with a practice folder containing no confidential information.

Install the Plugin

In the Claude Code input field, execute the following commands one by one from top to bottom. These are operations to add plugins within Claude Code, not commands to paste into a regular terminal.

1/plugin marketplace add openai/codex-plugin-cc
2/plugin install codex@openai-codex
3/reload-plugins
4/codex:setup

The final /codex:setup allows you to check Codex installation and authentication status. If Codex is not found and npm is available, guidance for installation will appear; review the content and proceed accordingly.

If unauthenticated, run codex login in the terminal and follow the prompts.

On Windows, ensure the environment running Claude and the environment where Codex was installed are not separate. Avoid reinstalling repeatedly just because it says "not found."

Try Review First

Start with a review that doesn't rewrite code. Prepare a small change in a Git-managed practice project and execute:

1/codex:review --background

• Check progress: /codex:status

• Check completed results: /codex:result

When multiple requests are active, specify the displayed Job ID to avoid mixing up results.

Amazon's Public Samples Are Useful for Task Division

For role division reference, look at development samples published by AWS, Amazon's cloud business unit. On GitHub's aws-samples, there are two relevant repositories:

• sample-codex-agent-team (for Codex)

• sample-claude-code-agent-team (for Claude Code)

The Codex version has six roles:

Deciding how to build a registration screen versus considering scalability, maintenance costs, etc., are different jobs. Separating feature implementation from operational consultation makes questions to specific agents more concrete.

Lightweight review isn't for casually handling risky changes. It's a division method to avoid subjecting low-risk tasks like document edits or mechanical replacements to heavy inspections every time.

Task handover methods differ between the two samples:

• Claude Code version: Agents fetch tasks from a shared task list (uses experimental agent teams, requires additional configuration)

• Codex version: Proceeds according to a work plan with divided responsibility files

These are separate samples. They do not automatically merge into one team if both are installed.

Also, the Codex version includes model specifications assuming unpublished connection settings. The sample itself states these won't work directly on everyone's accounts. Rather than copying wholesale into critical company projects, adopt only the role division logic and adapt it to your usable environment.

This article starts with a small structure where Claude Code acts as the interface, passing limited implementation and inspection tasks to Codex.

Note: This is a unique operational example referencing public samples. It is not a product guaranteeing AWS integration of Claude and Codex, nor a report of measured behavior.

Align the Meaning of "Saveable" Before Building

When you can't describe what you want to build in detail, don't start implementation immediately. First, have Claude organize confirmation items. You don't need to know all technical terms; just convert them into questions you can answer.

I want to build a personal case management app. Please first organize necessary specifications and ask me one question at a time about decisions needed. For technical choices, briefly explain the impact on users and reasons for recommendation. Do not start implementation until I approve.

For example, regarding saving: Is it enough if records persist in the same browser, or do you want sharing between smartphone and PC? These require completely different mechanisms. Silently choosing one causes rework later.

For this exercise, narrow the scope:

• In Scope: Use on the same PC/browser, records persist after reload

• Out of Scope: Multi-device sync, login, external publishing, customer real data

Define completion criteria by operation results, not "easy to use":

• Can register cases

• Sorted by deadline

• Can change status

• Empty registration shows reason

• Content persists after reload

Save Specs and Task Requests to Files

Save decided content to docs/spec.md as a specification everyone references. Filenames here are examples; they aren't auto-distributed to all AIs, so specify "read this" with each request.

Save decided specs, completion criteria, and out-of-scope features to docs/spec.md. Do not write undecided matters as confirmed. Separate items requiring implementation stops from those proceeding with temporary settings.

Next, summarize task requests for implementers in docs/tasks.md. Just naming the task isn't enough. Include reading materials, editable files, non-editable parts, verification methods, and expected outputs.

Break specs into implementable units. Write assigned files, prerequisite tasks, and verification methods in docs/tasks.md. Decide shared items between UI and storage logic beforehand. Do not plan for two agents to edit the same file simultaneously.

Show Both AIs the Same Spec

Continuous instructions can be written in CLAUDE.md for Claude and AGENTS.md for Codex. These are documented mechanisms. However, don't assume one file works identically for the other. Reference the same spec file from both.

Keep instructions short:

• Location of spec file

• Do not make changes outside requests

Duplicating specs risks one side becoming outdated. This avoids that.

Separate Workspaces Before Parallel Tasks

Multiple AIs working seems faster, but rewriting the same file with different policies just creates cleanup work for humans.

For initial parallel work, pair "UI builder" with "test planner." Implementing UI and storage separately before format is finalized increases mismatch issues.

Use Git Worktree to Separate Folders

Git worktree is useful here. It's an official Git feature allowing separate working folders for the same project with different changes.

Before creating, ensure specs and base are committed to Git. Uncommitted draft files may not carry over to new locations. Verify branch names and target folders are unused.

1git worktree add -b feature/ui ../case-app-ui
2git worktree add -b feature/storage ../case-app-storage
3git worktree list

Three cautions:

1. Creating folders doesn't change AI workspace. Open separate sessions in each directory and verify location/branch before starting.

1. Plugins use the caller's environment. Connecting Claude/Codex doesn't auto-isolate. Initially, stick to "one editor per location."

1. Worktrees mainly isolate files. Shared databases or ports cause conflicts. Separate test storage/ports or sequence startups.

Limit Concurrent Tasks in Codex

To increase sub-agents in Codex, limit concurrent threads. Sub-agents receive limited tasks from parent AI. Current config in .codex/config.toml:

1[agents]
2enabled = true
3max_concurrent_threads_per_session = 2

• Don't duplicate entries

• Use only in trusted projects (project settings load only in trusted contexts)

• Limit applies to "concurrent threads excluding main agent in that session," not total across Claude/sessions.

AWS sample's 14 threads is just their choice. Not a mandate. Their max_threads is a legacy alias; use current names.

Don't Explain Implementers From Scratch Every Time

In Codex, define custom agents via TOML files in .codex/agents. Create task-builder.toml with necessary conditions:

1name = "task-builder"
2description = "Implement only assigned scope from confirmed specs"
3developer_instructions = """
4Read docs/spec.md and docs/tasks.md first.
5Implement only assigned scope; stop and report if spec changes needed.
6Do not revert other agents' changes, read secrets, or publish externally.
7Return changed files, executed tests, results, and unconfirmed items.
8"""

Avoid fixing model names here. Default inherits parent settings. Public sample models may not be available on your contract; hardcoding unavailable names stops startup before role description.

After placing file, verify recognition in new Codex session and delegate small task. If requesting from Claude, specify using task-builder in Codex.

Request Codex to delegate only storage logic from docs/tasks.md to task-builder. Verify agent recognition and actual folder before starting. If unavailable, report instead of silently switching methods.

Note: Writing "do not change" differs from removing write permissions. Official docs state Codex child agents inherit parent permissions (sandbox settings). Role name "reviewer" doesn't create safe read-only environments.

Switch Agents If Fixes Repeat

If AI says "found the cause" but same operation fails again, record what changed/didn't rather than rushing next fix. Easier to hand off.

Official plugin has rescue entry for delegating investigation/fixes to Codex. Despite name, it's for scoped tasks, not just bugs.

Explicitly Mark Investigation as Read-Only

For cause analysis only, clearly state no writes. Internal procedures default rescue to writable unless specified. Keep investigation/fix distinct.

1/codex:rescue --fresh Investigate why registration disappears on reload, read-only. Compare docs/spec.md and code. Return reproduction steps, evidence-based causes, needed checks. Do not modify files.

--fresh starts new request; --resume continues previous (prompts if omitted). Specify permissions when resuming. If moving to fix, define scope.

1/codex:rescue --resume Fix only storage logic with minimal changes based on confirmed cause. Do not change UI/specs. Show failing test before and result after.

Transfer Entire Conversation with Transfer

• Pass task only → rescue

• Move conversation to Codex → transfer

1/codex:transfer

Official docs: Creates Codex thread continuing current Claude Code conversation, showing resume command. Update Codex if unsupported.

Transferring conversation ≠ transferring PC state. Unsaved changes, auth, running apps don't move. Verify files/status at destination.

Verify With Another AI After "Done"

Implementer testing is helpful, but if they misunderstood specs, passing tests don't match desired behavior.

Give inspectors human-verified specs and actual changes, not implementer explanations. Don't share "perfectly fixed" evaluations; let them independently check compliance.

Independently compare docs/spec.md and actual changes. Identify unmet completion criteria with evidence. Do not assume implementer self-evaluation. Separate reproducible issues, potential concerns, and unverified items. Do not fix now.

Pair opposites:

• Claude implemented → Add Codex normal review as separate check

• Codex implemented → Ask Claude to inspect, optionally add new Codex review

Normal vs Adversarial Review

Call normal review with /codex:review. Compare branch to main:

1/codex:review --base main

Use actual base branch if no main. Don't touch changes during review.

Note: Normal review doesn't accept free-text focus instructions like "check storage only." Official spec prohibits priority directives. To challenge design assumptions or specific risks, use adversarial-review.

1/codex:adversarial-review --background Check if save failures display as success, if editing from two tabs loses records, verify current design assumptions.

This isn't harsh tone; it challenges chosen approaches/assumptions. Both reviews identify issues, don't fix code. Confirm results, then delegate fixes separately.

Organize findings with applicable completion criteria, user impact, verification methods. Do not auto-fix issues requiring spec changes; present options/differences to human.

Skip Review Gate Initially

Automation option: "Review gate" inserts Codex review whenever Claude finishes response. Enable with /codex:setup --enable-review-gate.

Warning: Official docs note risk of long fix loops consuming quotas rapidly between Claude/Codex.

Start with manual reviews to understand findings. Disable when away. Stop with /codex:setup --disable-review-gate and check pending requests.

Preserve Successful Requests for Next Tasks

Instead of repasting long instructions, save successful workflows. Skills allow storing task procedures in files for reuse.

Anthropic docs: Place procedures in .claude/skills. Create team-brief folder with SKILL.md containing pre-handover checks.

1---
2name: team-brief
3description: Organize scope and verification from specs
4disable-model-invocation: true
5---
6Read docs/spec.md and docs/tasks.md, targeting only current changes.
7Organize scope, forbidden changes, prerequisites, completion criteria, verification.
8Create request texts for agents, leaving undecided items for human confirmation.
9Do not change code, publish externally, or launch Codex in this procedure.

Invoke in Claude Code:

1/team-brief Want to add sorting by deadline

Custom command, not standard. disable-model-invocation: true ensures human triggers timing. Claude won't auto-start. Procedures don't force AI launches/inspections; try "reuse preparation only" first.

Dynamic Workflows for Large Tasks

For larger scopes, Claude Code offers Dynamic workflows (announced May 2026), scripting multiple agents. Available in paid plans/API.

• Normal chat: Claude chooses next task each time

• Dynamic workflows: Script branches/result collection, rerunnable

Example: Investigate save failures, input checks, layout breaks across multiple screens separately, cross-reference findings. Don't launch massive agents from small app; consider when applying same checks broadly.

Create Dynamic workflow investigating split screens, verifying findings with separate agents. Present targets, agent count, exit conditions first. No code changes; execute small scope after approval.

Tips:

• Enable via /config in Pro plan

• Monitor progress/usage with /workflows, stop anytime

• Choose scale (small etc.) in /config; official docs call these estimates, not strict limits. Don't assume guaranteed agent counts.

This runs Claude-side agents. Codex doesn't auto-join. Use for Claude internal investigation/verification first; treat Codex delegation as separate stage.

Run Case Management App End-to-End

Connect components into one app build. Below is explanatory dev example, not completed experience report; verify in your environment.

Build Target

• Fields: Case name, deadline, status, notes

• Status: Not started / In progress / Completed

• Search by case name

• View incomplete cases sorted by deadline

Initial Request

Pass to Claude. Target new practice folder, not existing critical projects.

Build personal case management app in practice folder. First confirm environment and specs. Include registration/editing/search/sorting/persistence for name, deadline, status, notes. Exclude login, sync, external publishing.

Candidate storage: localStorage. No multi-device sync/backup; clearing browser data deletes records. Don't put valuable production info.

Build Base, Define Shared Parts

Single agent builds base. Verify app launches, empty screen displays. Commit specs/base to Git before separating workspaces if needed.

• Give UI agent: Display fields, action mappings

• Give Storage agent: Record format, read/add/update methods, failure handling

Don't let either invent field names. If status field is status, both use it. Don't change one side to state for ease; route shared changes back to Claude for adjustment.

Implementation Request to Codex

Specify writable locations AND required evidence outputs.

1/codex:rescue --fresh Read docs/spec.md and docs/tasks.md. Implement only assigned storage logic and tests. Return changed files, commands, test results, unconfirmed items. Stop and report if spec changes or other agent edits needed.

Meanwhile, Claude doesn't modify same files sideways. Focus on completion checks/test data prep; decide next steps after results return.

Prepare Verification Data

• Yesterday deadline, "Not started"

• Today deadline, "In progress"

• Next week deadline, "Completed"

• Multiple same-deadline cases

• Long case names

Enables concrete sorting/display checks.

Document detailed rules in specs:

• Sorting: Registration order for same deadlines

• Empty fields: Name/deadline required; notes optional. Display missing fields.

• Dates: Define date switch assumption. Timezone/time handling causing day shifts makes app unusable despite neat appearance.

Pre-defining rules prevents inconsistent post-implementation checks.

Integrate and Test

Once implementations ready, have Claude read change lists/test results, confirm integration. If using worktrees, collect changes into single verification branch. Re-run individual-passed tests after integration.

Use Playwright for UI automation. Current guides offer CLI/Skills for AI agents; MCP isn't sole method.

Separate "AI browser control mechanism" from "repeatable tests." Use Playwright Test for re-runnable registration-to-reload flows.

Create Playwright Tests verifying registration, empty rejection, search, status change, deadline sorting, persistence. Separate launch config/test data. Do not alter app behavior/completion criteria to pass tests.

Setup for new practice project:

1npm init playwright@latest

If already installed, verify existing launch/test configs before adding.

Ensure browsers installed, configure app launch, then run:

1npx playwright test
2npx playwright show-report

Crucial: Don't treat zero-found or all-skipped tests as "pass."

On failure, isolate cause: Storage bug or test looking for nonexistent button? Don't delete tests to go green; decide fix target against original specs.

Final Human Verification

Check visuals manually. Hidden text? Easy to find near-deadline cases? Passing test reports don't guarantee UX.

Receive four items from Claude, not long logs:

• Launch method

• Verified behaviors

• Remaining constraints

• Next fix candidates

Register one item yourself, reload, verify persistence. Then mark complete.

Where to Stop Persistent Fixing

As team scope expands, define endings. Are we looping same bug or solving sequential issues? Unclear state hinders further instructions.

Set Stopping Criteria

Use "max two fixes per issue" as guideline. Not official recommendation, but operational rule to return judgment to humans when stuck.

If same bug remains unfixed after two attempts, stop additional changes. Summarize tried actions, changes made, remaining symptoms, needed decisions. Do not expand to unrelated features.

Instructions alone don't guarantee stops. Monitor usage, cancel unnecessary background requests with /codex:cancel. Verify agents actually stopped.

Track Costs Separately

ChatGPT-authenticated Codex quotas differ from API-key pricing. Parallel agents consume inference/tool resources.

Don't route minor text edits through both AIs/large reviews.

Categorize:

• Solo-completable tasks

• Tasks needing second perspective

• Independently parallelizable tasks

Helps decide effort/quota allocation.

Watch Outdated Model Specs

Old model specs cause failures. OpenAI update: GPT-5.5 ended for ChatGPT-authenticated Codex on Oct 15, 2026 (JST). API-key auth unaffected.

Update old specs/role files to currently available models. Verify selectable models and accepted reasoning settings, not just rename.

Check Permissions and Hooks

Claude permissions don't always propagate to Codex. Verify execution rights both sides. Practice without production credentials. Require separate approval for deletion, external publishing, billing.

Inspect hooks in public samples before use. Hooks auto-execute at set times; see what actually runs, not just convenient additions.

Measuring "Built Quickly"

Don't compare generation time alone.

• Your re-explanation count

• Integration/fix time

• Remaining defects vs completion criteria

Include these to decide if same division works next time.

Start With Small Weekly Tools

Non-engineers find easiest wins where they judge correctness themselves.

• Inquiry tracking

• Order deadline checks

• CSV formatting with consistent sorts

Start with describable use cases.

Want near-deadlines first? Remove completed? Alert on missing inputs? Daily needs become AI completion criteria.

No need to master coding first; build prototypes based on conditions, use, fix. Note: Customer data systems or public services need professional validation beyond prototype success.

Initial team suffices:

1. Claude organizes specs

1. Codex executes one task

1. Verify returned results with different perspective

Save useful requests/verification methods to avoid full re-explanations next app.

Thanks for reading.

LINE Open Chat "Niku's AI Speed Strategy" distributes free 8-point set.

• Codex/Claude Code intro guide

• Copy-paste instructions

• Quick reference tables

• 50 mini apps

• 50 image prompts

• yomiyasu installation

• Title generator

• X monetization flow/amounts

Get here 👇 https://x.gd/VtPmw