Running Claude Code and Codex Together in One Terminal

The honest answer is that different coding agents are good at different things.

Claude Code's reasoning shines on cross-file refactors and long-context reads. OpenAI Codex tends to be faster at mechanical edits and tool-heavy loops. OpenCode is the one you reach for when you want a permissive open-source option with custom model routing. Picking one forever is a false economy. Most real workflows want two of these running at once: one agent doing the careful work, another burning through the boilerplate, and you deciding who gets which task.

Running them side by side is harder than it sounds. Each tool has its own CLI, its own auth flow, its own startup incantation. You end up writing a shell script per project that launches claude in one window, codex in another, opencode in a third, with different environment variables for each. When you want to send a task to Codex from an editor macro, you have to translate "the Codex pane" into a specific tmux pane coordinate every time. When Codex finishes a task and you want to hand off to Claude, there is no mechanism for that beyond copy-paste.

One Config, Multiple Tools

initech's role system lets each agent declare its own launch command. Mixing tools is a two-line change:

# initech.yaml
agents:
  super:   { role: super }
  claude1: { role: engineer, tool: claude-code }
  codex1:  { role: engineer, tool: codex }
  open1:   { role: engineer, tool: opencode }

role_overrides:
  claude-code:
    command: "claude --model claude-opus-4-7"
  codex:
    command: "codex --model gpt-5-codex"
  opencode:
    command: "opencode --model grok-code-fast-1"

Run initech and you have three panes, each with a different agent, all addressable by name. Everything that works for one agent works for all of them: initech send codex1 "...", initech peek claude1, initech patrol. The role system docs cover the full syntax for per-role environment variables, working directories, and tool-specific flags.

Handing Off Between Tools

Because every agent speaks the same messaging CLI, handoffs compose. Claude does the design and leaves a TODO list; Codex executes the list. Here is what that looks like in practice:

# claude1 designs the refactor
$ initech send claude1 "plan the auth middleware refactor. Write the TODO list to /tmp/auth-plan.md"

# ...claude1 finishes, ready_for_qa on bead ini-91...

# You hand the TODO list to codex1
$ initech send codex1 "execute the TODO list in /tmp/auth-plan.md one item at a time. Commit after each."

# Watch both from one TUI
$ initech patrol --agent claude1 --agent codex1

The activity detector treats all three tools uniformly. initech reads each pane through a terminal emulator and maintains the same state machine regardless of which CLI is inside: thinking, streaming, idle, stuck. Live Mode rotates the grid to whichever agent most recently changed state, whether that is Claude about to ask for approval or Codex finishing a tool call.

Why This Beats a Shell Script

You could get 80% of this with a tmux bootstrap script and some aliases. The remaining 20% is where the friction lives:

• Addressing. You get codex1 as a name, not tmux:0.2.
• Delivery guarantees. initech send is synchronous; tmux send-keys is fire-and-forget.
• Unified activity state. One state machine across all three tools.
• Cross-machine. The same host:agent addressing works whether the agent is local or on a remote workbench. See cross-machine docs.

When to Mix Tools

Pick one tool when you have one kind of task. Mix tools when the project has genuinely different kinds of work (design vs execution, deep reasoning vs high-throughput edits) and you want to route tasks to whichever agent handles them best. The overhead of a multi-tool session is the config (ten lines of YAML) and the routing decision (which pane gets which task). Both get cheap after the first few sessions.

$ brew install nmelo/tap/initech

$ curl -fsSL https://initech.sh/install.sh | sh