osFoundryが検知方式を比較

Claude Code 2.1.303は、スペースを書き込む代わりに\x1b[5GのようなCSIシーケンスでカーソルを固定列にジャンプさせて許可プロンプトを構築し、改行バイトを一切送らない。保存された11件のキャプチャ（2,099〜7,672バイト）はすべて改行バイトをゼロ個しか含んでいない。この設計により、出力末尾をgrepする安易な近道は通用しない。osFoundryの規則をPythonに移植し、各キャプチャの末尾8KBをエスケープシーケンス除去後、最後のキャリッジリターン以降のテキストを保持して採点したところ、実際にブロックされていた4件を含む全ケースでidleと判定された。見かけのプロンプト文も「Doyouwanttoproceed?」と連結してしまった。同じバイトを、文字、\r \n \b、カーソル移動、消去のみを扱う最小限の画面エミュレータに通すと、11件の状態をすべて正しく復元できた。

osFoundryデスクトップアプリはこの結論に従っている。terminal_pty.rsでは各セッションがvt100::Parserを保持し、検知にはエミュレート画面のscreen_text()のみを使う。その上の200行のスクロールバックは意図的に除外されている。応答済みで上にスクロールされたプロンプトがあると、ペインが永久にblockedと表示され続けてしまうからだ。

Claude Codeの文言と再描画の癖を模倣した代役エージェントによるライブ環境では、全ペインの700msスイープに中央値0.26秒、最大0.70秒の追加遅延が生じ、状態の残留は最大1サイクルだった。人が読むバッジとしては十分だ。自前で構築する人向けのプロジェクトの指針は次のとおり。エミュレート画面を分類すること、プロンプト固有のテキストとフッターを照合すること、blocked規則をworking規則より上に置くこと、エージェントを起動するプログラムにこれらの規則を編集させないこと、プロセステーブルは誰が実行中かを見る手段であり誰が待機中かを見る手段ではないと扱うこと。