ドキュメント · ステータス

ステータス

各セッションの tmux ペインは 2 秒ごとにポーリングされ、ポーリングのたびに 1 つの状態に決まります。行はその状態を色付きの記号で示します。

最初の列はデフォルトの Advanced です。Settings → symbols で Compatible に切り替えると、ほかの記号を描けないフォント向けのプレーンな ASCII の記号になります。そこでは starting の行が ASCII のスピナーで動き、グループは > と v で折りたたまれ、Y が worktree のブランチや分岐を示します。

ペインのルール#

検出では、ツールごとの正規表現のルールを表示中のペインに当て、最新のターンを読んで finished と waiting を見分け、ポーリングの間に変化する出力を working とみなします。まとめの行がないまま終わったターンも判定されます。静かになった working のペインは finished、質問で終わった場合は waiting になります。

それを始めたターンより長く続き、終わるとエージェントに報告する作業（バックグラウンドのエージェント、動的なワークフロー、Claude Code がバックグラウンドに移した MCP 呼び出し）は busy_line で検出されるので、その作業が動いている間は、ターン終了のまとめがあっても working のままです。バックグラウンドのシェルやモニターを動かしたまま終わるターンはほかのターンと同じように終わり、そのシェルがエージェントを起こすと、続くターンは終わるまで working になります。使用量やレート制限のバナー（limit_line）は errored です。セッションの中にいる間もポーリングは続くので、ステータスは常に最新です。リストに dead の行があってもレビューを開いていても、ポーリングは 2 秒間隔のままです。v0.43.2 より前は、どちらの場合もポーラーが回り続けていました。ポーリングのたびにキューに入れた処理が、終わるときに次のポーリングを要求していたためです。

Claude Code のフック#

Claude Code では、ステータスは推測ではなく、Claude Code 自身から直接得たものです。セッションは生成された --settings ファイル付きで起動し、そのフックがライフサイクルの状態をセッションごとのステータスファイルに書き込み、ポーラーはまずそれを読みます。Claude Code のプロファイルは、このために status_source を claude-hooks に設定しています。

rate_limit の StopFailure は errored を書き込みます。それでもペインのルールで補正されます。フックからはテキストでの質問、Esc による中断、エラーの行が見えないので、一致したペインの判定がフックのステータスを上書きします。フックのファイルがないか古い場合は、ペインのルールが完全に引き継ぎます。

リストの読み方#

各行にはステータスとツールが並んで表示され、折りたたまれたグループはステータスごとの件数を保つので、閉じたサブツリーでもその下に対応が必要なものがあるかがわかります。w を押すと、リストには waiting、finished、errored の行だけが残ります。もう一度押すとツリー全体に戻ります。セッションを選ぶと右側にペインの末尾が表示されるので、waiting のエージェントの実際の質問が、アタッチせずに読めます。ほかのエージェントからのメッセージが入力待ちになっているセッションには ✉（Compatible では @）と、名前の横に件数が表示されます。ターン終了後のアーカイブや終了を求めたセッションには、マネージャーが実行するか c で取り消すまで ↓ または ■（A または K）が表示されます。

通知#

セッションのステータスが waiting または errored に変わると、マネージャーは遷移ごとに 1 回通知を出します。タイトルには、セッション名、実行中のディレクトリ、マネージャーが worktree を作った場合はそのブランチ、ツールが入ります。worktree の場合は、切り出し元のリポジトリ名になります。タイトルは deploy · api · am/fix-login · codex のようになります。バナーには、セッションの行に表示されている 1 行が引用されます。waiting の場合はエージェントの質問で、◆ Waiting: Do you want to create probe.txt? のようになります。finished の場合は行に表示されているプロンプトで、● Finished: write three sentences about rivers のようになります。引用は 1 行で、120 文字で切られます。行に引用するものがなければ、waiting のバナーは ◆ Waiting for your input、finished のバナーは ● Finished のままです。errored のバナーは ✕ Errored のままです。Settings の notifications の行（デフォルトはオン）で通知を止められ、notify on finish の行（デフォルトはオフ）で finished への遷移も通知するようになります。

macOS のデスクトップ通知では、waiting、finished、errored にそれぞれ別の音が鳴ります。Linux では notify-send で対応するヒントを送ります。Ghostty や cmux の中では、状態は OSC 777 エスケープとして描画中のターミナルに届くので、マネージャーを SSH 経由でリモートホストで動かしている場合も届きます。WSL では、バナーは PowerShell から送るネイティブの Windows トーストになります。そのほかのターミナルでは OS のデスクトップ通知を使い、デスクトップのないヘッドレスのマシンではターミナルのベルにフォールバックします。

通知のたびにシェルコマンドを実行することもできます。agent-manager settings set notify_command '<command>' で設定し、空の値で解除します。Settings の行はありません。マネージャーはバナーの後に、macOS と Linux では sh -c、Windows では PowerShell を通してコマンドを実行し、同じ 2 つの Settings の行がその実行も制御します。イベントは環境変数 AM_NOTIFY_KIND、AM_SESSION_ID、AM_SESSION_NAME、AM_TOOL、AM_CWD、AM_BRANCH、AM_TITLE、AM_BODY として渡されます。Windows では $env:AM_BODY などの形で読みます。15 秒経っても動いているコマンドは停止されます。失敗は設定ディレクトリの notify-command.log に書き込まれ、マネージャーはそのまま動き続けます。コマンドを初めて設定したときと変更したときは、実行の前に New notify command のバナーでコマンドが表示されます。