Writing
Running Claude Code and Codex in parallel
2026-08-30
Most people who run Claude Code or Codex seriously hit the same wall: the agents scale, your attention doesn’t.
Most people who run Claude Code or Codex seriously hit the same wall: the agents scale, your attention doesn’t.
You go from “this is fast” to “I am tab-switching babysitter for eight terminals” in about a week.
This piece compares two ways to run Claude Code and Codex in parallel using git worktree: manual prompt juggling vs structured orchestration with an agent manager like Maxxwell.
It assumes you’re already comfortable with git and running agents locally.
Git worktrees are the isolation primitive
Parallel agent work without isolation is how you get silent conflicts and mystery test failures.
Git worktrees are the shared abstraction everyone has settled on:
git worktree lets one repo maintain multiple checked-out working trees.- Each worktree has its own branch and filesystem path, but shares the same
.git metadata. - Claude Code, Codex, ctx, and others all document worktrees as the safe way to run concurrent sessions.
Basic pattern:
# In your main repo
$ git worktree add ../feature-auth feature/auth
$ git worktree add ../feature-search feature/search
# Now you have:
# repo/ -> main branch
# feature-auth/ -> feature/auth branch
# feature-search/ -> feature/search branch
From here you can:
- Attach Claude Code to
feature-auth/ and Codex to feature-search/. - Run agents in parallel without them touching the same files.
Worktrees are inherently parallel-friendly: git supports zero or more linked worktrees per repo, and each is just another directory with a branch checked out.
Manual prompt juggling: simple, but attention-bound
The default for most devs is manual orchestration:
- Open multiple terminals or IDE sessions.
- Point each at its own worktree.
- Manually prompt Claude Code or Codex in each.
For example, using Claude Code’s CLI plus Codex in another shell:
# Session 1: Claude Code on auth worktree
$ cd ../feature-auth
$ claude-code
# Session 2: Codex on search worktree
$ cd ../feature-search
$ codex
You then:
- Type briefs per session: “Implement OAuth2 login”, “Add type-ahead search”.
- Answer questions as they come in.
- Watch logs to see who is stuck.
Where manual control is actually fine
Manual control still makes sense for smaller, supervised work:
- Single feature, high risk: touching auth, billing, or critical infra where you want to see every diff.
- Exploratory refactors: you’re iterating on design and expect to pivot mid-stream.
- One-off tasks: “write this migration”, “clean up this file”.
Anthropic’s docs call this synchronous terminal/editor work: you get fine-grained control, but burn attention the whole time. OpenAI’s guidance is similar: for most work, start with “Ask for approval”.
Manual is good when:
- Latency is low and tasks are short.
- The main risk is correctness, not throughput.
- You’re actively watching the agent and steering often.
The manual ceiling
Manual breaks down once you try to run agents truly in parallel:
- Context switching: A task-interruption study across 4,910 tasks showed contextual factors (switching project, repo, or problem) drive disruptiveness more than task details.
- Attention bottleneck: Google’s DORA 2025 report says 90% of devs use AI, median 2 hours/day, but Stack Overflow’s 2025 survey shows 46% distrust AI output and only 3% “highly trust” it. So you watch more, not less.
- Coordination tax: Cortex’s 2024 report found 58% of devs lose >5 hours/week to unproductive work; gathering context and waiting on approvals are top leaks at 26% each.
In practice, that looks like:
- Eight sessions open; you are the slowest part.
- No way to see which session is stuck vs just slow.
- One agent confidently building the wrong thing for 20 minutes.
Worktrees solved concurrency for git. They did nothing for your ability to see and route what the agents are doing.
Structured orchestration: one brain above many agents
The industry is converging on an orchestration layer that sits above individual agents:
- Claude Code has Agent View for background sessions.
- Codex surfaces subagent threads above the composer and collects their results.
- Tools like The Cog, Helmor, ctx, Herd, CommandSlate all offer some version of a multi-agent IDE.
The pattern is:
- You describe work once at the top.
- A system creates and manages agent sessions, often across worktrees.
- It routes tasks and reports progress back to you.
Our pillar guide, “AI coding agent orchestration: the complete guide for multi-agent development”, goes deep on this. Here we stay concrete on Claude Code, Codex, git worktrees, and an agent manager like Maxxwell.
A concrete git worktree workflow for parallel Claude + Codex
Say you want to build three features:
- Auth (Claude Code)
- Search (Codex)
- Analytics (either)
Set up worktrees:
$ cd repo
$ git worktree add ../auth feature/auth
$ git worktree add ../search feature/search
$ git worktree add ../analytics feature/analytics
Launch agents:
# Auth with Claude Code
$ cd ../auth
$ claude-code
# Search with Codex
$ cd ../search
$ codex
# Analytics, your choice
$ cd ../analytics
$ claude-code # or codex
Now the question is how you orchestrate these three sessions.
DIY orchestration with scripts and discipline
One route is to build your own thin orchestration on top of this:
- A tmux layout with panes per worktree.
- A shell alias to list worktrees and statuses.
- A personal checklist for “what’s running where”.
Example: crude status check via git and a convention:
$ git worktree list
repo 0123abc [main]
auth 4567def [feature/auth]
search 89ab012 [feature/search]
analytics 3456ghi [feature/analytics]
You then rely on:
- Logs in each terminal.
- Your memory for “Claude is on auth, Codex is on search”.
This works, but every coordination decision still goes through you.
Orchestration with Maxxwell: agent-of-agents
Maxxwell is an agent that manages your coding agents. It does not replace Claude Code or Codex; it sits above them.
With Maxxwell in the same setup:
- Each Claude/Codex session is a worker, running in a real terminal attached to a worktree.
- All workers appear in one window, each marked with state:
working, idle, waiting on you, needs sign-in, blocked, done, dead, not heard from, plus possibly stalled overlay.
- On top sits an orchestrator seat, which is itself a coding agent session started from your written brief.
You:
- Brief the orchestrator in natural language: “Auth in
../auth, search in ../search, analytics in ../analytics. Auth uses Claude Code, search uses Codex.” - Talk to it instead of twelve terminals.
- Get a return report of what landed, what it decided, and what needs your call.
Important constraints:
- Workers are your own unmodified tools (Claude Code, Codex, cursor-agent, etc.).
- Sessions are just terminals; you can attach and take over mid-sentence.
- Quitting Maxxwell detaches; it never kills sessions.
- Fleet controls draft rather than act: any control that would change the fleet writes a fully formed, unsent sentence into the composer. You stay the one who presses enter.
Maxxwell gives you orchestration without a hidden autopilot:
- It does not automatically detect drift and re-aim sessions.
- It does not automatically recycle context or restart stopped work.
- It does not run periodic goal checks.
You still decide; the system just makes that decision cheap.
When automation improves throughput and reliability
You don’t need structured orchestration for every task. You probably do need it once you cross three or four concurrent agents.
Patterns where automation helps:
- Parallelizable feature work
- Multiple independent branches: auth, search, analytics, emails.
- Each mapped to a worktree and agent.
- Claude’s Agent View and Codex’s subagents are explicitly built for this.
- Team environments
- Several developers running agents at once.
- Coordination cost is suddenly visible.
In these cases, an orchestrator that:
- Knows each session’s state.
- Can draft task routing among agents for you to send.
- Can surface “possibly stalled” sessions.
…gives you higher throughput than manual prompt juggling, while keeping human review in the loop.
Human review remains non-negotiable:
- Stack Overflow data shows a trust gap: nearly half of devs distrust AI output.
- OpenAI’s permission model keeps “Ask for approval” as the default.
An orchestrator should make review easier, not optional.
How Maxxwell differs from other orchestration tools
Brief landscape:
- The Cog: AI-native agent orchestration IDE, can spawn teams across multiple models.
- Helmor: local-first IDE, runs Claude Code and Codex side-by-side across worktrees.
- CommandSlate: thread-centric; dispatches tasks to agents on branches and returns pushed, merge-ready work.
- Herd: desktop app focused on monitoring many agents and shipping in parallel.
- ctx: isolates concurrent worktrees and runs an agent merge queue for conflict catching.
Maxxwell’s distinctives:
- Agent-of-agents, not another copilot: it manages Claude Code, Codex, Cursor, etc.; does not compete with them.
- Real terminals, not wrapped sandboxes: workers are normal sessions you already trust.
- Drafts rather than acts: nothing changes the fleet without you pressing enter.
- Local, no sign-up, no server: you bring your own Claude or ChatGPT/Codex access.
- Sessions outlive the app: quitting detaches; it never kills work.
If your DIY tmux scripts are mostly about keeping sessions visible and states straight, Maxxwell is essentially a turn-key version of that with an agent sitting on top.
Comparison: manual vs orchestrated Claude + Codex with worktrees
Here’s a condensed comparison for the same scenario: Claude Code on auth, Codex on search, analytics as a third lane.
Manual control is strongest for small, high-risk tasks, while structured orchestration wins once you run several agents in parallel across git worktrees.
Key differences:
- Setup
- Manual:
git worktree add + your own tmux / terminal layout. - Orchestrated: same worktrees, plus Maxxwell or another manager that knows each session.
- Visibility
- Manual: per-terminal logs and your memory.
- Orchestrated: one window, explicit session states, “possibly stalled” overlay.
- Routing work
- Manual: you decide, you prompt, you copy-paste context.
- Orchestrated: you brief once; orchestrator routes subtasks to Claude vs Codex, still drafting controls for you to send.
- Intervention
- Manual: attach to a terminal, type.
- Maxxwell: click into a worker’s real session, or send the drafted control.
- Risk profile
- Manual: low automation risk, high human fatigue risk.
- Orchestrated: lower fatigue, plus a live view of context pressure and task status; automation risk bounded by “person presses enter”.
Recommendation by use case
For most teams running Claude Code and Codex in parallel with git worktrees:
- Solo dev, 1-2 agents at a time
- Stick with manual.
- Use worktrees to isolate branches; your terminal discipline is enough.
- Power user, 3-6 agents in flight
- Move to structured orchestration.
- Claude’s Agent View and Codex subagents are a start.
- Add Maxxwell when you want one place to see all sessions and talk to an orchestrator instead of twelve terminals.
- Team with several people running agents
- Use git worktrees per feature and an orchestration surface.
- Your DIY tmux setup will eventually turn into a dashboard; at that point, Maxxwell or a similar tool is cheaper than maintaining your own.
If your pain sounds like “I have eight sessions open and I am the slowest part of this”, you’re past the manual ceiling. At that point, tying Claude Code and Codex to worktrees and letting an orchestrator manage them is the more stable path.
FAQ
How do I run Claude Code and Codex in parallel safely?
Use git worktree to create one worktree per independent feature or task. Attach Claude Code to one worktree and Codex to another. Avoid sharing a single working tree between agents to prevent file collisions.
When is manual control over agents enough?
Manual control is enough when you run one or two agents at a time on short, high-risk tasks. You’re watching outputs closely, and coordination overhead is low. For bigger parallel feature work, the attention cost grows faster than the benefit.
What does an orchestration layer actually do?
It:
- Tracks each agent session, often per worktree.
- Shows session state (working, idle, blocked, stalled, etc.).
- Helps route tasks between agents based on a higher-level brief.
- Centralizes reporting: what landed, what’s pending, what needs your decision.
Maxxwell does this while keeping agents in real terminals you can take over.
Does Maxxwell replace Claude Code or Codex?
No. Maxxwell is an agent that manages your coding agents. Claude Code, Codex, Cursor, and similar tools remain your workers. Maxxwell owns the layer above them: goals, visibility, and the handful of decisions that need a person.
How do I integrate orchestration with CI and main?
Keep each agent on its own worktree and branch. Land changes via normal git hygiene:
- Run tests in each worktree.
- Review diffs manually.
- Merge through your usual PR flow.
Tools like ctx add an agent merge queue; Maxxwell focuses on making the state of each session visible while leaving CI and merges in your existing pipeline.