initechプロジェクトの技術記事。
2026年4月1日
Claude Code、Codex、OpenCodeを同じTUIで動かす
initechは最初、すべてのペインがClaude Codeだと仮定していました。
実際の運用ではその前提はすぐ崩れます。広い変更はClaude Code。閉じた作業はCodexのfull-auto。別の操作感が欲しいときはOpenCode。面倒なのは起動ではなく、それらを1つの監視画面で扱うことです。
いまのinitechは、Claude Code、OpenAI Codex、OpenCodeを同じTUIに並べて動かせます。
多くのmulti-agentツールは、全ペインが同じCLIを動かすことを暗黙に前提にしています。その前提は起動方法、入力方法、プロンプト判定、送信キーにまで漏れます。
ツールを混ぜるとすぐに差が出ます。bracketed pasteを前提にするCLIもあれば、それを嫌うCLIもある。単純な>で入力可能なツールもあれば、まだサービス起動中やtrust画面にいるツールもある。権限確認が1つ出るだけで、そのロール全体が止まります。
見える変更はinitech.yamlのrole_overridesです。デフォルトの起動コマンドから外れるロールだけが独自のコマンド配列を持ち、agent_typeがそのペインに使うハーネスを決めます。
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
commandは追記ではなく完全置換です。Claude向けのフラグがCodexに混ざることはありません。さらにagent_typeは単なるラベルではなく、ready判定、bracketed paste、submit key、CLI固有の自動化を切り替えます。
ターミナルマルチプレクサで地味に重要なのがsubmitです。ここがずれると、見た目だけ動いて実際には何も送れていません。
Claude Codeは従来どおりbracketed pasteを使います。Codex系のペインでは、プロンプトが本当に戻るまで待ち、本文をPTYへ直接書き込み、paste burstの判定が落ち着いてからsubmit keyを送ります。
Codexの自律実行で面倒なのが権限確認です。確認が1つ出るだけで、そのペインは人間待ちになります。
agent_type: codexでは、initechはauto_approveをデフォルトで有効にします。terminal下部の既知パターンを見つけたら、pを送って承認と記憶を行います。
大事なのは「Codexが動くようになった」こと自体ではありません。initechがagent-agnosticなterminal multiplexerに近づいていることです。
オペレーターが見る面は1つ。TUIも1つ。監視場所も1つ。その中で、役割に合うエージェントを選べばいい。そこが今回の変化です。
インストール: initech.sh/install.sh
ソースコード: github.com/nmelo/initech
2026年3月31日
ロール別コマンドオーバーライド：Codex、Amp、Claude Codeを並行実行
initechはClaude Code専用ではなくなりました。initech.yamlのrole_overridesで、任意のロールに異なるCLIを指定できます。あるエージェントにはCodex、別のエージェントにはAmp、残りにはClaude Code。同じIPC、同じアクティビティ検出、同じTUI。
initech.yamlの新しいrole_overridesブロックで、ロールごとにデフォルトコマンドをオーバーライドできます：
# initech.yaml role_overrides: codex-eng: command: ['codex', '--full-auto', '--no-alt-screen'] amp-design: command: ['amp']
各オーバーライドはロール名をコマンド配列にマッピングします。ロールは引き続き独自のPTY、TUI内の独自のペイン、initech send / initech peekへの完全なアクセスを持ちます。ランタイムはPTY内で何が動いているかを気にしません。
「エージェントランタイム」というフレーミングは、これまで構想段階にとどまっていました。initechはあらゆる場所でClaude Codeを前提としていました。アクティビティ検出はClaudeのスピナーに依存し、イベントシステムはClaudeのJSONLログを解析し、ロールテンプレートはCLAUDE.mdファイルでした。
コマンドオーバーライドにより、コアプリミティブは引き続き機能します。PTYバイトフローは、どのCLIが出力を生成しても活動を検出します。IPCメッセージングはターミナルレベルで動作し、Claude固有ではありません。CLAUDE.mdテンプレートはClaude Codeを実行するロールにのみ適用されます。他のCLIは独自の設定を持ち込みます。
Claude以外のCLIで失われるもの：JSONLベースのイベント解析（ビーズ完了検出、停滞検出）とセッションログ対応のトースト通知。アクティビティ検出とIPCは引き続き機能します。混合フリートの場合、Claude Codeエージェントはフル機能セットを利用でき、それ以外は信頼性の高いPTY管理とメッセージングを利用できます。
明白なもの：同じコードベースでエージェントCLIを比較したい場合。engロールをClaude Codeで実行し、並列のengロールをCodexで実行。同じタスク、異なるエージェント、並べて表示。
実用的なもの：タスクによって適したツールが異なります。単純なリファクタリングにはフルオートモードのCodexエージェント。より多くのガイダンスが必要な複雑なマルチファイル変更にはClaude Code。どちらも1つのターミナルから可視化・アドレス指定可能。
$ curl -fsSL https://initech.sh/install.sh | bash
ソースコードとオペレーターガイド: github.com/nmelo/initech
2026年3月30日
クロスマシン連携：複数マシンでエージェントフリートを実行する
initechがクロスマシン連携に対応しました。ワークステーション、リモートGPUマシン、クラウドVMなど、任意のマシンで initech serve を実行すると、ローカルTUIがそのエージェントペインをリアルタイムでストリーミング表示します。1つのターミナル。すべてのエージェント。どのマシンでも。
リモートマシンの initech.yaml に mode: headless、peer_name、listen、token を追加します：
project: myproject root: /home/user/myproject mode: headless peer_name: workbench listen: ":7391" token: "shared-secret" roles: - eng1 - eng2 - eng3
デーモンを起動：
$ initech serve
ローカルの initech.yaml に remotes: ブロックを追加します：
project: myproject
root: /Users/you/myproject
token: "shared-secret"
roles:
- super
- pm
- qa1
remotes:
workbench:
addr: "192.168.1.100:7391"
通常通りTUIを起動：
$ initech
$ initech send workbench:eng1 "APIリファクタを開始" $ initech peek workbench:eng2 -n 30 $ initech peers
March 28, 2026
なぜAIエージェント用のターミナルマルチプレクサを構築したのか
複数のClaude Codeエージェントを並列管理するGo TUIを構築しました。セッションランタイムとしてtmuxを置き換えました。
各エージェントにロール固有の指示を持つClaude Codeターミナルを与えます。supervisorエージェントが調整。エンジニアエージェントが実装。QAエージェントが検証。shipperエージェントがリリース。各エージェントは、アイデンティティ、制約、ワークフロー、通信プロトコルをエンコードするCLAUDE.mdを持ちます。
initechを構築する前に、4つのプロジェクトでこのパターンを実行しました。並列エンジニアリング、独立したQA、リリースゲーティング、セッション間の組織記憶を備えた実際のソフトウェアをシップしました。
tmuxはエージェントを追加するほど悪化する3つの問題を抱えています。
tmux send-keysには配信保証がありません。エージェントのペインにメッセージを送り、届くことを祈ります。届かなくてもエラーは出ません。engからsuperへの完了報告がドロップすると、superはengの完了を知らず、QAはディスパッチされず、ビーズは1時間停滞します。
ハングしたエージェントと生産的なエージェントは、tmuxでは同じに見えます。完了と作業中も同じに見えます。確認する唯一の方法は各ペインを覗くこと。9エージェントなら、10-15分ごとに9回の手動チェックです。
tmuxはどんな作業があるか、誰が何に割り当てられているか、エージェントがタスクをready for QAにしたことも知りません。全てのオーケストレーションはsuperのコンテキストウィンドウに存在します。コンテキストはコンパクトされ、メッセージは失われ、supervisorエージェントはengの完了を忘れ、ディスパッチチェーンが停滞します。
tmuxは汎用ターミナルマルチプレクサであり、アプリケーションレベルのインテリジェンスが必要な仕事をしています。
各セッションはUnixドメインソケットを実行します。initech sendはエミュレータを通じてエージェントのPTYにテキストを書き込み、配信を確認します。送信者は数秒以内に明示的なOKまたはエラーを受け取ります。
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
最初にJSONLセッションログのテーリングを試しました。信頼性なし：Claudeは会話の境界でJSONLに書き込みますが、予測不能です。45秒の思考中の停止で、エントリはゼロ。タイムアウトのどんな値も、何かのケースでは不正解です。
正解：PTYが最後に出力を生成した時間を追跡。Claude Codeのスピナーは思考中に10-30 fpsでアニメーション。出力ゼロの唯一の状態はプロンプトでのアイドル。2秒の閾値でクリーンなバイナリ検出が可能。
緑は稼働中。グレーはアイドル。黄色はタスク待ちでアイドル。オーバーレイでペインを開かずに全エージェントの状態を表示。
JSONLはアクティビティ検出には失敗しましたが、セマンティックイベントには機能します。セッションログにはツール使用結果、アシスタントメッセージ、エラーシーケンスが含まれます。イベントシステムはこれらを解析して：
* ビーズ完了：エージェントが実行 bd update --status ready_for_qa
* 停滞：ビーズ割り当て中に10分以上出力なし
* エラーループ：3回以上連続のツール失敗
* ビーズクレーム：bdコマンドから自動検出、追加のCLIコール不要
イベントはトースト通知として表示。superが報告する前に「eng1 completed ini-bhk.3」が緑色で表示されます。
各エージェントのリボンに現在のビーズを表示。オーバーレイで全エージェントの状態を一覧。エージェントがビーズを保持したままアイドルになると、TUIがsupervisorエージェントに直接通知：「[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete.」
上記の全ての数字はツール自体が生成したものです。initechはinitechを構築したエージェントを管理しました。
TUIはランタイム。テンプレートがインテリジェンス。悪いCLAUDE.mdはTUIがどんなに良くても悪い出力を生みます。11のテンプレートを3回書き直し、実際の失敗からの教訓をコード化：エンジニアエージェントがPLANコメントをスキップ、QAエージェントがラバースタンプ、supervisorエージェントがディスパッチせずに作業を実施。
PTYバイトリーセンシーが機能するまで3つのアプローチを試しました。JSONLテーリング：遅すぎ。ターミナル出力レート：SIGWINCHの偽陽性。プロンプト検出：UI変更に脆弱。スピナーアプローチはClaude Codeが作業時に常に出力するから機能します。静的な「thinking...」表示では壊れます。
supervisorエージェントの最大の失敗：ディスパッチせずに実装すること。ディスパッチは遅く感じます。しかし、マルチエージェントの要点は専門化です。「エージェントを使わない」がsuperテンプレートの最初のクリティカル失敗モードになりました。
全てのエージェントは最終的にコーディング前のPLANコメント、ready_for_qa前のpush、ビーズ表示のクリアを忘れます。auto-notifyはエージェントが完了報告を忘れるために存在します。ガードレールは助けになりますが、完全には排除できません。プロセス遵守はバイナリではなく、グラデーションです。
セッション移植性 は未着手。マシン間（MacBookからワークベンチへ）のセッション移動は手動rsyncが必要。PRDには initech migrate コマンドが記述されていますが、まだ存在しません。
リソース管理 はフラグの後ろにあります。メモリプレッシャー下でのオートサスペンド/レジューム（36GBノートPCで有効なエージェント容量を倍増させる機能）は実装済みですが、 --auto-suspend の後ろにゲートされています。ポリシーが実セッションで十分にテストされていないためです。
オンボーディング は荒削りです。初めて initech を実行した新規ユーザーは、ガイダンスなしで7つのペインを見ます。ステータスバーのヒントが下部に表示されますが、完全なワークフローを文書化したオペレーターガイドはありません。このツールは自身のユーザーによって構築されたもので、それが表れています。
初期段階。 initechは現在、複数のプロジェクトで使用されていますが、ユーザーベースはまだ小さいです。より多くの実際の使用がドッグフーディングでは見つからなかったギャップを明らかにするでしょう。
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech