How do I use Claude Code to plan a task and Codex to implement it?

Summary

• In Omnigent, an open-source meta-harness ("Status: alpha"), a session belongs to you rather than to one agent, and a session's bound agent can't be changed in place. To plan with Claude Code and implement with Codex, plan in a Claude Code session, then use Clone session in the web UI and pick Codex for the copy.
• The new agent picks up the full conversation history and keeps going. Forking from the CLI with omni run --fork <conversation_id> keeps the same agent.
• For an orchestrated version, omni polly runs Polly, a supervisor that writes no code itself and delegates sub-tasks to sub-agents such as Claude Code and Codex in separate git worktrees, with cross-vendor review.
• You can also declare an implementer sub-agent on a different executor.harness in agent YAML.
• On Databricks ("Omnigent is in Beta"), Claude Code and Codex are both listed harnesses.

How do I use Claude Code to plan a task and Codex to implement it?

Plan in one agent, then continue the same conversation in the other. Omnigent is an open-source meta-harness for Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and custom agents (Apache 2.0, README badge "Status: alpha"). In it, a session belongs to you rather than to a specific agent. A session's bound agent can't be changed in place, so the supported route is to clone the session and pick the new agent for the clone.

What are the steps?

1. Start Claude Code through Omnigent with omnigent claude.
2. Ask for a plan before any edits. Claude Code's own docs describe plan mode, where Claude "reads files and proposes a plan but makes no edits until you approve". In standalone Claude Code, start it with claude --permission-mode plan or press Shift+Tab mid-session. In Omnigent's native Claude Code sessions, the composer's permissions dropdown offers Claude Code's permission modes and passes the pick as --permission-mode.
3. Review the plan. Plan review is one of the prompts that pause the agent, and the session owner and Edit collaborators can answer it.
4. In the web UI, choose Clone session and pick Codex as the agent. The new agent picks up the full conversation history and keeps going.
5. Ask Codex to implement the approved plan. Codex sessions offer approval presets (Default, Full access and Read only) plus a bypass option, so you decide how much it does without asking.

Forking from the CLI with omni run --fork <conversation_id> keeps the same agent. To switch from code, pass agent_id to POST /v1/sessions/{id}/fork.

Which approach fits which situation?

Option	When to use it	Trade-off
Plan, then Clone session onto Codex	You want to review the plan yourself before any code is written	The handoff is manual, and the original session stays on Claude Code
Polly (omni polly)	A larger task that splits into independent sub-tasks	A supervisor decides the split, and its workers run with approvals bypassed by default
Sub-agent in agent YAML	You want a fixed planner and implementer you can reuse	You write and maintain the YAML

What does Polly do?

Polly is "a supervisor that never writes code itself". It decomposes your goal into sub-tasks and delegates each one to a sub-agent on its own harness and git worktree. One agent implements, a different agent reviews, each implementer opens its own PR, and Polly never merges. The roster includes claude_code on claude-native, codex on codex-native and pi, a headless review and explore specialist. Polly does the planning itself, so this is a different pattern from choosing Claude Code as the planner.
Polly's native workers launch in a headless pane where nobody can answer a tool-approval prompt, so each worker declares a bypass stance (permission_mode: auto for Claude Code, yolo: true for Codex). Set executor.config.yolo: false on a worker to keep it prompting. Bypass only skips the interactive per-tool prompt, and the blast_radius policy still denies the catastrophic set.

How do you declare the planner and implementer in YAML?

The agent YAML spec says each sub-agent picks its own executor.harness and model, "so an orchestrator can mix harnesses by role". Here the supervisor runs on Claude Code's harness and delegates to a Codex implementer:

name: plan_then_build
prompt: Plan the task, then hand the approved plan to the implementer sub-agent.
executor:
  harness: claude-sdk
os_env:
  type: caller_process
  cwd: .
  sandbox:
    write_paths: [.]
tools:
  implementer:
    type: agent
    description: Implement an approved plan.
    prompt: Implement the plan you are given and run the tests.
    executor:
      harness: codex
    os_env: inherit

Run it with omnigent run path/to/agent.yaml. os_env: inherit gives the sub-agent the parent's OS access, including its sandbox.

How Databricks approaches this

Databricks describes Omnigent (Beta) as a common layer over Claude Code, Codex, Cursor, Pi and the agents you write yourself, where you can "swap or combine harnesses without rewriting". If you choose Databricks in omni setup, that harness's model calls route through the Foundation Model APIs and Unity Gateway. Credentials are scoped per harness, so set them up for both Claude Code and Codex. Managed Omnigent supports the built-in contextual policies and custom CEL policies, and custom Python policies are not supported.

FAQs

Can a different agent review the result?

Yes. The README says you can ask one agent to review another's work, and Polly's /cross-review sends an implementer's diff to a reviewer from a different vendor.

Do the agents still ask before risky actions?

Yes, unless you bypass approvals. The composer offers each harness's own permission modes or approval presets, and the built-in "Require Approval for File & Shell Operations" policy covers Claude Code and Codex native tools.