Claude Code の完了信号は変わり続ける。追いつく方法
Claude Code の完了バナーのキーワードマッチが壊れ続けた理由と、MadoHub がエージェントのターン終了を知るために実際に信頼しているもの。
MadoHub はエージェントがターンを終えた瞬間を知る必要があります — それはルーティングを発火し、タイルを作業中から完了へ切り替え、接続されたエージェントに出力を拾って安全だと伝えるエッジです。しばらくの間、「どうやって Claude Code の完了を知るか」に対する私たちの答えは文字列の完全一致でした。それは、Claude Code が違う語を含むリリースを出すまで動き、そして動かなくなりました。これはそれが何に置き換えられたか、そしてその置換が実は本当の修正ではない理由の話です。
問題または洞察
予定通りに期限切れした単語リスト
Claude Code はターンを終えると 1 行のバナーを出力します — ✽ Worked for 2m 30s のようなもの。検出器の最初のバージョンはそのバナーの 2 つの特定動詞 — Sautéed と Cogitated — にマッチしました。それらが当時 Claude Code が印刷していた語だったためです。検出はキーワードチェックでした — 語を見て、アイドルタイマーを開始し、ルートを発火。
それは Claude Code がその 2 語を使い続ける間ちょうど保ちました。もう使いません。動詞は回転する気まぐれなセット — Worked、Churned、Sautéed、Cogitated、その他 — から引かれ、リリースをまたいで変わり、CLI の個性のビットのようです。単語リストが変わるたびに、私たちのキーワードマッチは静かに発火を止め、それを使うすべてのタイルは誰かが気づいて新しい語を追加するまで完了検出を止めていました。
列挙して動く目標を追うのは負け戦です。修正は、語が何かを気にするのをやめることでした。
語ではなく形にマッチ
すべての完了バナーは、今週どの動詞が出荷されても同じ構造を持ちます — 行頭のスピナーグリフ、大文字化過去形動詞、リテラル for、そして持続時間。次リリースでどの動詞が出荷されても、その形に収まる限り、コード変更なしに検出は動き続けます。グリフ要件が重要なのは、ターミナル出力が「動詞 + for + 持続時間」に合致してもターン終了を意味しない散文でいっぱいだからです — Retried for 3s を印刷する再試行ループ、Waited for 5s をログに残すビルドステップ。行頭にグリフを要求すれば、それらの誤マッチは消えます。
MadoHub がどう扱うか
バナーマッチは加速であり、評決ではない
このバナーマッチは MadoHub が Claude Code エージェントの完了を決める主の方法ではなく — 加速です。権威ある信号は Claude Code 自身のセッショントランスクリプトを直接読むバックエンドウォッチャーから来ます — ログに書かれた最後のメッセージを見て、それが保留中ツール呼び出しのない assistant メッセージならエージェントは完了、user メッセージ、進行メッセージ、ツール呼び出し途中の assistant メッセージならまだ動いている — と判断します。その評決にはラベルが付き、アプリの残りがトランスクリプト裏付けの事実と画面掻き取り推測を区別できます。
バナーマッチは、ターミナルを見つめていてバナーが現れた瞬間にタイルを切り替えたいという一般的ケースで、そのウォッチャーからレイテンシを削るためだけに存在します。
見逃しは良いが、誤マッチは悪い
厳しすぎるマッチと緩すぎるマッチの選択では、MadoHub は厳しい側に傾きます — 明示する価値のある意図的トレードオフです。見逃したバナーマッチは無害です — ウォッチャーが直後に本当の停止を報告します。誤バナーマッチは無害ではありません — ターン途中のタイルにルーティングを発火できるためです。そのため MadoHub は画面マッチの上に防御を重ねて走らせます — ライブウォッチャー評決がエージェントがまだ動いていると言っている間に画面由来の「完了」評決が現れたら、MadoHub はそれに作用せず画面評決をドロップします — 完了に関するウォッチャーの言葉が最終です。
実践的な指針
- Claude Code タイルを見ていてルートがいつ発火するか予測したいなら、今週の動詞を暗記しない。 数リリース後には別の語になります。代わりに形を学びましょう — グリフ、大文字化過去形動詞、
for、持続時間、すべて 1 行。それが Claude Code が真ん中に入る語を変え続けても印刷をやめない部分の信号です。 - タイルの状態が間違って見えることがあれば、画面ではなくウォッチャーを信頼しましょう。 MadoHub がそうします — トランスクリプトが実際に信頼する信号で、バナーマッチは一般的ケースをすばやく感じさせるためだけにあります。タイルが「done」に切り替わってから戻るのを見たら、それはバグではなく、過剰に熱心なバナーマッチをウォッチャーが修正しているのです。
- 特定の動詞に依存する独自ルーティングを書かない。 Claude Code の完了にキーオフする Flow やコネクションを構築するなら、バナーテキストを自分でマッチするのではなく MadoHub の状態（working / done / failed）に頼りましょう — そうしないと、次の Claude Code リリースが私たちの最初の検出器が壊れたのと同じようにあなたのセットアップを静かに壊します。
- ウォッチャーパスが忙しいときは、瞬時ではなくわずかな遅れを期待しましょう。 バナーマッチは一般的ケースを瞬時にしますが、忙しいマシンでは常に正しいバックストップであるウォッチャーが一瞬かかることがあります。1〜2 秒の遅れは正常です — 決して切り替わらないタイルは正常ではありません。
これは Claude Code tips の投稿 からの同じ助言の略記版に取って代わります — あれは形を見て進むように伝えましたが、これはその形がなぜ見るべき正しいものか、そしてその下でセッショントランスクリプトが MadoHub が実際に信頼する信号である理由の完全な説明です。