Claude Code や Codex のような AIコーディングエージェントを複数の tmux セッションで立ち上げて同時に動かしているうちに、問題が出てきました。どのセッションが終わったのか、どれが自分の入力待ちで止まっているのかを見落としてしまい、バックグラウンドで動いているエージェントは usage limit に達してからようやく気づくこともありました。
tmux ではここまでが限界だったので、comux を作りました。
comux は AIエージェントを動かすための tmux スタイルのマルチプレクサです。
- すべてのセッションのエージェント状態（working / ready / blocked）をサイドバーにリアルタイム表示します
- エージェントがターンを終えたり入力待ちになったりすると、即座にデスクトップ通知を送信します
- サーバーを停止したり再起動したりしても、再開時に各エージェントを会話していた地点まで復元できます（tmux-resurrect とは異なり session を再起動します）
- エージェントたちの usage と、たまっている通知を status bar でリアルタイムに確認できます
依存関係のない単一の静的バイナリなので、SSH ヘッドレスサーバーなどどこでも動作します。
より大きなターミナルプロジェクト（copad）の一部ですが、comux だけを個別にインストールすることもできます:
# Comuxのみインストール
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Copad までインストール (Linux & MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
4か月間の制作記: https://marshallku.com/dev/road-to-making-my-own-terminal/
複数のエージェントを動かしている方からのフィードバックを歓迎します。
3件のコメント
ブログ記事も楽しく拝読しました。
私も似たような動機でターミナルを開発している立場として、気になる点が出てきました。
個人的には、最近のように DX 環境が速く変わり、開発者ごとにやり方が異なる時代はあまりなかったのではと思っているのですが、
作者の方もそう感じられたかは分かりませんが、こういう時だからこそ制御権が自分にあるほうが有利だと考えましたし、
AI 時代の DX の土台は何かと考えたとき、私はターミナルベースだと思いました。
最近流行っているターミナルもひととおり使ってみましたが、韓国語入力もほとんどのターミナルで不十分で、エージェントを使うには DX、UX ともに不便だったので、私も自分で直接開発しようという結論に至って進めてきましたし、自分のターミナルによって他の人より高い生産性を確保できたと思っています。
私の場合、制御権を完全に得るために、
外部ライブラリへの依存も最小化すべきだと考えて、Zig でのフルスクラッチ開発を選んだのですが（やむを得ない WebView のようなものは除いて）、
ブログ記事とコードを見ると Rust を選ばれていて、rataui など、独自実装よりも Rust に存在する外部ライブラリを選ばれた理由が気になります。
記事を見ても、外部ライブラリ依存による問題があったようなので。
それから、WebView がネイティブ WebView である以上、たいていの Web 環境は Safari 環境ではないので、完全な E2E テストは難しいように思うのですが、この部分は外部のテストツールに任せる感じなのでしょうか。あるいは今後 CEF も入れる計画があるのかも気になります。
私もターミナルがある程度使えるようになって安定化段階に入り、機能追加や企画、あるいは UX をいろいろ考える段階に入っていますが、開発中はクラッシュやさまざまなバグも多かったはずで、
開発を始めてから、実行環境としても外部ターミナルではなく自作のターミナルに入れるくらい安定したのは、だいたいいつ頃だったのかも気になります。
こんにちは！
良い経験やお考えを共有してくださりありがとうございます。
もちろん、コードを生み出すコストが下がったことで自作への道は開けましたが、個人的にはAI時代になったこととは関係なく、外部ライブラリを導入するという考え方で見ています。
この2つが当てはまると思える場合にだけ、自分で作るようにしています。
理由はいろいろありますが、結局どんなに小さなコード片でも自分が管理し始めると、最終的には自分がレビュー、テスト、保守などをしなければならない領域に入り、単にコードを書く以上のコストが常についてくると考えているからです。
開発の過程で起きた問題も、window manager のようなかなりコアなプログラムとの衝突が多かったので、もしこれまで全部 build from scratch していたら、外部依存との衝突をデバッグしてテストする期間よりも、はるかに多くの時間を実装と検証に費やすことになっていたと思います。
加えて、私は開発に入ってからずっとつらいながらも自分で作ったツールを使ってきたのですが、それが可能だった理由も、ある程度は依存関係の上に乗って開発を始めたからではないかとも思っています。
MacOS で SwiftTerm を取り除いた事例のように、まず外部依存を入れて自分の望むコンセプトが動くかを確認し、自分で実装すべきものが出てきたら直接実装を始めますが、この時点でも外部依存によってひとまず自分のプログラムは動いているので、その上で継続して安定化や機能追加に注力できました。
さらに、webkit を入れれば、たいていのウェブアプリは通常のブラウザを開いたときと同じように動作します！
最近は headless browser を cli から制御できるツールや、claude in chrome も積極的に活用していますし、ターミナルにまで chromium を載せてメモリを過剰に使うのは避けたいので、大きなことがない限り、ターミナル内の webview の技術スタックはあまり変えないと思います。
読んでくださってありがとうございます！
マルチプレクサのインストールリンクが切れてしまっていますね。README のこの項目を確認していただければ、マルチプレクサだけをインストールできます。