Claude CodeとCodexを並行して回していると、片方の画面がしばらく動かないとき「フリーズしたのか、単に長い処理を回しているだけなのか」を判断できない瞬間がある。デーモンもネットワークも使わず、ローカルのSQLite1枚でエージェント同士を横断監視するagmsgを、v1.1.11のリリースノートから読み解く。
複数のCLIエージェントを併用する運用者が抱える「止まっているのか進んでいるのか分からない」問題の輪郭と、agmsgが選んだ共有SQLite＋アイドル検知という解決の型。
Claude CodeとCodexを同時に走らせる運用が当たり前になってくると、必ずぶつかる壁がある。片方のペインがしばらく出力を止めているとき、それが本当にハングしているのか、それとも長いツール呼び出しを裏で回しているだけなのか、外から見分ける手段がないという壁だ。
1つのエージェントを1人で見ている間はまだ我慢できる。だが複数のエージェント・複数のベンダーを並行運用し始めると、「様子を見に行く」というだけの確認作業が、それ自体コンテキストスイッチのコストになる。誰かが（あるいは何かが）代わりに「動いているかどうか」を判定してくれる仕組みが欲しくなる。
Koichi氏（@fujibee）が開発するagmsgは、GitHubリポジトリの説明によれば「Cross-agent messaging for CLI AI agents. No daemon, no network, no complexity.」を掲げるツールだ。Claude Code・Codex・Gemini CLI・GitHub Copilot CLI・Antigravity・OpenCode・Hermesの7種のCLIエージェントを横断して、メッセージのやり取りと監視ができる。
デーモンもソケットもメッセージブローカーも存在しない。「ファイルが共有の土台」というのが設計の核で、各エージェントは配信モードに応じてフックまたはMonitorストリームを持ち、共有SQLiteファイルから読み取って受信メッセージをテキストとして提示する。WALモードなので複数のリーダーと単一のライターが競合なく共存できる。
Claude Code側はデフォルトで、SessionStartフック→Monitorツール→ブロッキングSQLiteストリームという経路で約5秒のレイテンシのプッシュ通知を実現する。Codex側は「mode monitor」をapp-serverブリッジ経由でサポートし、インタラクティブシェル内でagmsgのmonitorシムにルーティングする形で対応する。
agmsg spawnは役割を持つ別のエージェントプロセスを起動時に立ち上げ、despawnはそれをきれいに終了させる逆操作になる。対応7エージェントのうちHermesだけはインタラクティブセッションを開始するCLIモードを持たないため、spawn非対応と明記されている。
ここが核心。複雑な常駐サーバーを立てるのではなく、ローカルの1ファイルを各エージェントが読み書きする最小構成で、ベンダーの壁を越えたメッセージングと監視を成立させている。
2026-07-27付けのv1.1.11では、監視まわりに2つの変更が入った。CHANGELOGによると、1つ目はCodexのMonitorモードが「offer monitor as the default delivery mode, drop the beta framing」——ベータの位置づけを外し、既定の配信モードとして扱われるようになったこと。2つ目は「Make the turn watchdog an idle timeout, not a fixed ceiling」——ターンの監視方式を、固定の上限時間で切るのではなく、アイドル状態を検知する方式に変更したことだ。
この変更の意味は、01節で挙げた「固まっているのか、重い処理を回しているだけなのか」を区別する話に直結する。固定時間の上限は、時間内に終わらない正常な長時間処理まで巻き込んで誤検知してしまう。アイドル検知は「一定時間、何の動きもない」ことを見るので、処理中のターンを不当に切断しにくい。あわせてherdr（ターミナルペイン管理ツール）との連携で、spawnした際にペインへ直接エージェントを配置できるサポートも追加されている。
なお開発者本人はXでの投稿（2026-07-27）の中で、この監視方式変更の効果として、launcherのプロセス生成頻度が大幅に低下した具体的な数値（毎秒100回超→数回程度、load averageが跳ね上がっていたケースの解消）を報告している。この数値そのものはGitHub側のリリースノート・PRには記載がなく、開発者本人のポストのみでの報告である点は留保して読んでほしい。
agmsg自体を導入するかどうかより、この設計変更が示す教訓の方が汎用性が高い。複数のAIエージェントを自動化に組み込んでいるなら、次の3点で自分の監視ロジックを見直せる。
複数のAIエージェントを二人体制・三人体制で回す運用は、引き継ぎの窓口をファイル1枚に集約する設計から始まることが多い。agmsgはその延長線上で、「引き継ぎ」だけでなく「今動いているかどうかのリアルタイム監視」までファイル1枚に寄せた事例として読める。