エージェント別の対応状況

tako は Claude Code を基準に実装してきました。ほかのエージェント CLI でも worker を立てて使えますが、機能によっては落ちるか、まだ使えません。 このページは tako 本体が持っている能力マトリクスから生成しているので、 実装とずれません。手元で最新を引くには次を実行してください。

入れ方・つなぎ方は系統ごとのページにあります: エージェントの選び方 / Claude Code / OpenAI Codex CLI / Antigravity CLI / ローカル LLM。

tako agent-support                        # 全系統の表
tako agent-support --agent codex          # codex の理由つき一覧
tako agent-support --agent agy --status pending   # まだ使えないものだけ

全体

能力 66 件の内訳です。

エージェント	対応	一部対応	未対応	対象外
Claude Code（基準）	66 / 66	0	0	0
OpenAI Codex CLI	37 / 66	9	17	3
Antigravity CLI	24 / 66	6	24	12
Local LLM	0 / 66	0	54	12

状態の意味

状態	意味
対応	Claude Code と同じように使えます
一部対応	使えますが機能が落ちます。落ち方は各表の「差分」列
未対応	tako 側の実装が無い、またはまだ調べていないもの。追跡先の Issue 番号が付きます
対象外	そのエージェント CLI にその手段がそもそも無いもの

「未対応」と「対象外」を混ぜていません。調べていないものは「対象外」ではなく 「未対応」に置いています。まだ道があるかもしれないものを「無理」と書くと、 この宣言を読んで動く AI エージェントがその道を永久に避けてしまうためです。

各表の「根拠」列が判定の裏づけです。

根拠	意味
コード本文	tako 自身の実装がそうなっていること（配線の有無）を引用したもの
上流の仕様	エージェント CLI 側の仕様・設計判断で、実測する対象がそもそも無いもの
実測	実際に動かして結果を記録したもの
テスト	緑のテストが担保しているもの
未確認	まだ確かめていないもの

ローカル LLM について

現時点では 1 つも成立していません（表の値はほぼ「未対応」です）。 第一歩は codex CLI を Ollama へ向ける経路で、TUI 前提を外した一級対応は その次の段階です。

OpenAI Codex CLI を選ぶと落ちるもの

対応 37 / 66 件。以下は Claude Code との差分です（同じ理由のものはまとめています）。

一部対応（9 件）

• worker の状態照会では構造化ソースから ctx% が取れるが、master の自動ハンドオフは画面のパターンを見るので master 経路では未確認
  • コンテキスト残量を画面から読み取れる（master_ctx_percent）
• tako の実装が claude 専用で、この系統への配線がまだ無い
  • 画面で確かめられない送達を、諦める前に受け手の会話記録で確かめる（#2330）（prompt_delivery_receipt）
• worker の再開（再起動をまたぐ復元を含む）は spawn と同じ引数（モデル・effort・プロファイルの args と env）で立てる。master / solo の再開はカタログのメタだけで組む
  • 会話を再開するとき、元の起動と同じ引数（モデル・effort・system prompt・許可モード・Remote Control）で立てる（#1967）（resume_launch_args）
• spawn の記録は残るが、会話の実体を索引できないので pending のまま期限切れで消える
  • 会話がセッションカタログに索引される（#112）（sessions_catalog）
• codex の % は rollout の rate_limits を観測にして過去の分まで配るが、重みは API 換算ではなく生トークンの比（codex のモデルは単価表に無い）。rollout はどのログインで使ったかを持たないので、過去の分も今の auth.json のログインへ寄せる（#2204）
  • 観測した利用制限（5h / 7d）の % の増分を、区間の使用量の比でプロジェクト・Issue・会話へ配る（#2202）（usage_limit_share）
• codex のモデル（gpt- / codex-auto-review）は API 換算の単価表に無いので、使用量はトークン数だけを数える（API 換算は出ない）。rollout はどのログインで使ったかを持たないので、過去の分も今の auth.json のログインへ寄せる（#2204）*
  • 会話記録の使用量（トークン・API 換算）をプロジェクト・Issue・会話ごとに集計する（#2201）（usage_tokens）
• 5h / 週の枠は解除を待って自分で再開するが、ワークスペースのクレジットが尽きた場合は「待つ」出口が無い（増枠申請・購入・獲得済みリセットの引き換えしか無いので、tako は何も選ばずに止まる）
  • 利用上限の解除後に自分で再開する（#813）（worker_limit_autoresume）
• 宣言したモデルだけを返す。実際に使われたモデルは読まない（model_actual は null・model_check は not_observed）ので、CLI が別のモデルへ解決しても食い違いの警告は出ず、ledger も宣言のモデルで集計される
  • worker が実際に使ったモデルを確かめ、宣言との食い違いを知らせる（#1638）（worker_model_actual）
• 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない
  • 作業フォルダを起動前に信頼済みにしておく（信頼ダイアログで止まらない）（worker_trust）

未対応（17 件）

• 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない（追跡: #975）
  • アカウント（資格情報）の切替に追従する（account_switch）
• この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）（追跡: #1885）
  • エージェントの画面の中（プロンプトの上の帯 1 行・/tako のサイドバー・入力欄の下の行の使用制限 / ctx のバー）に tako のペイン・タブ・worker と要注意の数を出す。利用者の他の拡張の帯は消さない（claude_mod_band）
  • エージェントの画面の中（プロンプトの上の帯）に定型のカスタムボタン（既定は /compact。組み込みコマンド・tako の操作・新しいペインで実行するコマンド・入力欄へ入れる文）を描き、キーで押して実行する（claude_mod_buttons）
  • AI が出したコマンドカードをエージェントの画面の中（会話の行と入力欄の上の帯）に描き、キーでコピー / 新しいペインで実行する（描いたカードはペイン下のカード帯に出さない = 画面が縮まない）（claude_mod_cards）
  • チャット風の描画（発言の吹き出し・コードブロックのコピー・ツール呼び出しの 1 行の要約）をエージェントの画面の中に描く（ターミナル表示では既定でコードのコピーだけ。GUI モードで選べば tako のチャットビューの代わりにその画面を見せる）（claude_mod_chat）
  • tako setup がエージェントの設定 dir ごとに tako の拡張を入れる（管理印つき・同名の他の拡張があれば入れない・tako mod uninstall で外せる）（claude_mod_install）
  • エージェントの中で動く拡張（tako mod）から ctx・使用制限・ターン・権限待ちを構造で受け取る（claude_mod_state）
  • エージェントの画面の中の UI（カスタムボタン・使用量のバー・帯の区切り・色）の設定を、選ぶだけの定型の口（ui.json）で持ち、検証済みの値をエージェントの中の拡張へ届ける（claude_mod_ui）
• この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）（追跡: #975）
  • ctx% が閾値を超えたら自分で引き継ぐ（#749）（master_auto_handoff）
  • 回線が戻ったら、接続エラーで止まったセッションへ続きを送ってすぐ再開する（#2112）（network_autoresume）
• codex にも remote-control（experimental）はあるが、これは自前で app-server デーモンを立てて websocket + bearer トークンで TUI を繋ぐ形で、ベンダー側のスマホアプリへ会話を出すものではない。tako 側の配線も無い（追跡: #1059）
  • 会話をベンダー公式のリモート操作（スマホアプリ / Web）へ委譲できる（#1068）（remote_control）
• 手段は揃っているが実機で確かめていない（claude で先行実装した）（追跡: #975）
  • 引き継ぎを書かせてセッションを交代する（#1067。ペインの右クリック / tako session-restart --mode handoff）（session_restart_handoff）
• tako の実装が claude 専用で、この系統への配線がまだ無い（追跡: #975）
  • 会話を保ったまま CLI プロセスだけ建て直す（#1067。CLI の自動更新に追いつく手段）（session_restart_harness）
  • 過去の会話を復元して続ける（tako sessions resume）（sessions_resume）
  • 起動直後の Bypass 確認ダイアログを事前に承諾しておく（#407）（worker_bypass_preaccept）
  • 突然死を検知して復旧コマンドを提示する（#390）（worker_death_resume）
• この系統でログイン失効時に画面へ何が出るかを実物で採れていない（#757 の 3 文言は claude の実観測。推測の文言は置かない）（追跡: #975）
  • アカウントのログイン失効で止まったことを検知する（#757）（worker_login_expired_detect）

対象外（3 件）

• codex の CLI には上限解除を待って自分で続行する仕組みが無い（止まったままなので tako 側のナッジが唯一の再開手段）
  • エージェント CLI 自身が上限解除後に続行する（同じプロセスが生き続けているあいだだけ。#1140）（limit_autocontinue_upstream）
• 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い
  • 画面を介さずに指示を直送する（生成中でも取りこぼさない。#790）（worker_delivery_peer）
• モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.<agent>.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる
  • claude 語彙で書かれたモデル / effort の既定（プロファイルの worker_model / アカウントの default_model）を worker へ継承する（#1013）（worker_model_default_inherit）

Antigravity CLI を選ぶと落ちるもの

対応 24 / 66 件。以下は Claude Code との差分です（同じ理由のものはまとめています）。

一部対応（6 件）

• tako の実装が claude 専用で、この系統への配線がまだ無い
  • 画面で確かめられない送達を、諦める前に受け手の会話記録で確かめる（#2330）（prompt_delivery_receipt）
• spawn の記録は残るが、会話の実体を索引できないので pending のまま期限切れで消える
  • 会話がセッションカタログに索引される（#112）（sessions_catalog）
• 認証の有無は分かるがプランを取れないので、推奨プロファイルの規模を決められない
  • setup が認証済みかどうかを判定できる（setup_auth_check）
• worker としてのプロファイルは作れるが、master には別系統が自動で選ばれる
  • setup が起動プロファイルを組み立てる（setup_profile_recommend）
• 宣言したモデルだけを返す。実際に使われたモデルは読まない（model_actual は null・model_check は not_observed）ので、CLI が別のモデルへ解決しても食い違いの警告は出ず、ledger も宣言のモデルで集計される
  • worker が実際に使ったモデルを確かめ、宣言との食い違いを知らせる（#1638）（worker_model_actual）
• 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない
  • 作業フォルダを起動前に信頼済みにしておく（信頼ダイアログで止まらない）（worker_trust）

未対応（24 件）

• 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない（追跡: #975）
  • アカウント（資格情報）の切替に追従する（account_switch）
• この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）（追跡: #1885）
  • エージェントの画面の中（プロンプトの上の帯 1 行・/tako のサイドバー・入力欄の下の行の使用制限 / ctx のバー）に tako のペイン・タブ・worker と要注意の数を出す。利用者の他の拡張の帯は消さない（claude_mod_band）
  • エージェントの画面の中（プロンプトの上の帯）に定型のカスタムボタン（既定は /compact。組み込みコマンド・tako の操作・新しいペインで実行するコマンド・入力欄へ入れる文）を描き、キーで押して実行する（claude_mod_buttons）
  • AI が出したコマンドカードをエージェントの画面の中（会話の行と入力欄の上の帯）に描き、キーでコピー / 新しいペインで実行する（描いたカードはペイン下のカード帯に出さない = 画面が縮まない）（claude_mod_cards）
  • チャット風の描画（発言の吹き出し・コードブロックのコピー・ツール呼び出しの 1 行の要約）をエージェントの画面の中に描く（ターミナル表示では既定でコードのコピーだけ。GUI モードで選べば tako のチャットビューの代わりにその画面を見せる）（claude_mod_chat）
  • tako setup がエージェントの設定 dir ごとに tako の拡張を入れる（管理印つき・同名の他の拡張があれば入れない・tako mod uninstall で外せる）（claude_mod_install）
  • エージェントの中で動く拡張（tako mod）から ctx・使用制限・ターン・権限待ちを構造で受け取る（claude_mod_state）
  • エージェントの画面の中の UI（カスタムボタン・使用量のバー・帯の区切り・色）の設定を、選ぶだけの定型の口（ui.json）で持ち、検証済みの値をエージェントの中の拡張へ届ける（claude_mod_ui）
• agy は worker 専用で、master / solo としては起動前にエラーになる（#127）（追跡: #987）
  • ctx% が閾値を超えたら自分で引き継ぐ（#749）（master_auto_handoff）
  • master の引き継ぎ（後任の spawn と管轄の受け渡し）が通る（master_handoff）
  • master オーケストレーターとして起動する（tako master）（master_launch）
  • master が tako の MCP ツール群を呼べる（master_mcp）
  • master の system prompt がモデルへ届く（master_system_prompt）
  • 引き継ぎを書かせてセッションを交代する（#1067。ペインの右クリック / tako session-restart --mode handoff）（session_restart_handoff）
  • 1 対 1 対話の solo として起動する（tako solo）（solo_launch）
• agy の実況ログ（brain/<id>/.system_generated/logs/transcript.jsonl）には codex の token_count に相当するトークン数が無く、残量は対話の画面にも常時出ないので読む口が無い（#1033 で agy 1.1.27 の全ステップ種別を確認）（追跡: #975）
  • コンテキスト残量を画面から読み取れる（master_ctx_percent）
• この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）（追跡: #975）
  • 回線が戻ったら、接続エラーで止まったセッションへ続きを送ってすぐ再開する（#2112）（network_autoresume）
• tako の実装が claude 専用で、この系統への配線がまだ無い（追跡: #975）
  • 会話を再開するとき、元の起動と同じ引数（モデル・effort・system prompt・許可モード・Remote Control）で立てる（#1967）（resume_launch_args）
  • 会話を保ったまま CLI プロセスだけ建て直す（#1067。CLI の自動更新に追いつく手段）（session_restart_harness）
  • 過去の会話を復元して続ける（tako sessions resume）（sessions_resume）
  • 起動直後の Bypass 確認ダイアログを事前に承諾しておく（#407）（worker_bypass_preaccept）
  • 突然死を検知して復旧コマンドを提示する（#390）（worker_death_resume）
• agy のトークン数は会話の保管庫（conversations/<id>.db = SQLite の gen_metadata の行）にしか無く、実況ログには無い。tako は SQLite を読む依存を持たない（#984 の判断）ので、依存の可否を #2205 で調べる（追跡: #2205）
  • 会話記録の使用量（トークン・API 換算）をプロジェクト・Issue・会話ごとに集計する（#2201）（usage_tokens）
• この系統でログイン失効時に画面へ何が出るかを実物で採れていない（#757 の 3 文言は claude の実観測。推測の文言は置かない）（追跡: #975）
  • アカウントのログイン失効で止まったことを検知する（#757）（worker_login_expired_detect）

対象外（12 件）

• agy はクレジットを使い切っても「解除を待つ」出口が無い（買い足す導線しか無い）ので、待って再開するという動作が成立しない（#985）
  • エージェント CLI 自身が上限解除後に続行する（同じプロセスが生き続けているあいだだけ。#1140）（limit_autocontinue_upstream）
  • 利用上限の解除後に自分で再開する（#813）（worker_limit_autoresume）
• agy の残量は前払いの AI クレジット残高で、5h / 週のような枠とリセット時刻が無い。残高も対話の /credits モーダルの中にしか出ないので、worker の画面を乱さずに読む口が無い（#985 で agy 1.1.22 を再調査）
  • ステータスバーの利用制限表示をこの系統へ切り替えられる（#217 / #357）（limit_service_switch）
  • 観測した利用制限（5h / 7d）の % の増分を、区間の使用量の比でプロジェクト・Issue・会話へ配る（#2202）（usage_limit_share）
  • 利用上限で止まったことを検知する（worker_limit_detect）
  • 利用制限の残量（%）を取り出す（#357）（worker_limit_metrics）
• agy の --help 全件（フラグ 24 / サブコマンド 11）にリモート操作の口が無い（mic-serve はマイクを別ホストへ配るだけ）ので、会話を外の端末から操作する手段がそもそも無い
  • 会話をベンダー公式のリモート操作（スマホアプリ / Web）へ委譲できる（#1068）（remote_control）
• agy はプラン情報を出さないので検出できない
  • setup が契約プランを検出して推奨規模を決める（setup_plan_detect）
• 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い
  • 画面を介さずに指示を直送する（生成中でも取りこぼさない。#790）（worker_delivery_peer）
• 起動ごとに MCP を絞る手段が CLI に無い（agy 1.4.7 の --help に -c / --mcp-config / --settings が無い。agy mcp disable は利用者自身の agy の設定を書き換えるので使わない）
  • worker を tako の MCP だけで起動し、利用者の設定の MCP サーバーを持ち込まない（要るものはプロジェクトの mcp_servers で足す。#2412 / #2418）（worker_mcp_scope）
• モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.<agent>.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる
  • claude 語彙で書かれたモデル / effort の既定（プロファイルの worker_model / アカウントの default_model）を worker へ継承する（#1013）（worker_model_default_inherit）
• 実行の拒否が会話の作成前に起こるので、作業を 1 歩も始めていないことを実況ログで直接は確かめられない（#1034 の実物では拒否の時点で会話がまだ無い）。代わりに「会話が 1 件も解決できない」ことを作業ゼロの代理の証拠として使う
  • 実行拒否と判定する前に「作業を 1 歩も始めていない」ことの直接の証拠（一次シグナルの実観測）を要求できる（#1295）（worker_refusal_work_proof）

Local LLM でまだ使えないもの

対応 0 / 66 件。この系統が成立したときに埋まるマスの一覧です（同じ理由のものはまとめています）。

未対応（54 件）

• ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）（追跡: #990）
  • アカウント（資格情報）の切替に追従する（account_switch）
  • worker を立てるときに系統を選べる（設定の書き換えや再起動なしで）（agent_select_at_spawn）
  • thinking / reasoning effort を tako から指定する（effort_control）
  • コンフリクト解消エージェントとして起動する（#496）（git_resolve_agent）
  • ステータスバーの利用制限表示をこの系統へ切り替えられる（#217 / #357）（limit_service_switch）
  • 回線が戻ったら、接続エラーで止まったセッションへ続きを送ってすぐ再開する（#2112）（network_autoresume）
  • setup が認証済みかどうかを判定できる（setup_auth_check）
  • 未認証なら setup がその系統のログインコマンドを案内する（setup_auth_launch）
  • CLI 自体が入っていない環境へ setup が導入する（#868）（setup_cli_install）
  • setup がこの CLI の導入を検出する（setup_detect）
  • setup が tako の MCP サーバーをこの CLI へ恒久登録する（setup_mcp_register）
  • setup でモデルを選んでプロファイルへ反映できる（一覧は CLI から実取得し、一覧コマンドを持たない系統は同梱の既知リスト + 取得不可の明示。#1002）（setup_model_picker）
  • setup が起動プロファイルを組み立てる（setup_profile_recommend）
  • 会話記録の使用量（トークン・API 換算）をプロジェクト・Issue・会話ごとに集計する（#2201）（usage_tokens）
  • worker が実際に使ったモデルを確かめ、宣言との食い違いを知らせる（#1638）（worker_model_actual）
  • worker として起動できる（worker_spawn）
• ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）（追跡: #991）
  • エージェントの画面の中（プロンプトの上の帯 1 行・/tako のサイドバー・入力欄の下の行の使用制限 / ctx のバー）に tako のペイン・タブ・worker と要注意の数を出す。利用者の他の拡張の帯は消さない（claude_mod_band）
  • エージェントの画面の中（プロンプトの上の帯）に定型のカスタムボタン（既定は /compact。組み込みコマンド・tako の操作・新しいペインで実行するコマンド・入力欄へ入れる文）を描き、キーで押して実行する（claude_mod_buttons）
  • AI が出したコマンドカードをエージェントの画面の中（会話の行と入力欄の上の帯）に描き、キーでコピー / 新しいペインで実行する（描いたカードはペイン下のカード帯に出さない = 画面が縮まない）（claude_mod_cards）
  • チャット風の描画（発言の吹き出し・コードブロックのコピー・ツール呼び出しの 1 行の要約）をエージェントの画面の中に描く（ターミナル表示では既定でコードのコピーだけ。GUI モードで選べば tako のチャットビューの代わりにその画面を見せる）（claude_mod_chat）
  • tako setup がエージェントの設定 dir ごとに tako の拡張を入れる（管理印つき・同名の他の拡張があれば入れない・tako mod uninstall で外せる）（claude_mod_install）
  • エージェントの中で動く拡張（tako mod）から ctx・使用制限・ターン・権限待ちを構造で受け取る（claude_mod_state）
  • エージェントの画面の中の UI（カスタムボタン・使用量のバー・帯の区切り・色）の設定を、選ぶだけの定型の口（ui.json）で持ち、検証済みの値をエージェントの中の拡張へ届ける（claude_mod_ui）
  • ctx% が閾値を超えたら自分で引き継ぐ（#749）（master_auto_handoff）
  • コンテキスト残量を画面から読み取れる（master_ctx_percent）
  • master の引き継ぎ（後任の spawn と管轄の受け渡し）が通る（master_handoff）
  • master オーケストレーターとして起動する（tako master）（master_launch）
  • master が tako の MCP ツール群を呼べる（master_mcp）
  • master の system prompt がモデルへ届く（master_system_prompt）
  • 画面で確かめられない送達を、諦める前に受け手の会話記録で確かめる（#2330）（prompt_delivery_receipt）
  • 会話をベンダー公式のリモート操作（スマホアプリ / Web）へ委譲できる（#1068）（remote_control）
  • PC 再起動（tmux サーバーごと消える）後の復元で会話ごと戻る（#1238）（restore_after_reboot）
  • 会話を再開するとき、元の起動と同じ引数（モデル・effort・system prompt・許可モード・Remote Control）で立てる（#1967）（resume_launch_args）
  • 引き継ぎを書かせてセッションを交代する（#1067。ペインの右クリック / tako session-restart --mode handoff）（session_restart_handoff）
  • 会話を保ったまま CLI プロセスだけ建て直す（#1067。CLI の自動更新に追いつく手段）（session_restart_harness）
  • 会話がセッションカタログに索引される（#112）（sessions_catalog）
  • 過去の会話を復元して続ける（tako sessions resume）（sessions_resume）
  • 共通ルールをこの CLI のグローバル指示ファイルへ同期する（#136）（setup_rules_sync）
  • 1 対 1 対話の solo として起動する（tako solo）（solo_launch）
  • worker ペインの中から tako CLI で tako を操作できる（worker_cli_control）
  • 突然死を検知して復旧コマンドを提示する（#390）（worker_death_resume）
  • 背景作業（背景シェル・Monitor 等）が残っていても、ターンが終わって入力待ちになったことを検知する（#1273）（worker_idle_with_background）
  • worker が tako の MCP ツール群を呼べる（worker_mcp）
  • worker を tako の MCP だけで起動し、利用者の設定の MCP サーバーを持ち込まない（要るものはプロジェクトの mcp_servers で足す。#2412 / #2418）（worker_mcp_scope）
  • 初期プロンプトが送達確認つきで届く（#32 / #530）（worker_prompt_delivery）
  • プロンプトが届かなかったことを検知して再送手段を出す（#390 / #530）（worker_prompt_undelivered）
  • 画面の履歴から報告を取れる（#364 の第 1 層）（worker_report_scrollback）
  • 構造化された会話ログから報告を取れる（#364 の第 2 層 / --messages）（worker_report_transcript）
  • 作業中か終わったかを判定する（worker_status_detect）
  • 画面に依らない一次シグナルで状態を取れる（claude agents --json 相当）（worker_status_structured）
• ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）（追跡: #991）
  • 起動直後の Bypass 確認ダイアログを事前に承諾しておく（#407）（worker_bypass_preaccept）
  • 選択肢ダイアログを構造として読み、番号やラベルで応答する（#748）（worker_choice_dialog）
  • permission ダイアログを検知して応答する（#319 / #577）（worker_permission_dialog）
• ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）（追跡: #990）
  • 作業フォルダを起動前に信頼済みにしておく（信頼ダイアログで止まらない）（worker_trust）

対象外（12 件）

• 自分のマシンで動かすモデルなので利用上限という概念が無い
  • エージェント CLI 自身が上限解除後に続行する（同じプロセスが生き続けているあいだだけ。#1140）（limit_autocontinue_upstream）
  • 観測した利用制限（5h / 7d）の % の増分を、区間の使用量の比でプロジェクト・Issue・会話へ配る（#2202）（usage_limit_share）
  • 利用上限の解除後に自分で再開する（#813）（worker_limit_autoresume）
  • 利用上限で止まったことを検知する（worker_limit_detect）
  • 利用制限の残量（%）を取り出す（#357）（worker_limit_metrics）
• ローカルモデルに契約プランという概念が無い
  • setup が契約プランを検出して推奨規模を決める（setup_plan_detect）
• 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い
  • 画面を介さずに指示を直送する（生成中でも取りこぼさない。#790）（worker_delivery_peer）
• 自分のマシンで動かすモデルなので、座席種別・クレジット・組織ポリシーという概念が無い（阻害される権利がそもそも存在しない）
  • 時間では解けない利用阻害で止まったことを検知する（#1106）（worker_entitlement_detect）
• 自分のマシンで動かすモデルなので、ベンダーへのログインとその失効という概念が無い（失効する資格情報がそもそも存在しない）
  • アカウントのログイン失効で止まったことを検知する（#757）（worker_login_expired_detect）
• モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.<agent>.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる
  • claude 語彙で書かれたモデル / effort の既定（プロファイルの worker_model / アカウントの default_model）を worker へ継承する（#1013）（worker_model_default_inherit）
• 自分のマシンで動かすモデルなので、アカウントや座席の確認で実行を断られるという事象が起こらない（断る主体がそもそも存在しない）
  • 「起動も送達も成立したのに実行を断られた」停止を、完了ではなく error として検知する（#1034）（worker_refusal_detect）
  • 実行拒否と判定する前に「作業を 1 歩も始めていない」ことの直接の証拠（一次シグナルの実観測）を要求できる（#1295）（worker_refusal_work_proof）

セットアップ

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
setup がこの CLI の導入を検出する setup_detect	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: setup.rs の SetupAgent が 3 系統を列挙し、platform::exe::find（B16）で解決する
setup が認証済みかどうかを判定できる setup_auth_check	対応	対応	一部対応 認証の有無は分かるがプランを取れないので、推奨プロファイルの規模を決められない	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: tako-cli/src/setup.rs のプラン解決は認証済み・導入済みの provider だけを巡る （#262）。agy は provider としてプランを返さない
未認証なら setup がその系統のログインコマンドを案内する setup_auth_launch	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #989: setup_bootstrap::auth_instructions_for が claude = claude auth login / codex = codex login / agy = 引数なしの agy を案内する（agy は専用の ログインサブコマンドを持たず、公式 docs の sign-in も引数なし起動）。ログイン自体はブラウザ操作が要るので tako は 3 系統とも代行しない（#1129）
setup が契約プランを検出して推奨規模を決める setup_plan_detect	対応	対応	対象外 agy はプラン情報を出さないので検出できない	対象外 ローカルモデルに契約プランという概念が無い	コード本文: setup.rs の Provider は Claude / Gpt / Google の 3 値だが、プラン取得は claude / gpt の 2 経路しか実装が無い（#226）
CLI 自体が入っていない環境へ setup が導入する（#868） setup_cli_install	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #989: platform/agent_install.rs の recipe() が 3 系統 × 2 プラットフォームぶんの 公式手順を持ち、まっさら HOME + PATH 剥ぎで 3 系統とも tako setup bootstrap install が通る（実測）。Windows の実行代行は claude だけ （codex / agy は can_run=false = 状態照会と案内まで。#525）
setup が起動プロファイルを組み立てる setup_profile_recommend	対応	対応	一部対応 worker としてのプロファイルは作れるが、master には別系統が自動で選ばれる	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: setup.rs は選択した agent を worker_agent へ書くが、master_agent は claude / codex しか受け付けない（agy は起動前エラーになるため）
共通ルールをこの CLI のグローバル指示ファイルへ同期する（#136） setup_rules_sync	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: agents_sync.rs の AgentKind が 3 系統ぶんの書き先を持つ （~/.claude/CLAUDE.md / ~/.codex/AGENTS.md / ~/.gemini/GEMINI.md）
setup が tako の MCP サーバーをこの CLI へ恒久登録する setup_mcp_register	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #979（main の 63a7c26）で tako setup-mcp が 3 系統へ登録するようになった。書き先は claude = ~/.claude.json / codex = ~/.codex/config.toml の [mcp_servers.tako] / agy = ~/.gemini/config/mcp_config.json で、codex は env_vars 許可リストまで足して実セッションから tako_list_panes が通ることを実測。正本は tako-control::agent_mcp
setup でモデルを選んでプロファイルへ反映できる（一覧は CLI から実取得し、一覧コマンドを持たない系統は同梱の既知リスト + 取得不可の明示。#1002） setup_model_picker	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1002 の実測（2026-08-27）: codex 0.150.1 は codex debug models が Render the raw model catalog as JSON で slug / display_name / supported_reasoning_levels / context_window を返す（未認証でも既定カタログ、 認証すると内容が変わる）。agy 1.1.22 は agy models が id<TAB>表示名 の TSV を stdout へ返し未認証は exit 1 + Please sign in to view available models.。 claude 2.1.232 は該当サブコマンドが無く claude models はプロンプトとして 解釈される（一覧はセッション内の /model のみ）

オーケストレーター（master / solo）

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
master オーケストレーターとして起動する（tako master） master_launch	対応	対応	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/mod.rs の build_master_cmd_in は claude / codex で分岐し、agy は unreachable!() で到達しない（#127 の設計判断。前提の再評価は #987）
1 対 1 対話の solo として起動する（tako solo） solo_launch	対応	対応	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: solo は master と同じ build_master_cmd_in を通るので、agy は同じ理由で 起動前にエラーになる（#111 / #127）
master の system prompt がモデルへ届く master_system_prompt	対応	対応	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: claude は —append-system-prompt-file、codex は developer_instructions で注入する （orchestrator/mod.rs）。agy の注入手段（custom agent 定義の起動時選択）は 公式ドキュメントに記載が無く #987 で実機確認する
master が tako の MCP ツール群を呼べる master_mcp	対応	対応	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/mod.rs が codex へ -c mcp_servers.tako.* を起動時に一時注入する （恒久登録はしない = tako 外の codex にツールを出さない。FR-2.3.2）
master の引き継ぎ（後任の spawn と管轄の受け渡し）が通る master_handoff	対応	対応	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: handoff の後任は build_master_cmd_in（orchestrator/mod.rs）を通るので master が起動できる系統では通る。agy はその関数に到達しない
ctx% が閾値を超えたら自分で引き継ぐ（#749） master_auto_handoff	対応	未対応 #975 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: #749 の発火材料は画面由来の ctx%。codex 側のパターンは terminal.rs にあるが 採取 fixture が無く、実際に描画されるかは未確認（棚卸し §10 の 2 番）
コンテキスト残量を画面から読み取れる master_ctx_percent	対応	一部対応 worker の状態照会では構造化ソースから ctx% が取れるが、master の自動ハンドオフは画面のパターンを見るので master 経路では未確認	未対応 #975 agy の実況ログ（brain/<id>/.system_generated/logs/transcript.jsonl）には codex の token_count に相当するトークン数が無く、残量は対話の画面にも常時出ないので読む口が無い（#1033 で agy 1.1.27 の全ステップ種別を確認）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #984: rollout の token_count に last_token_usage.total_tokens と model_context_window があり、worker_status の ctx_percent へ載せた（実測で 8%）。master の #749 は terminal.rs の画面パターンを見る別経路なのでそこは未確認。#1033: agy の実況 JSONL は状態と発話を持つがトークン数は持たない。#1880（claude）: tako mod の報告があれば一次ソース（ctx_source=mod。窓も claude が答える）、無ければ画面 → transcript。statusLine を外した実 claude で 4 経路が mod を返し、報告を止めると 45 秒後に落ちて ctx_mod_reason=mod_stale が出た（scripts/test-mod-primary-1880.sh）

worker の起動

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
worker として起動できる worker_spawn	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/agent.rs の build_worker_cmd_in が唯一の組み立て口で、effort / 権限スキップ / role 注入の 3 点だけを系統別に分岐する
worker を立てるときに系統を選べる（設定の書き換えや再起動なしで） agent_select_at_spawn	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/agent.rs の WorkerAgent が spawn 引数・プロファイルの両方から 解決され、build_worker_cmd_in が 3 系統ぶんのコマンドを組む。ペイン単位・タスク単位の切替導線は #988
作業フォルダを起動前に信頼済みにしておく（信頼ダイアログで止まらない） worker_trust	対応	一部対応 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない	一部対応 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない	未対応 #990 ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）	コード本文: orchestrator/agent.rs の ensure_trusted_in が 3 系統ぶん書き分けてある （claude = <config dir>/.claude.json / codex = ~/.codex/config.toml / agy = ~/.gemini/antigravity-cli/settings.json）。claude 以外は固定パス
起動直後の Bypass 確認ダイアログを事前に承諾しておく（#407） worker_bypass_preaccept	対応	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）	コード本文: dispatch.rs の事前承諾は 2 箇所とも WorkerAgent::Claude を条件にしている。codex / agy は default_skip_permissions() が true なので常に skip 側なのに 事前承諾が無い（棚卸し §1.3(c)）
thinking / reasoning effort を tako から指定する effort_control	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1002 の実測（agy 1.1.22）: --effort（low|medium|high） が —help に実在し、agy models が挙げる 6 モデルすべてで不正値が invalid --effort "bogus" (valid: low, medium, high) として咎められる = 表示名に “(High)” 等を含むモデルでも —effort の検証が走る。正しい組み合わせは 検証を通り API 呼び出しへ進む。未知のモデル名のときだけ --effort is not supported for model "…" になる（この文言を「agy は effort 非対応」と 読み違えないこと）。orchestrator/agent.rs は claude = —effort / codex = -c model_reasoning_effort= / agy = —effort へ写像する（旧挙動は TAKO_1002_LEGACY=1）
アカウント（資格情報）の切替に追従する account_switch	対応	未対応 #975 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない	未対応 #975 設定ファイルの場所が固定なので、tako のアカウント切替がこの系統には効かない	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/agent.rs の事前信頼は claude だけ CLAUDE_CONFIG_DIR（#512 / #558）を 見て書き先を決め、codex は ~/.codex/config.toml、agy は ~/.gemini/antigravity-cli/settings.json を固定で開く（同ファイルのコメントが明示）
claude 語彙で書かれたモデル / effort の既定（プロファイルの worker_model / アカウントの default_model）を worker へ継承する（#1013） worker_model_default_inherit	対応	対象外 モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.&lt;agent&gt;.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる	対象外 モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.&lt;agent&gt;.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる	対象外 モデル名はベンダー固有の語彙なので claude 用の既定を渡せない（渡すと存在しないモデル名で起動する）。この系統のモデルは worker_agents.&lt;agent&gt;.model か spawn の明示指定で決め、無ければ CLI の既定に委ねる	実測: #1013 の実発生: profile（worker_model: claude-opus-5）+ アカウント（default_model: claude-opus-5）の master が agent=codex・model 省略で spawn した 結果、codex --model claude-opus-5 … が組み立てられ、codex がモデル警告の画面で 止まってプロンプトも届かなかった。orchestrator/mod.rs の resolve_agent_launch は claude 以外へ profile の worker_model を渡さない設計だったが、アカウントの default_model が spawn の明示指定と同じ段に混ざっていた

worker の監視

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
作業中か終わったかを判定する worker_status_detect	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #984: codex は構造化ソース（codex-session）を得たので need_streak が 8 → 3 に なり claude と同じ確定速度になる。同一タスクの A/B 実測（primes 25 個）で before = source=screen / ctx=None / 開始前の t=3s・6s に idle を出す、after = t=9s から source=codex-session で busy を 2 標本とも捉え t=15s から idle + ctx=8。#1033: agy も実況 JSONL（agy-session）を得て need_streak が 8 → 3 になった。北極星と同じ測り方の A/B 実測（同一タスク・各 3 標本・TAKO_1033_LEGACY での同一バイナリ A/B）で検知遅延の中央値が 39.46s（38.25 / 39.46 / 41.49）→ 13.92s（13.30 / 13.92 / 14.04）。claude 15.40s / codex 11.68s と同水準で、旧側は北極星の 39.38s を再現する。偽 idle（回答前に単発 status が idle を返す最早時刻）は 3.5〜6.1s → 4.3〜5.7s で増えておらず、watch の偽イベントは 6 ラウンドとも 0 件。(Thinking) 型の誤爆（#120）は弱マーカーの agent 別分離で構造的に起こらない。#1880（claude）: tako mod の報告があれば turn を一次ソースにする（status_source=mod）。無い・古い・止まったら claude agents —json → 画面へ落ちる。#2017: 報告が 20 秒以内（heartbeat 15 秒 + 余裕）で会話 ID を持てば claude agents —json を起こさない（応答の agents_scan.skipped）。完了・権限待ち・idle の判定は同じ報告の turn と画面の補正のままで変わらない
画面に依らない一次シグナルで状態を取れる（claude agents --json 相当） worker_status_structured	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #984 で codex-cli 0.150.1 を実物調査: $CODEX_HOME/sessions/ の rollout JSONL に task_started / task_complete が逐次書かれる（250 語生成を 1 秒刻みで観測: t=1s 開始 → t=27s 完了）。tako は status_source=codex-session として読む。#1033 で agy 1.1.27 を実物調査: 会話ごとの brain/<id>/.system_generated/logs/transcript.jsonl が逐次追記され、画面に答えが出た時刻と終端 PLANNER_RESPONSE が書かれた時刻が同一標本 （0.2 秒ポーリングで差 0.00 秒）。tako は status_source=agy-session として読む。ペイン → 会話は生きた agy が開いたままの brain/<id> を lsof で引く （codex の thread-writer-locks と同じ形）。claude の一次シグナルは #1880 / #2017 から tako mod の報告（会話 ID・turn・モデル・ctx）: 新しい報告（20 秒以内）があるペインは claude agents —json を起こさない。走査は mod の 無い・古い・止まった claude だけで、起こすのもその claude が居る config dir（台帳 <config dir>/sessions/<pid>.json で絞る）と既定だけ・ログインシェルを経由しない。本番 v0.8.31 の実測で走査は 1 分 60 本（4 アカウント × 15 回）・回収済みの子の CPU 24.4%
背景作業（背景シェル・Monitor 等）が残っていても、ターンが終わって入力待ちになったことを検知する（#1273） worker_idle_with_background	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: 3 系統とも検知できるが経路が違う。claude（#1273・2026-09-09 実測）: 2.1.258 の agents --json は isLoading || delegatedActive ? "busy" : "idle" で 状態を決め、背景シェル / Monitor が生きているあいだ busy を返し続けるので、tako は画面の状態行 · &lt;内訳&gt; still running を根拠に idle へ倒す （この行は claude 自身がターンが終わっているときだけ継ぎ足し、完了を待って止まっているあいだは Waiting for … to finish になる = 「終わった」と「待っている」を取り違えない）。codex / agy（#1277・2026-09-11 実測）: 一次シグナルが張り付かないので覆す必要が無い。隔離 tmux 上の実 CLI に背景作業を残したままターンを終わらせたところ、codex-cli 0.154.0 は背景ターミナル（sleep 600）が生きたまま rollout へ task_complete を書き（read_turn_state → idle）、Antigravity CLI 1.2.0 も背景タスクが生きたまま実況 JSONL の終端へ MODEL/PLANNER_RESPONSE（status=DONE・tool_calls なし）を書いた （read_turn_state → idle）。どちらの画面も screen_looks_busy=false / screen_looks_idle=true なので idle が覆されない。両系統は背景作業を画面へ申告もする（codex = 1 background terminal running · /ps to view · /stop to close / agy = フッターの · 1 task(s) · /tasks）ので worker_status の background_work はその内訳を返すが、この申告は生成中も同じ形で出る （#120 / #1015 の採取）ため claude と違ってターン終了の根拠には使わない （wait::declaration_implies_turn_end）。claude の入力欄は属性で読む（#1297・2026-09-09 本番観測）: claude は空欄へ AI のゴースト提案を dim で描くので、文字列だけで「空か」を見ると提案が 人の下書きに見えて覆せない（本番 pane 1636 / 1761 / 1775 / 1784 が永久 busy）。判定は read_pane の input_status.style と同じ 1 実装 （screen::analyze_input_line）を通し、ghost / none は下書きなし・user / mixed は下書きありとして扱う。属性の取れない素の tmux capture では 従来の文字列判定へ落ち、worker_status の idle_override_blocked に input_draft_unreadable を残す
worker が実際に使ったモデルを確かめ、宣言との食い違いを知らせる（#1638） worker_model_actual	対応	一部対応 宣言したモデルだけを返す。実際に使われたモデルは読まない（model_actual は null・model_check は not_observed）ので、CLI が別のモデルへ解決しても食い違いの警告は出ず、ledger も宣言のモデルで集計される	一部対応 宣言したモデルだけを返す。実際に使われたモデルは読まない（model_actual は null・model_check は not_observed）ので、CLI が別のモデルへ解決しても食い違いの警告は出ず、ledger も宣言のモデルで集計される	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: orchestrator/registry.rs の model_actual は claude の transcript（最初の assistant 行の message.model）からだけ埋まる（observe_pending_models / observe_worker_model）。codex の rollout・agy の実況 JSONL からモデルを読む配線は無いので、宣言だけを返し model_check は not_observed になる
プロンプトが届かなかったことを検知して再送手段を出す（#390 / #530） worker_prompt_undelivered	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	テスト: #983 の変更 2 で prompt_delivery_assessment の判断を delivery_observation （このマトリクスの WORKER_STATUS_STRUCTURED）から引く形にした。codex は rollout の task_started を送達の証拠にできるので claude と同じく未達を断定し、agy は画面確認しか 無いので未達ではなく unverified（+ verify_then_resend）を返す。緑のテスト: registry の「一次シグナルの無い系統は未達と断定せず未確認を返す」「送達の観測手段はマトリクスから引く」「ターンが走った証拠は画面検証の失敗より強い」/ dispatch の「issue983_観測手段の無い系統でも送達判定が黙らない」
突然死を検知して復旧コマンドを提示する（#390） worker_death_resume	対応	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: registry.rs の resume_command はコメントどおり claude のみ （案内 tako orchestrator resume <worker_id> が spawn と同じ組み立てで claude —resume を組む。#2470）
回線が戻ったら、接続エラーで止まったセッションへ続きを送ってすぐ再開する（#2112） network_autoresume	対応	未対応 #975 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #975 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #2112（2026-10-15 / claude 2.1.294）: 停止の文言は会話記録の isApiErrorMessage 300 件超の集計と、claude を到達できない API 先（.invalid）へ向けて採った実画面（100 桁 / 32 桁・再試行中・2 回目の停止）から決めた（tako_core::net_resume::connection_error_kind / tako_control::net_stop::detect のテストが実画面をそのまま持つ）。送達は FR-2.27.4 と同じ確認つきの経路で、隔離 GUI の実経路テスト（scripts/test-net-resume-2112.sh）が回線断 → 復帰で worker / master / 退避中の solo へ届き、使用制限・ログイン失効・質問・下書き・ダイアログには届かないことを見る。低いペインで締めの行より上が画面の外の停止（#2181）は、画面の外の直近の行（器の履歴 / 外側の端末の履歴）を足して同じ判定を通す（scripts/test-net-resume-2181.sh が器のペイン・直接のペインの両方で見る）。codex / agy は接続エラーで止まった実画面を採れていない（推測の文言を置かない = #1034 と同じ作法）
「起動も送達も成立したのに実行を断られた」停止を、完了ではなく error として検知する（#1034） worker_refusal_detect	対応	対応	対応	対象外 自分のマシンで動かすモデルなので、アカウントや座席の確認で実行を断られるという事象が起こらない（断る主体がそもそも存在しない）	実測: #1034: 北極星実測（#975）で agy worker がアカウントの適格性の検証待ちに当たり、1 文字も作業していないのに status=idle / prompt_delivery=delivered / WORKER_IDLE（50.07 秒後）を返した。#983 の分類は「まだ送達の証拠が無い worker」に限るゲートを持つので設計どおりその外だった。#1033 で agy が 実況 JSONL を得たので、**送達後でも「MODEL のステップを 1 件も観測して いない」**を条件に分類できるようになった（画面推定の busy は TUI の 起動描画を拾うので根拠にならない）。文言は版で変わる（agy 1.1.22 = Verifying your account... / We're finishing verifying your account eligibility.、1.1.27 = Unable to verify account eligibility. / Eligibility check failed:）ので、両版に共通して残る account eligibility を軸にした。claude 2.1.258 / codex 0.153.0 のバイナリには一時的な検証待ちの文言が 無い（2026-09-09 に実物を走査。eligibility の該当はすべて内部識別子・API パス・models cache の判定で、画面へ出る拒否の文ではない）ので、この 2 系統には判定パターンを宣言していない（execution_refused_patterns が空 = 推測を置かない）。両系統で観測されている拒否の形は未認証 （not_authenticated。#983）と時間で解けない利用阻害 （entitlement_blocked。#1106 / #1107）で、どちらも既に error になる
実行拒否と判定する前に「作業を 1 歩も始めていない」ことの直接の証拠（一次シグナルの実観測）を要求できる（#1295） worker_refusal_work_proof	対応	対応	対象外 実行の拒否が会話の作成前に起こるので、作業を 1 歩も始めていないことを実況ログで直接は確かめられない（#1034 の実物では拒否の時点で会話がまだ無い）。代わりに「会話が 1 件も解決できない」ことを作業ゼロの代理の証拠として使う	対象外 自分のマシンで動かすモデルなので、アカウントや座席の確認で実行を断られるという事象が起こらない（断る主体がそもそも存在しない）	実測: #1034: agy の実物では拒否が CLI の起動直後（会話が作られる前）に出るので、実況 JSONL がまだ無く「作業ゼロ」を直接は観測できない。代わりに会話が 1 件も 解決できないことを代理の証拠にしている（agy_session::resolve_conversation_id_for_backend の解決は sticky なので、一度でも会話を開いたペインは以後ずっと Some(..) を返す = 「解決できない」が durable に言える）。#1295: claude / codex にはこの代理が要らない。両系統で観測されている拒否は 未認証（#983 の detect_launch_failure）と時間で解けない利用阻害（#1106）で、どちらも別の分類が先に error にする。むしろ代理を許すと害がある: claude の腕（dispatch.rs の query_agent_status）は agent_work_started を一度も代入しないので、None を作業ゼロと数えると 正常に働いた worker（status=idle / prompt_delivery=delivered）の画面に 同じ文字列が流れただけで完了を error / retry_spawn へ落とす （#983 が command not found で避けた誤検知と同型）。再現は dispatch::tests::issue1295_claudeの正常完了を実行拒否へ落とさない。local は断る主体がそもそも居ない（worker_refusal_detect と同じ理由）
アカウントのログイン失効で止まったことを検知する（#757） worker_login_expired_detect	対応	未対応 #975 この系統でログイン失効時に画面へ何が出るかを実物で採れていない（#757 の 3 文言は claude の実観測。推測の文言は置かない）	未対応 #975 この系統でログイン失効時に画面へ何が出るかを実物で採れていない（#757 の 3 文言は claude の実観測。推測の文言は置かない）	対象外 自分のマシンで動かすモデルなので、ベンダーへのログインとその失効という概念が無い（失効する資格情報がそもそも存在しない）	実測: #757（2026-08-01 / 08-03 / 08-05 の実観測を 3 回）: claude の worker が OAuth refresh token is no longer valid; run /login to re-authenticate / Login expired · Please run /login / Please run /login を出して止まる。 画面には先に API Error: Unable to connect to API (ENOTFOUND / ECONNRESET) が 出るため、#757 前は api_error（推奨 resume）に分類され、続行ナッジを 何度撃っても復帰しなかった（master が 3 回空回りした）。この 3 文言を orchestrator::agent_cli::login_expired_line（#983 の起動時未認証検知と 同じ正本）で受け、WorkerErrorKind::LoginExpired（relogin）として返す。 対象アカウントは会話（session_id）の transcript の所在から逆引きする （orchestrator::login_expired_account。#652 の resume と同じ根拠）ので、 会話が claude の config ディレクトリに在る系統でしか名指しできない。 codex / agy は失効時の実画面を採れていないので文言を足していない （推測を置かないのは #1034 の execution_refused_patterns と同じ作法）。 実機で失効させる再現はしていない（同一アカウントを別マシンから使った 直後に起きるもので、任意のタイミングでは作れない）ので、検証は実観測の 文言を描いた fixture と隔離 tmux のペインで行った
エージェントの中で動く拡張（tako mod）から ctx・使用制限・ターン・権限待ちを構造で受け取る claude_mod_state	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1879: Claude Code 2.1.294 の mod を env CLAUDE_CODE_PLUGIN_DIRS で注入し、隔離 GUI の直接ペインと tmux ペインの両方で tako mod report が届いて tako mod の行に ctx・使用制限・turn・model が載った（scripts/test-claude-mod-1879.sh）
エージェントの画面の中（プロンプトの上の帯 1 行・/tako のサイドバー・入力欄の下の行の使用制限 / ctx のバー）に tako のペイン・タブ・worker と要注意の数を出す。利用者の他の拡張の帯は消さない claude_mod_band	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1881: Claude Code 2.1.294 の mod（AbovePrompt の帯・$.ui.open のペイン・$.store のトグル）を隔離 GUI のペインと 80 / 144 / 300 桁の隔離 tmux で実 claude に描かせ、帯が 1 行に収まること・ダイアログの後に戻ること・トグルが再起動後も保たれることを画面の capture で確かめた（scripts/test-claude-mod-band-1881.sh）。#1962: 帯は next(e) の答え（他の mod の行）を包む形にし、帯を描く別の mod と読み込み順を入れ替えて両方の行が出ること・PromptHint の末尾のバーが出て同じときにステータスバーの claude の区画が消え報告を止めて 45 秒で戻ること・statusLine が ctx を出す構成では描かないことを一時の設定 dir の実 claude で確かめた（scripts/test-mod-band-buttons-1962.sh）
エージェントの画面の中（プロンプトの上の帯）に定型のカスタムボタン（既定は /compact。組み込みコマンド・tako の操作・新しいペインで実行するコマンド・入力欄へ入れる文）を描き、キーで押して実行する claude_mod_buttons	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1962: 一時の設定 dir の実 Claude Code 2.1.294 で、帯の /compact のボタンを ctrl+x → Tab → ホットキーで押すと会話が圧縮され、tako の操作（split right）のボタンで隔離 GUI のペインが増えた。押した結果（種類と成否）は tako mod の行の report.last_press に出る（scripts/test-mod-band-buttons-1962.sh）。クリックで押すのは tako がクリックを TUI へ渡す #1961 から
AI が出したコマンドカードをエージェントの画面の中（会話の行と入力欄の上の帯）に描き、キーでコピー / 新しいペインで実行する（描いたカードはペイン下のカード帯に出さない = 画面が縮まない） claude_mod_cards	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1963: 一時の設定 dir の実 Claude Code 2.1.294 に偽 Messages API で tako の MCP の tako_show_command を呼ばせ、会話の行のカードと帯の card N / y: copy / r: run が出て、ペインの行数が 0.1 秒おきの採取（47 回）で一度も縮まない（GPUI のカード帯が出ない）こと・帯のキーで Run すると新しいペインと実行記録が付くこと（全画面とmain screen）・Copy が 157 字の論理文字列を改行なしで渡すこと・報告が途切れると 45 秒、claude が終わると 0.2 秒（1 tick 以内）で GPUI の帯へ戻ることを確かめた（scripts/test-mod-command-cards-1963.sh）
チャット風の描画（発言の吹き出し・コードブロックのコピー・ツール呼び出しの 1 行の要約）をエージェントの画面の中に描く（ターミナル表示では既定でコードのコピーだけ。GUI モードで選べば tako のチャットビューの代わりにその画面を見せる） claude_mod_chat	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1964: 一時の設定 dir の実 Claude Code 2.1.294 に偽 Messages API で答えさせ、隔離 GUI の GUI モードでchat.place mod にすると 11〜12 秒（次の報告）でペインがターミナル表示（理由 mod_chat）になり、吹き出し・コードブロックの Copy・ツールの 1 行の要約が描かれ、Copy をクリック・帯の o をキーで押せること・報告が途切れると最後の報告から 45.2 秒、claude が終わると即座に GPUI のチャットへ戻ること・ターミナル表示の既定では吹き出しを描かずコードのコピーだけであること・同じ描画の口を包む他の mod が外側 / 内側のどちらでも両方の描画が残ることを確かめた（scripts/test-mod-chat-1964.sh）
エージェントの画面の中の UI（カスタムボタン・使用量のバー・帯の区切り・色）の設定を、選ぶだけの定型の口（ui.json）で持ち、検証済みの値をエージェントの中の拡張へ届ける claude_mod_ui	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	テスト: #1960: tako_core::claude_mod_ui の単体（語彙の外の値は書かずに許される値を返す・ランダムな操作列 1,000 通りで常に形を満たす・壊れた ui.json は読める部分で動き .unreadable.bak へ保全）、dispatch の issue1960_*（報告の応答の tako.view.ui に検証済みの値が載り、変更が次の報告で届く）、issue1960_mod_ui_watchdog（CLI / MCP / setup の 3 つの口で ui.json が字面で一致）。mod が効かせるのは今は帯のトグルで、ボタン・バー・区切り・色の描画は #1962
tako setup がエージェントの設定 dir ごとに tako の拡張を入れる（管理印つき・同名の他の拡張があれば入れない・tako mod uninstall で外せる） claude_mod_install	対応	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #1885 この系統に同等の手段があるかを実物で調べていない（無いと確定したわけではない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1959: 一時の設定 dir 2 つへ tako setup の段が skills/tako の写しを置き、実物の Claude Code 2.1.294 の claude plugin list に tako@skills-dir（enabled）・デバッグログに hooks module tako@skills-dir が出た。env の注入と同時でも hooks module は tako@inline の 1 つだけ・利用者の skills/tako と別の出どころの 同名 tako には触らない・uninstall で写しだけが消えることを確かめた（scripts/test-mod-skills-1959.sh）

worker への指示と応答

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
初期プロンプトが送達確認つきで届く（#32 / #530） worker_prompt_delivery	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: 第 2 層のキー操作経路（claude_tui::deliver_via_tmux）は 3 系統の入力欄 （❯ / › / >）を見分けるので agent 非依存に動く
画面を介さずに指示を直送する（生成中でも取りこぼさない。#790） worker_delivery_peer	対応	対象外 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い	対象外 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い	対象外 画面を介さない直送は claude の受信箱（Cross-Session Messaging）に固有の仕組みで、他系統には相当物が無い	上流の仕様: 第 1 層は claude の Cross-Session Messaging（受信箱の socket へ直送）に固有。AGENTS.md「worker への指示送達（#790）」も codex / agy / Windows は常に 第 2 層と明記している
画面で確かめられない送達を、諦める前に受け手の会話記録で確かめる（#2330） prompt_delivery_receipt	対応	一部対応 tako の実装が claude 専用で、この系統への配線がまだ無い	一部対応 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #2330（2026-10-20 / claude 2.1.301）: 狭いペイン（54 桁）の claude は入力欄の高さに上限があり、長い本文の先頭と先頭の ❯ 行が画面から流れる。修正前は transcript に本文が入っていても gave_up / paste_not_reflected（mod_turn は busy）だった。送達フローは諦める前に tako_control::delivery_receipt で transcript の利用者の発話 / キュー投函を照合する （scripts/test-handoff-close-2330.sh の deliver 段が実物で delivered / received を見る）。codex / agy は送達そのものは従来どおり通るが、画面で確かめられないときは gave_up のまま （照合は claude の transcript の形だけ）
permission ダイアログを検知して応答する（#319 / #577） worker_permission_dialog	対応	対応	対応	未対応 #991 ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）	コード本文: claude_tui.rs の detect_permission_dialog は 3 系統のパターンを持ち、agy の「Do you want to proceed?」も対象に入っている。#1880（claude）: tako mod の報告があれば権限待ち・質問待ちを先に見るが、答え方（respond）は画面のダイアログを読むので画面の検出を正にし、食い違い（classic_events=false の組織アカウントではルールの無い ask を mod が拾えない）を worker_status の warnings に出す
選択肢ダイアログを構造として読み、番号やラベルで応答する（#748） worker_choice_dialog	対応	対応	対応	未対応 #991 ローカル LLM のハーネスが決まっていないので可否が定まらない（codex TUI を借りる #990 なら在り、非 TUI 経路の #991 なら無い）	コード本文: claude_tui.rs は claude v2.1.198 / codex 0.144.1 / agy 1.1.0 の実採取画面の 和集合として実装され、CODEX_TRUST_DIALOG / AGY_PERMISSION_DIALOG 等の fixture が同ファイルに在る。番号なし・選択肢 2 つ（claude 2.x の信頼 ダイアログ = TRUST_DIALOG_NO_NUMBER）も #1223 で検知対象。claude の auto mode 環境学習の確認（番号つき 3 択の下に空の入力欄が 描かれる形 = TEACH_AUTO_MODE_DIALOG）は #1263 で検知対象
worker ペインの中から tako CLI で tako を操作できる worker_cli_control	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: TAKO_PANE_ID / TAKO_SOCKET / TAKO_TOKEN の注入と PATH 注入（#601）は ペイン単位で agent に依らない
worker が tako の MCP ツール群を呼べる worker_mcp	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #986 の実測（2026-09-09 / 隔離 GUI + tako-vd / codex-cli 0.153.0 / agy 1.1.27）: codex = spawn の起動コマンドへ master と同じ -c mcp_servers.tako.* を一時注入する （正本は orchestrator::agent::codex_mcp_args の 1 実装）。実 worker が tako.tako_list_panes({}) を呼び、pane を省略した tako_set_title が 自分のペインへ当たった。効いているのが一時注入だと分かるのは env の指紋で、 MCP 子プロセスの初期環境は一時注入の 5 個（TAKO_TAB_ID を含む）に対し、 TAKO_986_LEGACY=1 の旧アームでは恒久登録（#979）の 4 個（TAKO_TAB_ID 無し）だった。 agy = per-launch の注入手段が CLI に無い（agy --help 実測 1.1.27: -c / —mcp-config なし）ので 恒久登録（#979）に委ねる。agy は親 env をそのまま渡す（実測: MCP 子が TAKO_* を 15 個受け取る = claude と同じ形）ため、実 worker から pane 省略の tako_set_title が自分のペインへ当たった。 TAKO_PANE_ID が届かない系統でも解けるよう、caller_pane は pid 祖先辿りへ落ちる （tako mcp serve が Request::ResolvePane で問う。#288 / #567 と同じ 1 実装）
worker を tako の MCP だけで起動し、利用者の設定の MCP サーバーを持ち込まない（要るものはプロジェクトの mcp_servers で足す。#2412 / #2418） worker_mcp_scope	対応	対応	対象外 起動ごとに MCP を絞る手段が CLI に無い（agy 1.4.7 の --help に -c / --mcp-config / --settings が無い。agy mcp disable は利用者自身の agy の設定を書き換えるので使わない）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #2412 の実測（2026-10-26 / claude 2.1.301・一時の CLAUDE_CONFIG_DIR + 偽 Messages API + 起動を記録する偽 MCP）: --settings の deniedMcpServers に並べた user scope の名前だけが立たず、.mcp.json（cwd と祖先）と local scope（git の根を鍵にした projects.<path>.mcpServers）は立つ。同名の .mcp.json 側まで止まるので 同名は止めない。--settings を 2 つ渡すと後ろが勝つ。--strict-mcp-config は .mcp.json / local まで止め、--setting-sources project,local は user の settings.json まで落とすので採らない。組み立ては orchestrator::agent::build_worker_cmd（spawn / run / git resolve / 再開）、判断は worker_mcp::prepare の 1 実装。codex は #2418 の実測（2026-10-27 / codex-cli 0.154.0・一時の CODEX_HOME + 偽 Responses API + 起動を記録する偽 MCP）: 起動ごとの -c mcp_servers.&lt;名&gt;.enabled=false で止めた server の子プロセスは立たず、tako の MCP は立つ。config.toml に無い名前を enabled=false だけで渡すと invalid transport で起動しないので、読んだ transport と 同じ種類の目印（stdio = command・http = url）を一緒に渡す（種類を違えると起動しない）。プロジェクトの .codex/config.toml（cwd から git の根まで・信頼済みのフォルダ）と同名の server は、止めるとプロジェクト側まで 止まるので止めない。名前に .・空白を含む server は -c で表せない（付けると起動しない）ので持ち込む。codex の対象は spawn / run / git resolve / 再起動をまたぐ復元。#2447 の実測（2026-10-28 / 隔離 GUI + 実物の codex-cli 0.154.0 + 偽 claude・scripts/test-resume-worker-mcp-2447.sh）: 修正前は GUI を起こし直した復元が codex resume &lt;id&gt; / claude --resume &lt;id&gt; だけで組まれ、spawn の断片（codex 9〜13 個・claude の --settings）が 0 個になり、止めたはずの user 設定の MCP が立っていた。いまは復元とカタログの再開も spawn と同じ worker_mcp::prepare_for_resume（判断）と orchestrator::agent::worker_mcp_args（断片）を通る （codex resume は -c を受ける = 0.154.0 の —help）。agy 1.4.7 は起動ごとの手段が無い

報告と会話ログ

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
画面の履歴から報告を取れる（#364 の第 1 層） worker_report_scrollback	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: 第 1 層は器の capture（capture-pane -p -J -S）なので agent に依らない （dispatch.rs の report が明記）
構造化された会話ログから報告を取れる（#364 の第 2 層 / --messages） worker_report_transcript	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #984 で codex アダプタを実装。rollout JSONL の response_item（role=assistant）を 読むので report --messages N が codex でも実データを返す。応答の transcript_agent でどれを読んだか分かる。#1033 で agy アダプタを追加: 実況 JSONL の PLANNER_RESPONSE で本文を持つ行が発話なので同じく実データを返す （北極星実測では agy だけ messages が 0 件だった）
会話がセッションカタログに索引される（#112） sessions_catalog	対応	一部対応 spawn の記録は残るが、会話の実体を索引できないので pending のまま期限切れで消える	一部対応 spawn の記録は残るが、会話の実体を索引できないので pending のまま期限切れで消える	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: sessions.rs の昇格は claude のセッション検出（transcript）に依存する。3 系統とも spawn 時に pending 記録は作られるが、claude 以外は昇格しない
過去の会話を復元して続ける（tako sessions resume） sessions_resume	対応	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: コマンドの組み立ては #1238 で 3 系統に広がったが、tako sessions resume が引くのはカタログ本体（entries）で、そこへ昇格するのは claude だけ（sessions_catalog 参照）。codex / agy の会話は pending にしか残らないので一覧に出ない。dispatch.rs の実在確認も ~/.claude/projects の transcript 固定
会話を再開するとき、元の起動と同じ引数（モデル・effort・system prompt・許可モード・Remote Control）で立てる（#1967） resume_launch_args	対応	一部対応 worker の再開（再起動をまたぐ復元を含む）は spawn と同じ引数（モデル・effort・プロファイルの args と env）で立てる。master / solo の再開はカタログのメタだけで組む	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: tako-control/src/resume_launch.rs が master / solo は build_master_cmd、worker は build_worker_cmd_in（spawn と同じ関数に会話 ID を渡す = WorkerLaunch::resume）で組む。worker は GUI の再起動をまたぐ復元・tako sessions resume・会話を保った再起動が同じ worker_resume_launch を通る（#2473）。#2473: 隔離 GUI + 偽 claude / 偽 codex で spawn と復元の 引数・役割・プロファイルの env が一致（scripts/test-resume-launch-args-2473.sh。codex-cli 0.154.0 の codex resume --help は -m / -c と spawn の承認・サンドボックスの引数を受ける）。codex の master / solo の 再開はカタログのメタだけ（claude の —effort 書式を足さない = agent_resume::ResumeSpec の accepts_launch_flags）
会話を保ったまま CLI プロセスだけ建て直す（#1067。CLI の自動更新に追いつく手段） session_restart_harness	対応	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #975 tako の実装が claude 専用で、この系統への配線がまだ無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: resume コマンド自体は #1238 で 3 系統ぶん組めるようになった（agent_resume::resume_spec）。残る欠けはペイン → 会話 ID の解決で、session_restart は claude の検出（agents —json / セッションカタログ）に依るため codex / agy では ID が出てこない。#1238 が採る ID は復元用に layout.json へ保存する経路で、まだここへは配線していない
引き継ぎを書かせてセッションを交代する（#1067。ペインの右クリック / tako session-restart --mode handoff） session_restart_handoff	対応	未対応 #975 手段は揃っているが実機で確かめていない（claude で先行実装した）	未対応 #987 agy は worker 専用で、master / solo としては起動前にエラーになる（#127）	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: 引き継ぎ再起動は master ペインへ定型文を送り、エージェント自身が tako_orchestrator_handoff を呼ぶ形（handoff.rs の restart_prompt）。 codex master は #979 で MCP が届くので成立しうるが未実測。 agy は master になれない（#987）ので対象そのものが無い
PC 再起動（tmux サーバーごと消える）後の復元で会話ごと戻る（#1238） restore_after_reboot	対応	対応	対応	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1238 の実測（2026-09-09 / codex-cli 0.153.0 / agy 1.1.27）: 生きた codex は $CODEX_HOME/thread-writer-locks/<id>.lock を、生きた agy は ~/.gemini/antigravity-cli/brain/<id> を開いたまま持つ（#1033 の実測）。ペイン → 子孫 pid → lsof でその ID を採り layout.json へ保存すると、tmux サーバーを kill したあとの復元で codex resume &lt;id&gt; / agy --conversation &lt;id&gt; が会話を履歴ごと戻した。Windows は lsof が無いので ID を採れない（復元の内訳は resume 非対応 と出す。判定は tako_core::agent_resume::restore_support）

利用制限

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
利用上限で止まったことを検知する worker_limit_detect	対応	対応	対象外 agy の残量は前払いの AI クレジット残高で、5h / 週のような枠とリセット時刻が無い。残高も対話の /credits モーダルの中にしか出ないので、worker の画面を乱さずに読む口が無い（#985 で agy 1.1.22 を再調査）	対象外 自分のマシンで動かすモデルなので利用上限という概念が無い	実測: #985 実測（2026-08-27）: codex 0.150.1 の停止文言 You've hit your usage limit. と 接近ダイアログ Approaching rate limits をバイナリ内文字列で確認し、limit_stop.rs の実採取 fixture が両方を検知することをテストで固定した。agy 1.1.22 は窓つきの利用上限を持たない（agy --help に usage / quota 系の サブコマンドが無く、バイナリの RateLimit は全部 PR レビュー設定と Go / sentry の内部名。残量は /credits = 前払いクレジット）ので、検知すべき「上限で止まった状態」自体が存在しない。#1880（claude）: 停止の判定は画面のまま。tako mod の報告があれば解除時刻だけを mod の値（秒精度）に差し替える（LimitHint::from_mod。mod の値だけでは停止と判定しない）
利用上限の解除後に自分で再開する（#813） worker_limit_autoresume	対応	一部対応 5h / 週の枠は解除を待って自分で再開するが、ワークスペースのクレジットが尽きた場合は「待つ」出口が無い（増枠申請・購入・獲得済みリセットの引き換えしか無いので、tako は何も選ばずに止まる）	対象外 agy はクレジットを使い切っても「解除を待つ」出口が無い（買い足す導線しか無い）ので、待って再開するという動作が成立しない（#985）	対象外 自分のマシンで動かすモデルなので利用上限という概念が無い	実測: #985 実測（2026-08-27 / codex-cli 0.150.1）: codex の解除時刻は 2 つの経路で 取れる。① 画面の Try again at Aug 28th, 2026 4:24 AM.（バイナリ内書式 " Try again at " + ", %Y %-I:%M %p"。日付を挟む形は #985 前は読めず、不明の猶予 900 秒で早撃ちして 3 回で諦めていた）② rollout の rate_limits.<枠>.resets_at（epoch 秒。書式にもタイムゾーンにも依存しない）。セルフテスト項目 111 の codex 節が解除前は撃たず解除後に再開するところまで見る （TAKO_985_LEGACY=1 へ戻すと reset_at=None で FAILED になることを実測）。agy 1.1.22 は /credits に「待つ」出口が無く（Get More AI Credits / See Activity）、待って再開する動作そのものが成立しない
エージェント CLI 自身が上限解除後に続行する（同じプロセスが生き続けているあいだだけ。#1140） limit_autocontinue_upstream	対応	対象外 codex の CLI には上限解除を待って自分で続行する仕組みが無い（止まったままなので tako 側のナッジが唯一の再開手段）	対象外 agy はクレジットを使い切っても「解除を待つ」出口が無い（買い足す導線しか無い）ので、待って再開するという動作が成立しない（#985）	対象外 自分のマシンで動かすモデルなので利用上限という概念が無い	上流の仕様: #1140 の実物調査（claude 2.1.258 の実装ソースをバイナリから採取）: 上限の API エラーを受けた時点で bUn(quotaLimits, …) がダイアログ無しで自動的に armed へ入り、解除時刻 + 30〜90 秒のジッタで自分へ継続プロンプト （Your claude.ai usage limit has reset. Continue the task you were working on …）を投げる。設定キーは autoContinueAtUsageLimit（未設定なら ON）、ゲートは tengu_marble_heron の enabled / autoArm（未設定なら ON）。連続の張り直しは 2 回まで（rearm_cap）、自動 arm は解除が 24 時間より 先だと張らない（horizon_exceeded）。上限ダイアログの Stop and wait for limit to reset（値 cancel）は arm しない: 継続が既にキューへ入っているか episode が stale なら解除し、それ以外はメニューを閉じるだけ。arm する選択肢は別で、Wait here, then continue automatically …（値 auto-resume）。escape / ctrl_c / kill_agents_chord / 手入力の送信 / conversation_reset（clear / resume / remote_attach）/ account_switch / relaunch / process_exit で解除される。codex 0.153.0 と agy 1.1.27 のバイナリには相当する文字列が 1 件も無い （continue automatically / auto_resume / auto-resume / autoResume / wait for limit / resume automatically が各 0 件。同じ走査で codex の hit your usage limit は 7 件・Try again at は 1 件当たるので走査は有効）。解除時刻をまたぐ実機観測は行っていない（実装ソースからの判定）
利用制限の残量（%）を取り出す（#357） worker_limit_metrics	対応	対応	対象外 agy の残量は前払いの AI クレジット残高で、5h / 週のような枠とリセット時刻が無い。残高も対話の /credits モーダルの中にしか出ないので、worker の画面を乱さずに読む口が無い（#985 で agy 1.1.22 を再調査）	対象外 自分のマシンで動かすモデルなので利用上限という概念が無い	実測: #985 実測（2026-08-27 / codex-cli 0.150.1 / plan_type = plus = 有料プラン）: rollout の token_count に rate_limits.primary（window_minutes: 300 = 5h）と .secondary（10080 = 週）が数値で載る。#357 の画面スクレイピングは 0.150.1 では成立しない（実測: TUI のフッターはモデル名と cwd だけで、5h limit: [██…] 90% left (resets 23:23) は /status のモーダルの中にしか 出ない = 常時見えるところに primary NN% は無い）ので、構造化ソースが正になった。両者の解除時刻が一致することも確認（rollout の 1787840583 = 画面の 23:23）。agy 1.1.22 は前払いクレジットで枠が無い（/credits を実行して確認）
時間では解けない利用阻害で止まったことを検知する（#1106） worker_entitlement_detect	対応	対応	対応	対象外 自分のマシンで動かすモデルなので、座席種別・クレジット・組織ポリシーという概念が無い（阻害される権利がそもそも存在しない）	実測: #1106: claude 2.1.258 のバイナリで阻害の前置き（dCt / pCt / Par）を読み、時間で解ける 4 条件（#1096）を除いた 6 分類 / 8 文言 —— 座席種別 3 種・管理者による無効化・グループ枠 $0・クレジット要求・追加利用ぶんの枯渇・組織でのサービス無効 —— を tako_core::limit_resume::entitlement_block_line で受け、WorkerErrorKind::EntitlementBlocked（needs_human）として返す。#1107（2026-09-04 の実物調査）: codex 0.153.0 のバイナリに 6 実文言 / 3 分類（クレジット残高の枯渇 = You're out of credits. / Your workspace is out of credits. {Add credits to continue. | Ask your workspace owner to refill in order to continue. | Add credits to continue using Codex.}、spend cap = You hit your spend cap set {in your workspace | by the owner of your workspace}. …、workspace のクレジット上限 = You've reached your workspace credit limit + … Notify owner?）、agy 1.1.25 に 2 実文言（AI: Out of credits = 前払いクレジットが 0。変更履歴に「spurious “Out of credits” errors」の修正が 2 件あり実表示だと分かる / No license available for this project and location. Contact your administrator to setup Gemini Enterprise for this project.）が在ることを確認し、out of credits / spend cap / workspace credit limit / no license available の 4 語句として受ける。この 4 語句は claude 2.1.258 の バイナリに 1 件も無い（各 0 件。逆に claude の out of usage credits 12 件・spend limit 75 件は codex / agy に 0 件 = 語彙が系統ごとに分かれている）ので claude の判定は 1 ビットも変わらない。座席種別・組織のサービス無効に相当する 停止文言は codex / agy には無い（disabled for your 0 件。seat は Seatbelt サンドボックスと SQL 予約語、entitlement は MCP の openai/entitlementContext = ツール権限の文脈で停止文言ではない）。codex の構造化ソースでは区別できない （rollout の rate_limits は used_percent / resets_at / window_minutes だけで、クレジット残高や権利の欠如を表すフィールドが無い = #985 の枠情報のみ）ので画面の文言が唯一の根拠になる。実文言の fixture は detect_worker_errorはcodexとagyの阻害も別種として検知する / issue1107_codexとagyの阻害文言も別種として読む、上限停止（#1093 / #1096 / #985）との排他は issue1107_workspace_credit_limitはテンプレートより阻害が優先する と issue1107_codexの上限系は従来どおり時間で解ける扱い が固定している。残高を 0 にして実際に踏ませる再現はしていない（課金・管理者権限が要る）。ローカル LLM にはベンダーの座席・クレジット・組織ポリシーが無い
ステータスバーの利用制限表示をこの系統へ切り替えられる（#217 / #357） limit_service_switch	対応	対応	対象外 agy の残量は前払いの AI クレジット残高で、5h / 週のような枠とリセット時刻が無い。残高も対話の /credits モーダルの中にしか出ないので、worker の画面を乱さずに読む口が無い（#985 で agy 1.1.22 を再調査）	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #985: ステータスバーの codex 表示は rollout の構造化データ（rate_limits）を 読む形になり、有料プランの実データが出る。agy は取得不能を再確認して unsupported の明示表示のまま（#357 の判断は理由を差し替えて維持）。#1903（claude）: tako mod の報告があれば 5h / 7d はその値、無ければ画面 （取得元は tako limit-service —refresh の claude.source）
会話記録の使用量（トークン・API 換算）をプロジェクト・Issue・会話ごとに集計する（#2201） usage_tokens	対応	一部対応 codex のモデル（gpt-* / codex-auto-review）は API 換算の単価表に無いので、使用量はトークン数だけを数える（API 換算は出ない）。rollout はどのログインで使ったかを持たないので、過去の分も今の auth.json のログインへ寄せる（#2204）	未対応 #2205 agy のトークン数は会話の保管庫（conversations/<id>.db = SQLite の gen_metadata の行）にしか無く、実況ログには無い。tako は SQLite を読む依存を持たない（#984 の判断）ので、依存の可否を #2205 で調べる	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: tako_control::usage::index::tests（偽の transcript の分割行・仮の output・<synthetic>・サブエージェント・書きかけの最終行・切り詰め・追記分だけの読み直し・カタログの追い出し）。codex は #2204 実測（2026-10-17・この機の rollout 264 本・631 MB の写し）: token_count の累積の差分の和が rollout ごとの最後の累積の和（別実装の python）と 19.41 億トークンで完全一致・会話 262 本すべて一致。gpt-* / codex-auto-review は単価表に無いので API 換算は出ない
観測した利用制限（5h / 7d）の % の増分を、区間の使用量の比でプロジェクト・Issue・会話へ配る（#2202） usage_limit_share	対応	一部対応 codex の % は rollout の rate_limits を観測にして過去の分まで配るが、重みは API 換算ではなく生トークンの比（codex のモデルは単価表に無い）。rollout はどのログインで使ったかを持たないので、過去の分も今の auth.json のログインへ寄せる（#2204）	対象外 agy の残量は前払いの AI クレジット残高で、5h / 週のような枠とリセット時刻が無い。残高も対話の /credits モーダルの中にしか出ないので、worker の画面を乱さずに読む口が無い（#985 で agy 1.1.22 を再調査）	対象外 自分のマシンで動かすモデルなので利用上限という概念が無い	実測: #2202 実測（2026-10-17・この機の limits.jsonl と会話記録の写し）: 7d の配った合計 + tako の外が 観測と一致（2 ログイン）。単体テスト tako_core::usage::share::tests は既知の重みで合成した観測の列で、混雑時間帯の係数・窓のまたぎ・古い値のペイン・下がる報告・使用量 0 の区間（tako の外）・最後の観測より後と観測の無い窓（推定）を含め、合計が観測と一致しキーごとの誤差が 1 ポイント以内。agy は #985 の実測（agy 1.1.22）で窓つきの利用上限と使用率を持たない（残量は前払いクレジット）ので配る % が無い。codex は #2204 実測（2026-10-17・この機の rollout 264 本の写し）: 過去の rate_limits から 5h は 11 窓で延べ 478% = 段 478.00 + tako の外 0・7d は 17 窓で 718% = 段 718.00 + 0（窓ごとの最大の % の和を別実装で 出しても同じ）。重みは生トークン（単価表に無い）で推定はしない。単体テスト tako_core::usage::share::tests::codexの窓は揺れを1時間まで寄せ早く始まった窓を分ける

リモートからの操作

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
会話をベンダー公式のリモート操作（スマホアプリ / Web）へ委譲できる（#1068） remote_control	対応	未対応 #1059 codex にも remote-control（experimental）はあるが、これは自前で app-server デーモンを立てて websocket + bearer トークンで TUI を繋ぐ形で、ベンダー側のスマホアプリへ会話を出すものではない。tako 側の配線も無い	対象外 agy の --help 全件（フラグ 24 / サブコマンド 11）にリモート操作の口が無い（mic-serve はマイクを別ホストへ配るだけ）ので、会話を外の端末から操作する手段がそもそも無い	未対応 #991 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	実測: #1068 の実測（2026-09-02）: claude 2.1.232 の --help に --remote-control [name] Start an interactive session with Remote Control enabled が在り、tako は build_master_cmd_in / build_worker_cmd_in の claude 分岐でこれを渡す。codex 0.150.1 の --help には remote-control [experimental] Manage the app-server daemon with remote control enabled と --remote <ADDR> があるが自前ホストの app-server 経路で別物。agy 1.1.23 の --help 全件にはリモート操作の口が無い

その他

能力	Claude Code	OpenAI Codex CLI	Antigravity CLI	Local LLM	根拠
コンフリクト解消エージェントとして起動する（#496） git_resolve_agent	対応	対応	対応	未対応 #990 ローカル LLM の系統がまだ成立していない（リポジトリに Ollama への参照が 1 件も無い）	コード本文: dispatch.rs の git resolve は worker spawn と同じ WorkerLaunch（#986 で tako_bin を配線済み）を通るので、MCP の一時注入も同じ 1 実装で効く。 番犬 worker_mcp_injection_watchdog::worker_を起動する経路は_tako_bin_を渡している が 片方だけ配線が落ちる形を落とし、MCP が実際に通ることは worker 経路で実測済み （WORKER_MCP 行）

この表の作り方

正本は crates/tako-core/src/agent_support.rs の能力マトリクスです。 Claude Code 以外について「使える」「落ちる」「使えない」と書くときは根拠 （コード本文の引用・上流の仕様・実測の記録）を同時に書く必要があり、 書かずに倒すとテストが落ちます。

このページの再生成と同期検査は次のとおりです。

cargo build -p tako-cli
node scripts/gen-agent-support-docs.mjs          # 再生成
node scripts/gen-agent-support-docs.mjs --check   # 同期検査