Running Claude Code, Codex, and OpenCode in the Same TUI

initech started with a simple assumption: every pane was Claude Code.

That assumption breaks as soon as you use agent CLIs for real work. You end up mixing tools. Claude Code for the broad refactor. Codex in full-auto mode for a contained task. OpenCode for a different interaction model. The annoying part is not launching them. The annoying part is supervising them together without turning your screen into a mess of unrelated tabs.

initech can now run Claude Code, OpenAI Codex, and OpenCode side by side in the same TUI.

initech grid showing Claude Code, Codex, and OpenCode panes side by side — One TUI, mixed agent types, one overlay that still tells you what every role is doing.

The problem

Most multi-agent tooling quietly assumes every pane runs the same binary. That leaks into the launch path, the input path, the prompt detection, the submit key, and the operator workflow.

Once you mix tools, the rough edges show up fast. One CLI expects bracketed paste. Another treats it as noise. One agent is really idle at a plain > prompt. Another is still booting MCP services or waiting on a trust screen. One permission dialog can freeze an otherwise autonomous run until a human notices it.

The goal is simpler than that: one supervisor TUI, multiple agents, no requirement that every pane runs the same CLI.

How it works

The visible change is role_overrides in initech.yaml. Roles that differ from the default launch command can override it with their own command array, and the runtime uses agent_type to pick the right harness for that pane.

project: myproject
root: ~/src/myproject

claude_command: ["claude"]
claude_args: ["--continue"]

roles:
  - super
  - eng1
  - eng2
  - qa1

role_overrides:
  eng2:
    command: ["codex", "resume", "--last", "--full-auto"]
    agent_type: codex

  qa1:
    command: ["opencode", "--continue"]
    agent_type: opencode

Two details matter.

command is a full replacement, not an append. A Codex role does not inherit Claude-specific flags by accident.
agent_type is not decorative metadata. It tells initech how to drive the pane: readiness checks, bracketed paste behavior, submit key, and any tool-specific automation.

initech.yaml showing role_overrides for Codex and OpenCode roles — The default stays Claude Code. Overrides exist only for roles that need a different CLI.

Today the built-in harnesses are claude-code, codex, opencode, and generic. Claude Code keeps the bracketed-paste path. Codex and OpenCode use the non-bracketed send path and an enter submit flow. generic is the conservative fallback.

Auto-submit across agents

The unglamorous problem in a terminal multiplexer is submit. If submit is wrong, the rest of the runtime does not matter.

For Claude Code panes, initech still uses bracketed paste and the old submit path. For Codex-like panes, the runtime waits until the prompt is actually ready, writes the message body directly to the PTY, pauses long enough for paste-burst detection to clear, and only then sends the submit key.

That readiness check is the difference between "supports multiple CLIs" and "happens to launch multiple CLIs." It prevents the TUI from injecting text while a pane is still on a trust prompt or still booting services.

Codex pane in initech showing a visible Working indicator — Codex gets its own harness path, including prompt detection and submit timing that matches the CLI.

Codex permission auto-approve

Codex has one more sharp edge in autonomous runs: permission prompts. A single confirmation can stall a role until somebody sees it.

For agent_type: codex, initech now defaults to auto_approve. The pane scans the lower rows of the terminal for known Codex permission prompt patterns and sends p to approve and remember the choice.

That default is intentionally narrow. The runtime should only automate prompts it understands well enough to automate safely. OpenCode shares the send path, but it does not inherit Codex-specific approval logic just because the input harness is similar.

The direction

The interesting part is not "Codex works now." The interesting part is that initech is moving toward an agent-agnostic terminal multiplexer.

That does not mean pretending every agent is the same. Different tools need different launch commands, different input handling, different readiness checks, and sometimes different prompt automation. The point is that the operator interface stays stable while the harness underneath adapts per pane.

One TUI. One command surface. One place to supervise work. Use the agent that fits the role.

Install: initech.sh/install.sh
Source: github.com/nmelo/initech

Related docs:

← Back to all posts