Using Claude Code and Codex as Coding Subagents in OpenClaw

A popular question in the OpenClaw community: How do you effectively use Claude Code or Codex as coding subagents? Here's a synthesis of community wisdom and official guidance.

The Challenge

OpenClaw can spawn coding agents like Claude Code and Codex, but these tools have their own internal subagent systems. The question is: how do you orchestrate them effectively without creating chaos?

The Recommended Architecture

The cleanest approach uses OpenClaw as the task router, not the micro-manager:

1. OpenClaw (or a code-manager agent) decides which engine owns the task
2. The chosen engine uses its built-in subagents internally
3. OpenClaw sees one process per task, not the internal decomposition

This keeps orchestration simple while letting each tool do what it does best.

Routing Strategy: By Files, Not Task Description

Don't route based on vague task wording like "UI work" vs "backend work". Instead, route by what's actually being changed:

The Critical Rule: Shared File Ownership

Even with clean routing, you'll hit shared files—main.go, config files, routers. The solution:

Designate an integrator/owner for shared files (usually the backend/Codex side). The other agent proposes changes as instructions or diffs, not direct edits.

This prevents the nightmare of "two agents rewrote the same block differently."

Using the coding-agent Skill

OpenClaw includes a built-in coding-agent skill that handles the PTY/terminal complexities for you. Check skills/coding-agent/SKILL.md for details on spawning Claude Code or Codex instances programmatically.

Example Agent Instructions

Add this to your code-manager agent's AGENTS.md:

## Coding Task Routing

- UI/UX/frontend-heavy tasks → spawn Claude Code
- Backend/infra/general tasks → spawn Codex
- Shared files (`main.go`, routers, config) → Codex owns, Claude proposes diffs
- Mixed tasks → split into separate branches, merge sequentially

Cost Considerations

This architecture doesn't reduce model usage—internal subagents still consume tokens. The main savings come from:

• Avoiding terminal repaint noise feeding back into OpenClaw
• Cleaner context since each engine manages its own subtasks
• Fewer merge conflicts from proper file ownership

Key Takeaways

1. Let OpenClaw route tasks to the right engine
2. Let each engine use its own subagent system internally
3. Route by files being changed, not task description
4. Designate owners for shared/choke-point files
5. Use the coding-agent skill to handle PTY complexity

Based on a discussion in #help on the OpenClaw Discord. Thanks to the community members who contributed!