Show original
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.

AI translation
― Design is passed to Claude, implementation is passed to Codex
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
This is a continuation of the "Claude Code Environment" series from Claude Codeの記憶を4層に分けた話. This time, I'll write about dividing roles between Claude Code and Codex CLI within a single Mac.
The trigger was simple: when running the main session with a lightweight model, I felt it was wasteful to burn through tokens on long typing during implementation. Design and review benefit from model intelligence, but the process of simply writing predetermined implementations should be delegated elsewhere. So I settled on delegating implementation to Codex, while keeping design, research, and review on the Claude side.
I've documented this explicitly in 分担はCLAUDE.md. The key points are:
| Process | Owner | Reason |
|---|---|---|
| Design, codebase research, planning | Claude (main) | Requires context understanding and tradeoff judgment |
| Implementation, refactoring, test generation | Codex | Routine, large-scale, repetitive work—delegate to the typing side |
| Code review | Both | Bring in different engines' perspectives to improve quality |
The key point is not delegating everything. For implementations with high difficulty or heavy design decisions, it's faster and more accurate for the main session (which holds context) to write directly. Delegation is limited strictly to the process of "mass-producing predetermined work."
The axis is separating processes that require model intelligence (design, review) from those that require volume over intelligence (routine implementation). It's not "two AIs means parallel speed," but rather "choosing which tasks deserve the smarter seat."
Codex comes in as a CLI (codex-cli 0.135.0). Delegation is done via non-interactive headless execution.
# 実装・タスク委譲(@file でファイル参照可)
timeout 600 codex exec --skip-git-repo-check "<依頼内容>" </dev/null
# コードレビュー(現在のリポに対して実行)
codex exec review </dev/nullThere are three subtle but effective points:
</dev/null. Without closing it, Codex waits for interactive input and freezes, wasting time until timeout.timeout. Headless AI processes sometimes don't terminate. Setting OS-level limits prevents hung processes from accumulating.--skip-git-repo-check. Necessary when running in directories outside git repos. Without it, repo detection will reject the execution.Codex is installed under nvm. During interactive Claude sessions, Bash has nvm default loaded, so codex works as-is. But with raw zsh or via cron, command not found can happen. In that case, use the full path.
/Users/<you>/.nvm/versions/node/v24.13.0/bin/codex exec ...When running unattended from launchd or cron, nvm isn't in the minimal PATH, so you'll always hit this snag. Full path specification is reliable.
The actual operational flow looks like this:
codex exec for implementationcodex exec reviewSeparating steps 3 and 4 across different engines is subtly effective. When the same model reviews its own work, reviews tend to be lenient. But having Codex write and Codex review—or having Claude review—separates writer from reviewer, improving quality.
For long delegations, I pass tasks, handoffs, and state via files. Conversation context is ephemeral, so dropping state to disk makes resumption and verification easier. When running isolated in worktrees, I write branch and worktree path to a status file.
# Status
- State: running
- Updated: 2026-06-17T...
- Branch: feat/...
- Worktree: `/path/to/worktree`This follows the same principle as 記憶を4層に分けた話: place the authoritative state outside volatile conversation. Whether collaborating or maintaining long-term memory, the principle works the same.
</dev/null causes Codex to freeze waiting for interaction → Always close stdincodex: command not found → It's under nvm, so full path is essential--skip-git-repo-checkcodex exec --skip-git-repo-check "..." </dev/null with timeout for non-interactive executionNext time, I'll write about mechanically preventing secrets leakage right before push—the hook story in pre-pushガードでAPIキーと誤pushを止める.
Lily (@bokuwalily) — Individual developer. Building automation infrastructure with Claude Code while mass-producing iOS apps and web services
◼︎ Apps I've made are summarized at **ポートフォリオ**📱
◼︎ New releases and development behind-the-scenes on X **@bokuwalily**🐦
◼︎ OSS: **github.com/bokuwalily**🐙
Your ❤️ and shares are my motivation!
Claude Codeの記憶を4層に分けた話から続く「Claude Code環境」シリーズです。今回は、1台のMacの中でClaude CodeとCodex CLIを役割分担させる話を書きます。
きっかけは単純で、メインセッションを軽量モデルで回しているとき、実装の長いタイピングでトークンを溶かすのがもったいないと感じたからです。設計やレビューはモデルの賢さが効くけれど、決まった実装をひたすら書く工程は別プロセスに逃がしたい。そこで実装をCodexに委譲し、設計・リサーチ・レビューはClaude側に残す形に落ち着きました。
分担はCLAUDE.mdに明文化しています。要点はこうです。
工程担当理由設計・コードベースのリサーチ・計画Claude(メイン)文脈の理解とトレードオフ判断が要る実装・リファクタ・テスト生成Codex定型・大規模・反復はタイピング側に逃がすコードレビュー両方別エンジンの目を入れて品質を上げる
ポイントは「全部委譲しない」ことです。実装難易度が高い、あるいは重い設計判断を伴う実装は、文脈を持っているメインセッションが直接書いた方が速くて正確です。委譲はあくまで「決まったものを量産する」工程に限定します。
モデルの賢さが要る工程(設計・レビュー)と、賢さより量が要る工程(定型実装)を分けるのが軸です。「AIが2ついるから並列で速くなる」ではなく、「高い席に座らせる作業を選ぶ」発想です。
CodexはCLI(codex-cli 0.135.0)として入っています。委譲は非対話のヘッドレス実行で投げます。
# 実装・タスク委譲(@file でファイル参照可)
timeout 600 codex exec --skip-git-repo-check "<依頼内容>" </dev/null
# コードレビュー(現在のリポに対して実行)
codex exec review </dev/null細かいけれど効くポイントが3つあります。
</dev/null で stdin を閉じる。閉じないとCodexが対話入力を待ってフリーズし、timeout まで無駄に張り付きます。timeout で囲う。ヘッドレスのAIプロセスは、たまに終わらない。OS側で刈れるようにしておくと、張り付いたプロセスが溜まりません。--skip-git-repo-check。gitリポ外のディレクトリで実行するときに必要。これが無いとリポ判定で弾かれます。Codexは nvm 配下にインストールされています。対話中のClaudeのBashは nvm default をロード済みなので codex がそのまま通りますが、素のzshやcron経由だと command not found になることがあります。そのときはフルパスで叩きます。
/Users/<you>/.nvm/versions/node/v24.13.0/bin/codex exec ...launchdやcronから無人で回す場合、最小PATHにnvmは入っていないので、ここで必ず躓きます。フルパス指定が確実です。
実際の運用フローはこうなっています。
codex exec に具体的なタスクを投げて実装させるcodex exec review でコードレビュー3と4を別エンジンに分けるのが地味に効きます。同じモデルが「書いた本人」としてレビューすると甘くなりがちですが、Codexに書かせてCodexにレビューさせる/あるいはClaudeがレビューする、と書き手とレビュアーを分離できます。
長い委譲では、タスク・引き継ぎ・状態をファイルで渡すようにしています。会話の文脈は揮発するので、状態をディスクに落とすと再開や検証が楽になります。worktreeで隔離して走らせるときは、ステータスファイルにブランチとworktreeパスを書き出します。
# Status
- State: running
- Updated: 2026-06-17T...
- Branch: feat/...
- Worktree: `/path/to/worktree`これは記憶を4層に分けた話と同じ思想です。揮発する会話の外に、状態の正本を置く。協業でも長期記憶でも、効く原則は同じでした。
</dev/null 忘れでCodexが対話待ちフリーズ → stdinは必ず閉じるcodex: command not found → nvm配下なのでフルパス必須--skip-git-repo-checkcodex exec --skip-git-repo-check "..." </dev/null を timeout で囲う非対話実行次回は、その push の直前で秘密情報の流出を機械的に止めるフックの話 ―― pre-pushガードでAPIキーと誤pushを止めるを書きます。
Lily(@bokuwalily)― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています
◼︎作ったアプリは **ポートフォリオ** にまとめています📱
◼︎新着・開発の裏側は X **@bokuwalily** で発信しています🐦
◼︎OSS: **github.com/bokuwalily**🐙
皆さんの ❤️ やシェアが励みになります!