Windows 対応状況

tako は macOS で先行開発し、安定した差分を Windows へ反映しています。このページは tako 本体が持っている対応マトリクスから生成しているので、実装とずれません。手元の環境で最新を引くには次を実行してください。

tako platform                      # この環境の対応状況
tako platform --status pending      # まだ使えないものだけ

全体

状態	件数	意味
対応	119 / 162（73%）	macOS と同じように使えます
一部対応	20	使えますが機能が落ちます。落ち方は各表の「差分」列
未実測	6	実装はあり macOS と同じ経路を通るが、Windows 実機でまだ動かしていないもの
未対応	15	Windows 側の実装が無い、または動かないことが分かっているもの
対象外	2	Windows にその概念が無い、または OS が同等機能を標準で持つ

「未実測」について

tako は 実機で確かめたものだけを「対応」と書きます。実装がプラットフォーム共通で動く見込みがあっても、Windows 実機で 1 度も実行していないものは「未対応 / 未実測」に置いています。過大に申告すると、この宣言を読んで動く AI エージェント（tako は縮退の件数と引き方を system prompt へ渡し、理由の全文は tako orchestrator guide platform で引けるようにしています）が「使えるはず」と信じて失敗し続けるためです。

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

根拠	意味
実機セルフテスト	Windows 実機の GUI セルフテスト（通しで失敗 0 件）が実際に通した項目
実機テスト	Windows 実機の `cargo test` で緑のテスト
実機実測	Windows 実機で操作を実行して結果を記録したもの
OS の仕様	Windows の仕様・設計判断で、実測する対象がそもそも無いもの
未実測	まだ実機で動かしていないもの

ターミナルの基本

対応 27・一部対応 5・未対応 / 未実測 1・対象外 1

機能	状態	差分	根拠
`tako_split_pane`	対応	—	実機セルフテスト: 項目 2 / 18 / 34（cmd+D・tako split・MCP tako_split_pane）
`tako_close_pane`	対応	—	実機セルフテスト: 項目 6 / 28 / 40 / 40b（cmd+W・tako close・非フォーカス側 close・10 周の fd 検査）
`tako_focus_pane`	対応	—	実機セルフテスト: 項目 4 / 24（方向フォーカス移動・tako focus）
`tako_resize_pane`	対応	—	実機セルフテスト: 項目 5 / 5b / 22（キーボード・境界ドラッグ・tako resize —share-y）
`tako_equalize_layout`	対応	—	実機セルフテスト: 項目 23（tako equalize）
`tako_move_pane_to_tab`	対応	—	実機セルフテスト: 項目 26 / 68c（tako tab move-pane・target + direction）
`tako_scroll_pane`	対応	—	実機セルフテスト: 項目 43 / 44 / 44b（ホイールの出し分け・tako scroll・ピクセル単位スクロール）
`tako_scrollback`	未対応 / 未実測	実装はプラットフォーム共通で macOS と同じ経路を通るが、Windows 実機での実測がまだ無い（動く見込み。失敗したらまずここを疑う）	未実測
`tako_send_input`	対応	—	実機セルフテスト: 項目 19（tako send）。非 ASCII は #907 で器の注入口へ迂回済み
`tako_read_pane`	対応	—	実機セルフテスト: 項目 20 / 33（tako read・MCP tako_read_pane）
`tako_links`	一部対応	`C:\…`・`\\server\share\…`・`src\main.rs:10:5` のような `\` 区切りのパスもリンクになる（#2435）。ただし拡張子の無い `\` 区切りの相対パス（`src\components`）は `.\src\components` の形のときだけ、Debug 表示の二重バックスラッシュ（`C:\\Users\\…`）はリンクにならない（`\n` などのエスケープと見分けるため）	実機テスト: links の単体（`\` の形の候補を macOS 上から Platform::Windows で検査 / Windows ランナーで cargo・rustc・Python・Node の出力のパスが実在チェックまで通る / URL・`\n`・正規表現を候補にしない）と dispatch の links 経路（`C:\…` の絶対パス）。どれも Windows ランナーで走る
`tako_list_panes`	対応	—	実機セルフテスト: 項目 17 / 33（tako list・MCP tako_list_panes）
`tako_set_title`	対応	—	実機セルフテスト: 項目 21（tako title —role）
`tako_create_tab`	対応	—	実機セルフテスト: 項目 7 / 25 / 116（cmd+T・tako tab new・—cwd 指定）
`tako_select_tab`	対応	—	実機セルフテスト: 項目 12 / 27（cmd+1・tako tab select）
`tako_rename_tab`	対応	—	実機セルフテスト: 項目 50（tako tab rename）
`tako_reorder_tab`	対応	—	実機実測: #937 の Windows 11 実測: `tako tab reorder 1 --index 1` でタブ順が tab2,tab1,tab3 へ入れ替わり `--index 0` で戻る
`tako_collapse_tab`	対応	—	実機実測: #937 の Windows 11 実測: `tako collapse --tab 1 on` が collapsed=true を返し `tako list` の collapsed も true、`off` で戻る
`tako_pin_tab_title`	対応	—	実機セルフテスト: 項目 51b（自動命名直後の「この名前を固定」）
`tako_confirm_close`	対応	—	実機セルフテスト: 項目 73a〜73f（確認ダイアログの表示・Esc・Enter・即 close）
`tako_auto_rename`	一部対応	AI 命名は動くが、シェル統合が無い（#525）ためタブの素材（cwd / タイトル / 実行状態）が起動後に変化せず、命名はタブごとに 1 回だけになる。claude を導入していない環境ではタブ名が PowerShell の実行ファイルパスになる（#760）	実機実測: #722 の Windows 11 実測: 隔離 GUI で AI 経路が走りタブ名が AI 由来（同素材のヒューリスティックは PowerShell のパス由来で別物）。セルフテスト項目 51 / 52（適用・手動優先・ON/OFF）も緑。残る縮退は #760 の実測（素材が不変なので 2 回目以降が発火しない）
`tako_autosuggest`	対象外	Windows の PowerShell は PSReadLine の予測入力を標準搭載しているため、tako 側の注入は要らない	OS の仕様: PowerShell が PSReadLine の予測入力を標準搭載しているので注入する対象が無い（セルフテスト項目 41c / 41c-2 は zsh 不在で自動スキップ）
`tako_window`	対応	—	実機セルフテスト: 項目 77（window new → move-tab）+ #872 で 0 枚化の寿命を Windows 向けに実装（項目 79b）
`tako_menu`	対応	—	実機セルフテスト: 項目 118（in-window メニューバー #657 の open / invoke / close）
`tako_background_pane`	対応	—	実機セルフテスト: 項目 47b（ーボタンでバックグラウンドへ退避）
`tako_background_list`	対応	—	実機セルフテスト: 項目 47c（ドロワーに実画面プレビューが並ぶ）
`tako_background_kill`	対応	—	実機実測: #937 の Windows 11 実測: MCP `tako_background_kill` が killed=2 を返し、`tako backgrounded` が 1 件から空になる
`tako_foreground_pane`	対応	—	実機実測: #937 の Windows 11 実測: `tako background --pane N` で外したペインが `tako foreground N` で由来タブへ戻る（list の panes が 1 → 1,2）
`tako_show_command`	対応	—	実機セルフテスト: 項目 91 / 91b（カードとカード帯）+ #875 で新規ペイン実行を実機実測
`tako_run`	一部対応	宣言・拡張子既定・プロジェクト既定の解決と実行・実行設定の保存は動くが、Arduino のスケッチ（.ino）が使う arduino-cli のうち Arduino IDE 同梱の置き場（%LOCALAPPDATA%\Programs\Arduino IDE\… / %ProgramFiles%\Arduino IDE\…）の探索と、書き込み先のポート（COM3 等）・基板とポートの選択（arduino-cli board attach）は Windows 実機で未確認（#1950 / #1952）	実機実測: #875 の実機 before/after: 「PTY を起動できなかった」→ 出力 + __TAKO_EXIT=0。終了コード 4 型・引用符・日本語・psmux 経由まで実測 + セルフテスト項目 91(d) の実行検査が ran=true。拡張子既定も #1655 で Windows 用の列を持つ（`python` / `.exe` / `cmd /c` / `pwsh -File`。`&&` と `./` は PowerShell 5.1 で通らないので使わない）。#1950 の Arduino（IDE 同梱の `arduino-cli.exe` の置き場・案内の PowerShell の形）は macOS の単体から固定しただけ
`tako_run_resolve`	一部対応	宣言・拡張子既定・プロジェクト既定の解決と実行・実行設定の保存は動くが、Arduino のスケッチ（.ino）が使う arduino-cli のうち Arduino IDE 同梱の置き場（%LOCALAPPDATA%\Programs\Arduino IDE\… / %ProgramFiles%\Arduino IDE\…）の探索と、書き込み先のポート（COM3 等）・基板とポートの選択（arduino-cli board attach）は Windows 実機で未確認（#1950 / #1952）	実機実測: #875 の実機実測で Code Runner の宣言 / 拡張子既定の解決から実行まで通した（3 経路のうちの 1 つ）。#1656 のプロジェクト既定（cargo / npm / python / go / dotnet / make）と #1950 の arduino は Windows の列を macOS の単体から固定したが実機は未検証
`tako_run_defaults`	一部対応	宣言・拡張子既定・プロジェクト既定の解決と実行・実行設定の保存は動くが、Arduino のスケッチ（.ino）が使う arduino-cli のうち Arduino IDE 同梱の置き場（%LOCALAPPDATA%\Programs\Arduino IDE\… / %ProgramFiles%\Arduino IDE\…）の探索と、書き込み先のポート（COM3 等）・基板とポートの選択（arduino-cli board attach）は Windows 実機で未確認（#1950 / #1952）	実機テスト: 拡張子既定の登録・削除・一覧は設定ファイル I/O だけで、単体が実機で緑。組み込み既定は #1655 で OS 別の表になり、Windows の列（41 拡張子中 36 件）を macOS の単体から解決結果ごと固定している。#1952 の .ino の基板とポート（board list の COM ポート・board attach の argv・PowerShell の core install の案内）は macOS の単体で固定しただけ
`tako_run_interactive`	対応	—	実機実測: #937 の Windows 11 実測: `tako run-interactive --pane <p> <コマンド>` が新ペインで実行し、`--wait` が exit_code=0 / status=exited を返す（ペインが極端に狭いとマーカーが折り返して検出できない = #651。macOS も同様）
`tako_run_interactive_status`	対応	—	実機実測: #937 の Windows 11 実測: `tako run-interactive-status <pane>` が exit_code=0 / status=exited を返す（狭いペインの折り返しは #651）

表示とプレビュー

対応 28・一部対応 5・未対応 / 未実測 6

機能	状態	差分	根拠
`tako_open_file`	一部対応	エクスプローラーの「プログラムから開く」に tako は出ない（インストーラが関連付けを登録しない）。既定のアプリを奪わない登録（OpenWithProgids）の案は Windows 実機で未確認（#2134）。tako の中ではファイルツリーと `tako open` で開ける	実機セルフテスト: 項目 66 / 66b / 68b / 112 / 114 / 116（dispatch・tako open・direction・新しいタブ）
`tako_jump`	対応	—	実機テスト: 履歴の積み方・畳み方・上限・閉じたペインの開き直しは OS 分岐を持たない純粋関数で、jump_history の単体と dispatch の jump（行指定の open で積み、戻る / 進むで着地する）が CI の Windows ジョブで緑
`tako_open_dir`	対応	—	実機実測: #970 の Windows 11 実測（同一バイナリの A/B）: `tako open-in dir <path>` で開いたペインの cwd が `C:\Users\…` になり、そのペインで `tako git log --pane N` が branches / commits を返す。`TAKO_970_LEGACY=1` では cwd が `\\?\C:\…` のまま `git リポジトリではない` で止まる
`tako_preview_view`	一部対応	PDF はページ画像として表示できるが、Windows のレンダラが文字位置を返さないため文字選択・目次・PDF 内リンクは使えない（#693）	実機セルフテスト: 項目 66b-2 / 70 / 112 / 114（コード・md・画像は緑。PDF はページ画像だけ通り文字座標の検査はスキップ）
`tako_preview_outline`	一部対応	PDF はページ画像として表示できるが、Windows のレンダラが文字位置を返さないため文字選択・目次・PDF 内リンクは使えない（#693）	実機セルフテスト: 項目 114（Markdown 目次のジャンプは緑。PDF 目次は text_layer 不在でスキップ）
`tako_preview_link_list`	一部対応	PDF はページ画像として表示できるが、Windows のレンダラが文字位置を返さないため文字選択・目次・PDF 内リンクは使えない（#693）	実機セルフテスト: 項目 90 / 114（Markdown リンク索引は緑。PDF 注釈リンクは不可）
`tako_preview_follow_link`	一部対応	PDF はページ画像として表示できるが、Windows のレンダラが文字位置を返さないため文字選択・目次・PDF 内リンクは使えない（#693）	実機セルフテスト: 項目 90（Markdown の修飾キー + クリックは緑。URL は ShellExecuteW で開く = #1371。PDF 内リンクは不可）
`tako_preview_copy_code`	対応	—	実機セルフテスト: 項目 90 / 114（画面外のコードブロックも含めてコピー）
`tako_preview_reload`	対応	—	実機セルフテスト: 項目 66c（実 CLI の ON/OFF と OS イベントでの再生成）
`tako_preview_cache`	対応	—	実機セルフテスト: 項目 33d / 66c（MCP と CLI から同じ LRU 上限へ反映）
`tako_preview_edit`	対応	—	実機セルフテスト: 項目 66d（tako edit で開始 → 適用 → 保存）
`tako_preview_apply`	対応	—	実機セルフテスト: 項目 66d（全文適用）
`tako_preview_edit_range`	対応	—	実機テスト: 範囲の解決・版・CRLF の扱いは純粋関数で、OS 依存の分岐を持たない。text_edit の単体と dispatch の preview範囲編集は行桁で1行だけを差し替えて版を返すが CI の Windows ジョブで緑
`tako_preview_cursor`	対応	—	実機テスト: 行・桁の解決は本文のバイト列だけを見る純粋関数で、OS 依存の分岐を持たない。text_edit の単体と dispatch の previewカーソルは行桁で動き選択は本文を変えないが CI の Windows ジョブで緑
`tako_preview_move`	対応	—	実機テスト: 単語・行・ページの移動は本文のバイト列だけを見る純粋関数で、OS 依存の分岐を持たない。打鍵（Ctrl+←→ / Ctrl+Home / End）の Windows 列は editor_keys の単体が macOS 上からも検査し、dispatch の preview移動と削除は単語と行の単位で効くが CI の Windows ジョブで緑
`tako_preview_delete`	対応	—	実機テスト: 語・行単位の削除は本文のバイト列だけを見る純粋関数で、OS 依存の分岐を持たない。打鍵（Ctrl+Backspace / Ctrl+Delete）の Windows 列は editor_keys の単体が macOS 上からも検査し、dispatch の preview移動と削除は単語と行の単位で効くが CI の Windows ジョブで緑
`tako_lsp`	未対応 / 未実測	診断の受信・重大度の絞り込み・定義の問い合わせ・整形の答えの当て方・補完とホバーの問い合わせと取り消し（読み込み中の待ちを含む）・参照検索と呼び出し階層 / 型階層の問い合わせとツリーの開閉・名前の変更（dry-run と段階 1 の当て方）・右クリックメニューの能力による出し分け・UTF-16 の桁の変換・Windows 形式の URI → パス・着地の規則・ホバーのキー（Ctrl+Shift+H）の割当は偽サーバの e2e と単体で確かめているが、Windows 実機で実サーバ（rust-analyzer / clangd 等）の診断を出したことも、定義へ飛んだことも、整形したことも、補完の一覧やホバーのカードや参照の一覧や右クリックメニューの項目を出したことも、名前を変えたことも、Ctrl+Shift+H を実際に押したこともまだ無い（#1007）	実機テスト: issue1679_lsp_diagnostics（偽サーバの Diagnostic 配列 → tako lsp diagnostics の固定値・重大度の境界・UTF-16 の桁・閉じたら保持 0）と issue1680_lsp_goto（偽サーバの Location / LocationLink → 行・桁の変換・UTF-16・見つからない / 未応答 / 未導入 / 未対応の区別・一時 didOpen の後始末）と issue1683_lsp_format（偽サーバの TextEdit 配列 4 形 → 固定値・undo 1 回・範囲の外を変えない・CRLF・待つあいだの変更）と issue1682_lsp_completion（偽サーバの補完 → 3 回の要求で $/cancelRequest 2 件・版が変わった答えを捨てる・UTF-16 の範囲・説明の補い）と issue1684_lsp_menu（偽サーバの申告 4 通り → 右クリックメニューの項目の列・握手以外を送らない・未導入）と issue1681_lsp_hover（偽サーバのホバー → Markdown / 平文 / 旧形式 / 空の読み取り・UTF-16 の往復・マウスの要求の取り消し・開いていない文書でサーバを起こさない・100 回で保持件数が増えない）と issue1869_lsp_followup（偽サーバの読み込み中 → 打鍵の要求も待って問い直す・待ちは次の打鍵 / 閉じるで抜ける・上限で loading）と issue1893_lsp_hover_followup（偽サーバの読み込み中 → マウスのホバーも待って問い直す・乗せ直す / 閉じる / 文書を閉じるで抜ける・先に取った取り消しの番号・上限で loading・申告の無いサーバではメニューにホバーを出さない）と issue1685_lsp_xref（偽サーバの Location 配列 → 一覧の行の固定値・巨大な結果の上限・0 件・未対応・未導入・呼び出し階層の prepare → 展開の送信列・型階層・ツリーの開閉の往復・閉じたら保持 0）と issue1686_lsp_rename（偽サーバの WorkspaceEdit の changes / documentChanges → ファイル数・箇所数の固定値・dry-run でバイト一致・別のファイルに及ぶと当てない・undo 1 回・prepareRename の拒否・能力なし）が CI の Windows ジョブで緑。URI → パスの Windows 形式は lsp::goto の単体（macOS 上で固定）、ホバーのキー Ctrl+Shift+H が既存の割当と衝突せず Ctrl+H（0x08）を奪わないことは keybindings の単体（Platform::Windows の表を macOS 上でも検査）
`tako_lsp_server`	未対応 / 未実測	言語サーバの起動・握手・文書同期と、未導入のサーバを data dir へ取って起こす経路（#1944）は偽サーバの e2e で確かめているが、Windows 実機で実サーバ（rust-analyzer 等）と握手したことも、配布元から実際に取ったこともまだ無い（#1007）。第 2 波の 6 行（#1956）も同じで、texlab / tombi の Windows 向けの取得物（zip の中の tako が取り出す 1 つ）・sourcekit-lsp（Swift toolchain に同梱）・dart・vscode-css-language-server / vscode-html-language-server（npm の .cmd）を Windows 実機で起こしたことはまだ無い。Arduino のスケッチ（.ino）の arduino-language-server（#1951）も、Arduino IDE 同梱の置き場（%LOCALAPPDATA%\Programs\Arduino IDE\… / %ProgramFiles%\Arduino IDE\…）と伴走の arduino-cli.exe / clangd.exe の探索は macOS の単体から固定しただけで、Windows 実機では未確認	実機テスト: issue1678_lsp_e2e（偽サーバとの握手・送信列・分割受信・再起動の上限・親が落ちたら子も終わる）と issue1944_lsp_fetch（ローカルの配布元から偽サーバの gzip を取ってハッシュを検証して起こす・グローバル優先・ハッシュ不一致 / オフライン / 404 / 大きすぎるで未導入へ落ちる・2 つの器で 1 回だけ取る・取っている途中で閉じたら起こさない）と issue1956_lsp_servers_wave2（第 2 波の 9 つの拡張子 → 表の行と languageId・未導入なら取得の失敗の理由か導入コマンドへ落ちる）と issue1951_lsp_arduino（.ino → arduino-language-server・伴走の arduino-cli / clangd と空の設定ファイルのパスが起動引数に並ぶ・基板が無ければ起こさず理由・ALS / clangd なしで未導入）が CI の Windows ジョブで緑。zip の中の 1 つを取り出すのは lsp::archive の単体（stored / deflate）
`tako_preview_save`	対応	—	実機セルフテスト: 項目 66d（保存と外部変更の拒否）
`tako_preview_undo`	対応	—	実機実測: #937 の Windows 11 実測: `tako edit undo --pane <p>` が undone=true を返す（redo と対で実測）
`tako_preview_redo`	対応	—	実機実測: #937 の Windows 11 実測: `tako edit redo --pane <p>` が redone=true を返す（undo と対で実測）
`tako_preview_search`	対応	—	実機実測: #937 の Windows 11 実測: `tako edit search <語>` が index=2 / total=2 を返し、`--direction next/prev` で index が 1 ↔ 2 と動く
`tako_preview_replace`	対応	—	実機実測: #937 の Windows 11 実測: `tako edit replace <前> <後>` と `--all` が replaced を返し、`tako edit save` 後の実ファイルが置換後の内容になる
`tako_search`	対応	—	実機テスト: workspace_search の単体（既知のツリーの結果の固定値・.gitignore とバイナリの除外・大文字小文字 × 正規表現の 4 通り・CRLF と多バイトの桁・上限 / 所要 / 取り消しでの停止・入れ子のルート）と dispatch の横断検索（MockHost で search → results → open で新しいペイン → clear で保持 0）が CI の Windows ジョブで緑。キーの Ctrl+Shift+G が既存の割当と衝突せず Ctrl+G（0x07）を奪わないことは keybindings の単体（Platform::Windows の表を macOS 上でも検査）
`tako_preview_autosave`	対応	—	実機実測: #937 の Windows 11 実測: `tako edit autosave true/false` が状態を往復する。有効化後の CLI / MCP 編集で自動保存が発火しないのは実装が共通なので macOS でも同じ（タイマーを始めるのが GUI 入力経路だけ。#973）
`tako_preview_changelog`	対応	—	実機実測: #937 の Windows 11 実測: `tako preview-changelog on --pane <p>` が changelog=true / commits=2 を返し `off` で戻る
`tako_pin_preview`	対応	—	実機実測: #937 の Windows 11 実測: `tako pin --pane N on` が pinned へ矩形つきで載り、`off` で消える
`tako_video_playback`	未対応 / 未実測	動画デコーダの Windows 実装が無く、動画ファイルを開くとエラーになる	実機実測: video_player.rs の非 macOS 実装が Err(“動画再生は macOS でのみ対応”) を返すスタブ
`tako_video_seek`	未対応 / 未実測	動画デコーダの Windows 実装が無く、動画ファイルを開くとエラーになる	実機実測: video_player.rs の非 macOS 実装が Err を返すスタブ
`tako_video_volume`	未対応 / 未実測	動画デコーダの Windows 実装が無く、動画ファイルを開くとエラーになる	実機実測: video_player.rs の非 macOS 実装が Err を返すスタブ
`tako_web`	未対応 / 未実測	Web ビューを開くとアプリごと落ちていた原因（WebView2 の生成中の二重借用と COM コールバックの中の unwrap）への手当てを入れたが、Windows 実機で未確認（#724）。WebView2 ランタイム（145.0.3800.47 以上）が要り、無い・古い PC では生成の失敗が入れ方を案内する（版は check-health の webview2。ユーザーデータは %LOCALAPPDATA%\tako\WebView2。#2431）	実機実測: 修正前の実機の記録: panic.log に gpui の async_context.rs:65 の二重借用（CallWindowProcW が 2 段）、セルフテスト項目 71 で wry/src/webview2/mod.rs:910 の InvalidUri(Empty)。#724 で生成を App の借用の外へ出し・Windows では ipc を付けず・生成中に落ちた Web ビューを次の起動で保留にした。項目 71 は実機で通るまでスキップのまま
`tako_theme`	対応	—	実機セルフテスト: 項目 33b（MCP tako_theme: light 適用 → GUI 反映 → toggle）
`tako_lang`	対応	—	実機セルフテスト: 項目 33c（MCP tako_lang: en 適用 → i18n 反映 → system 復帰）
`tako_ui_mode`	対応	—	実機実測: 項目 93 / 94 / 97 / 100 / 114 / 115（G1 スターター〜チャット表示と仮想化）に加え、2026-09-09 の Windows 11 実機でスターターカード「AI チームに任せる」からペインが tako master を実行し、role=orchestrator-master / state=running とタブ名 master まで到達した。投入経路の #899 は PR #931（2026-08-27 merge）で解消済み
`tako_chat_copy`	対応	—	実機セルフテスト: 項目 98 / 115（チャット本文の選択・コピー・索引）
`tako_panel`	対応	—	実機セルフテスト: 項目 49 / 56 / 64 / 64b（fleet ビュー・タブ枠・tako panel roundtrip・ファイルツリー経路）
`tako_tree_folder`	対応	—	実機セルフテスト: 項目 67 / 85（タブ = ワークスペース・TreeFolder 経由の git セクション）
`tako_welcome`	対応	—	実機実測: 項目 88（バナーと案内コマンドの取得）に加え、2026-09-09 の Windows 11 実機で「セットアップを実行」ボタンから新しいタブが開き tako.exe setup が実際に走った（ゼロスタート導入の 3/3 まで到達）。投入経路の #899 は PR #931（2026-08-27 merge）で ShellDialect::command_word 経由になり、LF 側は #897 の番犬が禁じている。#1510 の導線（自動の段・次にやることのボタン）はボタンが同じ command_word 経由でタブへ打つ形で、PowerShell の形は welcome の単体テストが縛る（Windows 実機の通しは未実測）
`tako_recent`	対応	—	実機実測: #937 の Windows 11 実測: `tako recent list` が `open-in dir` で開いたディレクトリを返す

AI 連携（オーケストレーション）

対応 27・一部対応 2・未対応 / 未実測 1

機能	状態	差分	根拠
`tako_orchestrator_spawn`	対応	—	実機セルフテスト: 項目 72 / 117（配置エンジンとプロファイル適用）+ #867 で実機の claude 起動と env 到達を PEB で確認
`tako_orchestrator_self`	対応	—	実機セルフテスト: 項目 102（後任 master の self がプロファイルと handoff_path を引き継ぐ）
`tako_orchestrator_handoff`	対応	—	実機セルフテスト: 項目 101 / 102 / 102b / 102c / 122（自動通知・後任起動・新旧書式・管轄解決）
`tako_orchestrator_handoffs`	対応	—	実機実測: #915 で実機 13/13（移行・冪等・list / show / write・日本語本文・円記号区切りのパス）+ セルフテスト項目 122
`tako_orchestrator_profiles`	対応	—	実機セルフテスト: 項目 96 / 99 / 117（設定画面のフォーム・スターターの ▾・limit_resume の既定）
`tako_orchestrator_guide`	対応	—	実機テスト: guide の単体 6 本と番犬 prompt_guides.rs（本文は include_str! の静的データで、プレースホルダ解決は platform::facts が OS 差を吸収する）
`tako_orchestrator_projects`	対応	—	実機セルフテスト: 項目 117（一時プロジェクトの登録と解除）
`tako_orchestrator_adopt`	対応	—	実機セルフテスト: 項目 146（自動生成 → 採用 → spawn 既定 → 引き継ぎ先の一連）
`tako_orchestrator_accounts`	対応	—	実機実測: #937 の Windows 11 実測: `accounts list`（空）→ `add --inherit` → `show` → `list`（1 件）→ `remove` → `list`（空）の往復
`tako_orchestrator_layout`	対応	—	実機セルフテスト: 項目 72（master-reserved の配置と close 後のリフロー）
`tako_orchestrator_workers`	対応	—	実機セルフテスト: 項目 105（レジストリの登録・再読込・再解決）
`tako_orchestrator_worker_status`	対応	—	実機セルフテスト: 項目 74 / 105（IPC 応答と busy 中の後続 send）+ #877 で agents 経由の status=idle を実機実測
`tako_orchestrator_respond`	一部対応	tako が保持していないペイン（GUI 不在・ペイン消失）へは応答できない。psmux はアウトオブプロセスの画面採取だけができ、入力送出を持たないため	実機実測: #1200 の Windows 11 実測: 生きているペインへ CLI / MCP の respond が in-process 経路で届き、送ったキーがペインの中のプロセスまで到達する（旧実装は器越しへ直行していたため必ず NoDetachedAccess で失敗していた）
`tako_orchestrator_report`	対応	—	実機実測: #937 の Windows 11 実測: `tako orchestrator report --pane <p>` が source=scrollback で実ペインの出力を返す（第 1 層）。transcript 層は実機の claude が未認証で会話を作れず未実測
`tako_orchestrator_run`	対応	—	実機実測: #937 の Windows 11 実測: MCP `tako_orchestrator_run` が run_id を即返して worker を spawn し、CLI の同期版は status=timeout + 出力 + closed=true まで返す（完遂は実機の claude が未認証のため未実測）
`tako_orchestrator_run_status`	対応	—	実機実測: #937 の Windows 11 実測: `tako orchestrator run-status` が starting/running → timeout/finished と elapsed_seconds を返す（MCP と CLI の両経路）
`tako_orchestrator_run_result`	対応	—	実機実測: #937 の Windows 11 実測: `tako orchestrator run-result <run_id>` が status / duration_seconds / output / pane_id を返す
`tako_orchestrator_supervisor`	対応	—	実機実測: #937 の Windows 11 実測: `supervisor status` → `set_mode --mode notify_only` → `status` → `set_mode --mode auto` の往復と `history --lines 5`
`tako_orchestrator_ledger`	対応	—	実機実測: #937 の Windows 11 実測: spawn が作った台帳エントリを `ledger list` が返し、`ledger record --outcome pass` / `ledger amend` が反映され `ledger stats` が pass_rate=100 になる
`tako_limit_resume`	対応	—	実機セルフテスト: 項目 111 / 117（オプトイン・ダイアログ型 / idle 型の出し分け・試行上限・プロファイル既定）
`tako_limit_service`	対応	—	実機実測: #937 の Windows 11 実測: `tako limit-service` が現在サービスを返し、claude → codex → claude の切替が反映される
`tako_sessions`	対応	—	実機実測: #877 で実機の session_id 解決（resolve_session_id_for_backend -> Some）を実測 + sessions の単体 14 本が実機で緑。resume のペイン起動そのものは未実測だが、経路は #867 で実機実測済みの launch と同じ
`tako_session_restart`	一部対応	引き継ぎ再起動は使える。ハーネス更新（会話を保ったまま CLI を建て直す）の終了要求は #1599 で Windows にも入ったが、Windows には穏当な終了要求が無いので CLI は後始末の機会なく強制終了（TerminateProcess）される。古い CLI が起こした子（MCP サーバ・背景のシェル）は tako がペインの中で止める（#2462。GUI のアプリは残す）が、器（psmux）のペインでは CLI だけが止まり子はペインを閉じるまで残る。終了 → シェルの復帰 → —resume の送達の通しは Windows 実機で未実測（#1067 / #1599）	実機テスト: #1599: 境界 tako_control::platform::process::terminate の Windows の腕（OpenProcess + TerminateProcess）が、自分で起こした子を実際に止める（子の終了コードが TerminateProcess に渡した値になる）ことを CI の Windows ジョブの実プロセステスト（platform::process::tests を名指しで回す段）で確認。dispatch の harness は OS 分岐なしでこの境界を呼ぶ。#2462: 同じ口（terminate_with_descendants）がペインの Job の中のエージェントの孫を止めペインのシェルは残すことを CI の Windows ジョブの実プロセステスト（issue2462_kill_paths_windows。旧アームでは孫が残る）で確認。終了 → シェルの復帰 → —resume の送達の通しは未実測。handoff は queue_prompt_flow だけを使うので影響を受けない
`tako_task_gate`	対応	—	実機テスト: acceptance_gates の 14 テストが実機で緑（#935 でコマンド型述語の実行も通るようになった）
`tako_task_gate_check`	対応	—	実機実測: #935 の Windows 11 実測: `tako task gate check` が 4 形（exit 0 / exit 1 / cwd 指定 / 出力取得）とも判定し、`cmd /c exit 7` は evidence が `exit 7`（値が丸まらない）・非 ASCII の出力も化けない。`TAKO_935_LEGACY=1` では 4 形すべてが「コマンド実行に失敗: program not found」
`tako_task_gate_show`	対応	—	実機テスト: acceptance_gates の表示テストが実機で緑
`tako_task_checkpoint`	対応	—	実機実測: #937 の Windows 11 実測: `tako task checkpoint --task-id … --phase running` が保存され、`tako task update --phase verifying` が反映される
`tako_task_list`	対応	—	実機実測: #937 の Windows 11 実測: `tako task list --json` が保存したチェックポイントを issue / branch / project / prompt_head / phase つきで返す
`tako_task_resume`	対応	—	実機実測: #937 の Windows 11 実測: `tako task resume <id> --tab <t>` が PowerShell 方言の env 前置き（`$env:TAKO_ORCHESTRATOR_ROLE=…; claude …`）でペインを立てる
`tako_todo`	未対応 / 未実測	実装はプラットフォーム共通で macOS と同じ経路を通るが、Windows 実機での実測がまだ無い（動く見込み。失敗したらまずここを疑う）	未実測

git 連携

対応 14

機能	状態	差分	根拠
`tako_git_log`	対応	—	実機セルフテスト: 項目 85（git タブのセクション表示順。git データを取得できない環境ではこの項目は自己スキップする）+ #520 のパス可搬化と CRLF 耐性テストが実機で緑
`tako_git_diff`	対応	—	実機セルフテスト: 項目 85 / 79b（変更ファイルの分類と diff。git データを取得できない環境ではこの項目は自己スキップする）+ #520 の parse_diff CRLF 耐性
`tako_git_show`	対応	—	実機セルフテスト: 項目 85（コミット詳細。git データを取得できない環境ではこの項目は自己スキップする）+ #520 の to_git_path / repo_relative
`tako_git_stage`	対応	—	実機セルフテスト: 項目 79b（ステージング UI の分類とコミット挙動。git データが取れない環境では自己スキップする項目）
`tako_git_unstage`	対応	—	実機セルフテスト: 項目 79b（ステージング UI の分類とコミット挙動。git データを取得できない環境ではこの項目は自己スキップする）
`tako_git_commit`	対応	—	実機セルフテスト: 項目 79 / 79b / 86（コミットメッセージ入力欄・両経路のコミット・IME。git データを取得できない環境ではこの項目は自己スキップする）
`tako_git_conflicts`	対応	—	実機セルフテスト: 項目 82b / 109（使い捨てリポのコンフリクトを git パネルが認識する。git データを取得できない環境ではこの項目は自己スキップする）
`tako_git_resolve_agent`	対応	—	実機セルフテスト: 項目 82b / 109（3 択の開閉と起動。git データを取得できない環境ではこの項目は自己スキップする）+ #867 でエージェントペインの実起動を実機実測
`tako_git_checkout`	対応	—	実機実測: #937 の Windows 11 実測: `tako git checkout topic --pane <p>` が checked_out=true を返し実リポジトリの HEAD が移る（cwd が通常形のペインで実施 = #970）
`tako_git_branch_create`	対応	—	実機実測: #937 の Windows 11 実測: `tako git branch <名前> --pane <p>` が新ブランチを作ってチェックアウトする（cwd が通常形のペインで実施。verbatim prefix の cwd では解決できない = #970）
`tako_git_merge`	対応	—	実機実測: #937 の Windows 11 実測: `tako git merge topic -y --pane <p>` が merge コミットを作り、`-y` なしのドライランは作業ツリーを変えずに予測（predicted_conflicts）だけ返す
`tako_git_merge_abort`	対応	—	実機実測: #937 の Windows 11 実測: 衝突する merge が conflicted=true / conflicts=[c.txt] になり、`tako git abort` が aborted=merging を返して HEAD と作業ツリーが元へ戻る
`tako_git_pull`	対応	—	実機実測: #937 の Windows 11 実測: `tako git pull --pane <p>` が対向 bare リポジトリの新コミットを取り込み merge コミットを作る
`tako_git_push`	対応	—	実機実測: #937 の Windows 11 実測: `tako git push --pane <p>` で対向 bare リポジトリの main が push 後の HEAD へ進む

永続化とセッション

対応 5・一部対応 1・未対応 / 未実測 2

機能	状態	差分	根拠
`tako_persist`	対応	—	実機セルフテスト: 項目 58（tako persist の ON/OFF と状態取得）+ 実機 psmux_backend 16/0
`tako_logs`	一部対応	ペインログは動くが、器（psmux）の中のコマンドが出力し続けている最中に自ら終わると、最後の取り込みの後の行（最大 10 秒ぶん）が入らない。psmux で終わる前の出力を書き出す手段（pane-died フック）を実機で確かめていないため（#2085）。手で閉じる・CLI / MCP で閉じる・出力が止まってから終わる場合は最後まで入る	実機セルフテスト: 項目 87 / 104（ペインログのクローズマーカーと発生源）。#2085 の縮退（自ら終わったコマンドの最後の出力）は、psmux の能力 keeps_exit_output = false で器の設定へ 1 行も足さないことを tmux_backend の単体（能力の無い器へは1行も書かない）が固定
`tako_tmux_list`	対応	—	実機実測: #866 の製品経路 A/B: 項目 48 が既定で通過（TAKO_866_KEEP_EXACT_TARGET=1 では FAILED）
`tako_tmux_kill`	対応	—	実機実測: #866 の製品経路 A/B: 項目 48 で対象だけが消え、隣の tako-test2 が残ることまで実測
`tako_tmux_open`	未対応 / 未実測	永続化の器は psmux で、attach と send-keys を前提にする tmux 操作は動かない	実機実測: セルフテスト項目 68 / 73 は attach / send-keys 前提のため psmux ではスキップ
`tako_tmux_select_window`	対応	—	実機実測: #937 の Windows 11 実測: 2 つ目の window を作ってから `tako tmux select-window 0 / 1 --pane 1` でアクティブ window が実際に切り替わる
`tako_tmux_cleanup`	対応	—	実機実測: #937 の Windows 11 実測: 器へ孤児セッションを 1 つ作ると `tako tmux cleanup` が killed=[tako-orphan937] を返し、使用中の 5 セッションには触らない
`tako_tmux_resize`	未対応 / 未実測	psmux がセッションの寸法指定（-x / -y）を反映しないため寸法を変えられない	実機実測: psmux が -x / -y を受け取っても反映しないことを #866 の調査で確認

OS 連携

対応 6・一部対応 2・未対応 / 未実測 2・対象外 1

機能	状態	差分	根拠
`tako_file_op`	対応	—	実機実測: #617 の Windows 11 実測: 空白 + 日本語名 / 読み取り専用 / ディレクトリ / 315 文字のパスがいずれも復元可能な状態でごみ箱へ入り、reveal で対象が選択され、既定アプリが起動する。実機で緑のテスト: os_integration の windows モジュール（FOF_ALLOWUNDO のフラグ構成 / 絶対化 / /select, の形）。#1182 のターミナル内パスリンクの cmd+右クリックメニューもこの op 群（open_in_tako / open_default / open_with / reveal / copy_）だけで出来ているので、Windows でも項目は 1 つも消えない（「Finder で表示」が「エクスプローラーで表示」へ入れ替わるだけ = #617 の呼び名 1 実装。文言の入れ替えと項目の並びが変わらないことは path_link_menu_items の単体が macOS 上から両 OS 分を検査する）。ただしメニューを出す前段のパス検出は Windows では狭い: links::is_path_like が `/` を含む形だけを候補にするので `C:\…` の絶対パスはリンクにならず（`src/main.rs` のような `/` 区切りの相対パスは効く）、これは #1182 以前からの #153 の範囲の制約。#1834 の `op=move`（ツリーの D&D と同じ移動）は CI の Windows ランナーで tako_core::file_move の単体（実ファイルの移動・同名の拒否・配下の拒否・実体の形での照合）が緑。Windows 実機の D&D と別ボリューム（ERROR_NOT_SAME_DEVICE）の断りは未実測。#1842 で移動の実行は上書きしない rename（`platform::fs_move::rename_noreplace`）になり、Windows は `MoveFileExW` をフラグ 0（`MOVEFILE_REPLACE_EXISTING` も `MOVEFILE_COPY_ALLOWED` も付けない）で呼ぶ。確認から移動までの隙間に作られた同名は OS が `ERROR_ALREADY_EXISTS` で断り、どちらの中身も残る（CI の Windows ランナーで fs_move と file_move の単体（同名のファイル・空のフォルダの上へ・隙間の注入）が根拠。実機は未実測）。#1860 の `op=copy`（複製）/ `clipboard_copy` / `clipboard_cut` / `clipboard` / `paste` は CI の Windows ランナーで tako_core::file_copy（別名はエクスプローラーと同じ「- コピー (2)」の形・上書きしない・戻す）と file_clipboard の単体、DROPFILES の組み立て・読みと Preferred DropEffect の読み分けの単体（macOS の上でも走る）が緑。OS のクリップボードは CF_HDROP + Preferred DropEffect + CF_UNICODETEXT を書き、CF_HDROP を読む。Windows 実機のエクスプローラーとの往復（貼れる・切り取りが移動になる）とシンボリックリンクの複製（開発者モードが要る = 理由つきで断る）は未実測。#1867 の `paths`（まとめた clipboard_copy / clipboard_cut / trash / move）・`paste_move`・`copy_progress` / `copy_cancel` は OS に依らない dispatch の 1 実装で、CI の Windows ランナーで tako_core::tree_select（選択の状態遷移・範囲・配下の除去）・file_copy（進み具合・取り消しで作りかけを戻す）・keys（Ctrl+Alt+V と、AltGr の文字を奪わない判定）の単体が緑。Windows 実機の Ctrl+クリック・Ctrl+Alt+V・AltGr 配列での打鍵は未実測。#1895 の `paths` の `op=copy`（まとめたコピー = 1 つのジョブ）と `copy_progress` の `eta_secs` は OS に依らない dispatch の 1 実装。1 つのファイルは Windows では `CopyFileExW`（`COPY_FILE_FAIL_IF_EXISTS` で上書きしない・進み具合ルーチンでバイトを進め `PROGRESS_CANCEL` で途中で止めて作りかけを消す）で写し、CI の Windows ランナーで fs_copy / file_copy（累計が減らない・途中の取り消しで作りかけを残さない・同名を上書きしない・0 バイト）と keys（Delete だけを奪い Shift+Delete は端末へ流す）の単体が緑。Windows 実機の Delete キーでのごみ箱・大きな 1 ファイルの途中の取り消しの手触りは未実測*
`tako_sleep_guard`	対応	—	実機実測: powercfg /requests の SYSTEM に tako のアサーションが出て mode=off で消える。蓋閉じは lid-guard.json の生成まで確認 + セルフテスト項目 120 / 121。バッテリー継続（#1473）は判定も lid action のバッテリーレールも実装済みだが、残量の取得が未実装なので実機では安全弁（battery-unknown）で降りる = 実質 AC のみ・実機未検証
`tako_port_detect`	対応	—	実機実測: スライス 9 で tako list が 8123/node.exe を拾い、psmux の偽 listen 21 個を 1 つも報告しない + セルフテスト項目 55（ON/OFF）
`tako_fda`	対象外	Windows に macOS の TCC（フルディスクアクセス）に相当する仕組みが無い	OS の仕様: Windows に TCC（フルディスクアクセス）相当の仕組みが無いので許可を求める対象が無い（#515 の判定テストが固定）
`tako_shell_integration`	一部対応	tako のペインの PowerShell は起動引数で統合を読む（$PROFILE は書かない・実行ポリシーが Restricted でも効く。#2432）。器（psmux）越しは側路で届く（#766）。ペインの中で手で起こした入れ子の PowerShell には統合が入らない	実機実測: #766 で側路の state が unknown → idle、exit_code=3、cwd が OSC 7 由来で追従。実機 shell_integration_powershell 7/0（#525）。#2432 の起動引数の形は Windows CI の同テスト（実行ポリシー Restricted）で確認、実機は未実測
`tako_stale_binary`	一部対応	古いバイナリの検知と警告は動く。バナーの「張り直す」はハーネス更新と同じ実装で、終了要求は #1599 で Windows にも入ったが、Windows には穏当な終了要求が無いので CLI は強制終了（TerminateProcess）になり、実機での通しは未実測（#1067 / #1599）	実機実測: #936 の Windows 11 実測（隔離 GUI + 偽 claude）: 実行中プロセスのパスを境界 B5（`procinfo::image_path`）で解決し、`tako stale-binary status` が stale=true / spawned_version=1.0.0 / current_version=1.0.1 を返してバナー「claude 1.0.1 が利用可能です（このセッションは 1.0.0）」が出る。claude の自己更新と同じ形（旧 exe を改名 → 新 exe を同じ名前で設置）でも stale=false → true へ変わる。張り直しの終了要求は #1599 で Windows にも入った（CI の Windows ジョブの実プロセステストで確認）が、張り直しの通しは未実測
`tako_check_health`	対応	—	実機実測: #937 の Windows 11 実測: MCP `tako_check_health` が HTTP 200 で healthy=true / tmux_available=true / persist_enabled=true / version_match=true / issues=[] を返す。#2092 の `encoding_pin` 節（ペインの文字コード固定）は Windows CI の実 ConPTY で、注入で諦めさせたペインを `gave_up`・いまのコードページ 437 で名指しし、issues に `check=encoding_pin` を出す（issue2092_encoding_pin_health）
`tako_queue`	未対応 / 未実測	PC 全体のメモリ・CPU とプロセスごとの消費の計測（境界 B29）は macOS だけ。Windows は機の値を「まだ採れない」と返す（#2000）。tako のペインの cargo が共有する札（jobserver・境界 B31）も unix の fifo なので Windows では配らない（cargo は従来どおり自前の並列で走る。Windows の名前付きセマフォに cargo が従うかは未実測）	未実測
`tako_telemetry`	対応	—	実機実測: #937 の Windows 11 実測: `tako telemetry status` → `on` → `status`（true）→ `off` → `status`（false）の往復
`tako_test_residue`	対応	—	実機テスト: test_residue の単体 12 本 + tako-core の test_data_residue（子プロセスを起こして dir の有無を実測。TMP / TEMP を使い捨てへ向けるので Windows でも同じ経路を通る）
`tako_mod`	未対応 / 未実測	実装はプラットフォーム共通で macOS と同じ経路を通るが、Windows 実機での実測がまだ無い（動く見込み。失敗したらまずここを疑う）	未実測

セットアップと設定

対応 10・一部対応 2・未対応 / 未実測 1

機能	状態	差分	根拠
`tako_setup`	対応	—	実機実測: #937 の Windows 11 実測: `tako setup --check` が claude（未認証）/ psmux / git / tailscale / スリープ防止 / MCP 未登録を正しく列挙し、`--changes --json` が revision 17 と未適用一覧を返す。対話の通し（エージェント起動）は実機の claude が未認証のため未実測
`tako_setup_bootstrap`	一部対応	3 系統とも状態照会と公式手順の案内はできるが、導入の実行代行は claude だけ（#1057 で実機実測）。codex / agy の install.ps1 は実在するが未実測なので代行せずコマンドを案内する（実行代行は #525 の範囲）	実機実測: #1057 の Windows 11 実測: 隔離 USERPROFILE + PATH 剥ぎで `tako setup` が install（install.ps1 を -ExecutionPolicy Bypass -File で実行）→ path（ユーザー環境変数 Path へ追記・undo-path で完全復帰）→ auth 誘導まで到達。2 回目は無言で素通り。#989 で足した codex / agy は recipe の tako_can_run=false（状態照会・PATH・認証誘導は動くが install は代行しない）
`tako_setup_changes`	対応	—	実機テスト: changes.yaml の連番・platforms 絞り込みテストが実機で緑（#525 が platforms: を最初に使う）
`tako_setup_deps`	一部対応	依存の検出はできるが、導入の実行代行は macOS（Homebrew）だけ。Windows は winget のコマンドを案内する	実機実測: #1057 の Windows 11 実測: `tako setup deps` が器（psmux）/ git / tailscale を実際の解決結果つきで列挙し、install は winget を代行せず not_delegable で理由 + コマンドを返す
`tako_setup_mcp`	対応	—	実機実測: #937 の Windows 11 実測: `tako setup-mcp` が claude の設定（スクラッチ HOME 側）へ tako を登録し旧内容を backups へ退避する。別途、実 HOME の登録に対して `claude mcp list` が `tako.exe mcp serve` を Connected と健康判定したので、stdio ブリッジ自体も Windows で通る
`tako_setup_models`	未対応 / 未実測	実装はプラットフォーム共通で macOS と同じ経路を通るが、Windows 実機での実測がまだ無い（動く見込み。失敗したらまずここを疑う）	未実測
`tako_settings`	対応	—	実機セルフテスト: 項目 96 / 120（プロファイルタブ・スリープ防止タブの表示構成）
`tako_migrate`	対応	—	実機セルフテスト: 項目 123（実 dispatch で自動マイグレーション）+ migrations の単体 20 本が実機で緑
`tako_agents_sync_rules`	対応	—	実機実測: #937 の Windows 11 実測: `tako agents sync-rules --source <正本>` が claude のグローバル指示へマーカーブロックを書き（action=updated + .bak 生成）、未導入の codex / agy は理由つきで skip される
`tako_config_share`	対応	—	実機実測: #937 の Windows 11 実測: `tako config init` が共有リポジトリを作って初回コミット（7 ファイル）、`tako config` が差分（same 4）を出し、`tako config pull` が 1 件取り込む
`tako_platform`	対応	—	実機テスト: platform_parity 13 本と support の単体が実機で緑（判定は純粋関数）
`tako_agent_support`	対応	—	実機テスト: agent_parity 5 本と agent_support の単体 15 本が緑（判定は純粋関数で OS を見ない）
`tako_context_budget`	対応	—	実機テスト: context_budget の単体 18 本と番犬 context_budget.rs（判定・移送とも純粋関数でプラットフォーム分岐が無い）

リモートアクセス

対応 2・一部対応 2・未対応 / 未実測 8

機能	状態	差分	根拠
`tako_remote_start`	未対応 / 未実測	remote デーモンの起動に unix 前提の処理（setsid / シグナルマスク）が残っており、Windows 実機での通し確認も未了（停止は #1599 で境界の終了要求と admin API の shutdown へ寄せた）	実機テスト: 実機の cargo test で remote::tests の 2 件（daemon_stop_impl / is_process_alive）が失敗。うち is_process_alive は「非 unix では常に false」という製品側の穴で #1557 で解消し、daemon_stop_impl が見ていた正体確認の素通りは #1616 で解消（どちらも実機の再測は未了）。トークン・QR などの秘密のファイルと置き場は、#1632 まで何もせず %APPDATA% の ACL の継承まかせだったが、境界 platform::private_file が継承を切った本人 + SYSTEM だけの DACL で作るようにした（unix の 0600 / 0700 に当たる）。CI の Windows ジョブが実ファイルの ACL を Win32 と icacls の 2 通りで読み戻し、旧アーム（TAKO_1632_LEGACY=1）では継承のままなことも同じ回で確かめている
`tako_remote_stop`	未対応 / 未実測	remote デーモンの起動に unix 前提の処理（setsid / シグナルマスク）が残っており、Windows 実機での通し確認も未了（停止は #1599 で境界の終了要求と admin API の shutdown へ寄せた）	実機テスト: #1616 で Windows も正体確認を通るようになり、daemon_stop_impl はpid再利用時にkillしないは両 OS とも「撃たずに中止」を見る。#1599 で停止を境界 platform::process::terminate（Windows は TerminateProcess）と admin API の shutdown（OS を問わない穏当な停止）へ寄せ、止められなければ stopped: true を返さず Err にした。CI の Windows ジョブで、停止の芯が自分で起こした子を実際に止めること・正体の違う pid（正規経路 / stale 経路）を撃たないこと・shutdown が管理トークンでだけ受け付けることを実プロセスで確認。daemon の起動（#971）が Windows で通らないので、実 daemon の停止の通しは未実測
`tako_remote_status`	未対応 / 未実測	#1038 で serve の中継先をループバック TCP へ変えたので、`unix socket serve target is not supported on Windows` で止まる原因は無くなった。ただし Windows 実機での通し（setup の 4 段目 → デーモン起動 → スマホからの接続）は未実測（#971）	実機実測: #937 の Windows 11 実測: `tako remote status` は running=false を返すが、デーモンを起動できないので常にこの状態（#971）
`tako_remote_setup`	未対応 / 未実測	#1038 で serve の中継先をループバック TCP へ変えたので、`unix socket serve target is not supported on Windows` で止まる原因は無くなった。ただし Windows 実機での通し（setup の 4 段目 → デーモン起動 → スマホからの接続）は未実測（#971）	実機実測: #937 の Windows 11 実測（#1038 の修正前）: 1〜3 段（Tailscale 検出 / ログイン / HTTPS 証明書）は OK で、4 段目の serve 設定が `unix socket serve target is not supported on Windows` で失敗した。#1038 でこの原因は取り除いたが、実機での再測はまだ（#971）
`tako_remote_devices`	未対応 / 未実測	#1038 で serve の中継先をループバック TCP へ変えたので、`unix socket serve target is not supported on Windows` で止まる原因は無くなった。ただし Windows 実機での通し（setup の 4 段目 → デーモン起動 → スマホからの接続）は未実測（#971）	実機実測: #937 の Windows 11 実測: `tako remote devices list` は running=false の形を返すが、デーモンを起動できないので端末を登録できない（#971）
`tako_remote_agents`	未対応 / 未実測	#1038 で serve の中継先をループバック TCP へ変えたので、`unix socket serve target is not supported on Windows` で止まる原因は無くなった。ただし Windows 実機での通し（setup の 4 段目 → デーモン起動 → スマホからの接続）は未実測（#971）	実機実測: #937 の Windows 11 実測: `tako remote agents` は agents=[] を返し走査そのものは動く（#877 の境界）が、`tako remote setup` が serve 設定で失敗しデーモンを起動できない（#971）
`tako_remote_messages`	未対応 / 未実測	remote デーモンの起動に unix 前提の処理（setsid / シグナルマスク）が残っており、Windows 実機での通し確認も未了（停止は #1599 で境界の終了要求と admin API の shutdown へ寄せた）	実機実測: #937 の Windows 11 実測: CLI が <SESSION_ID> を要求するところまで確認。実機の claude が未認証で会話を作れないため本体は未実測（デーモン側は #971 でブロック）
`tako_remote_scrollback`	対応	—	実機実測: #972 の Windows 11 実測（psmux 3.3.7・同一バイナリの A/B）: 既定では実経路テスト `remote_scrollback_e2e`（実 psmux + 偽 IPC サーバー）がセッション名と数値ペイン ID の両方で緑、`TAKO_972_LEGACY=1` では `psmux: no server running on session '<socket>__<pane id>'` で落ちる（#937 が報告した症状そのもの）。数値 ID の解決に要る IPC クライアントの Windows 実装も #972 で入れた（それまでは `Windows の IPC は未実装` の 1 行だった）
`tako_open_remote`	一部対応	Windows の OpenSSH は接続多重化（ControlMaster）に対応しないため、操作ごとに独立した SSH 接続になる。鍵・ssh-agent で入れる相手は変わらないが、パスワード認証しか無い相手はツリーの展開やファイルの取得のたびに認証が要る。接続が生きているかもソケットで判定できないので、切断後の自動再接続（#1040）も armed にならない（#1090）	実機実測: #1090 の Windows 11 実測（OpenSSH_for_Windows_10.0p2）: ControlMaster 系を渡すと接続の前に `getsockname failed: Not a socket` / exit -1 で死に、渡さないと同じ相手へ exit 255（`Could not resolve hostname` / `Host key verification failed`）まで進む。渡さない形にしたうえで到達不能ホストの 3 経路（split / tab / pane）が理由 + 次の一手を出してローカルのシェルへ戻ることを実測
`tako_remote_folder`	一部対応	同梱の OpenSSH クライアントで開けるが、接続多重化（ControlMaster）が無いので操作ごとに認証が起きる（パスワード認証しか無い相手は展開のたびに聞かれる。接続が生きているかも判定できない。#1090）。ペインの ssh を検知した自動追加（#976）は、プロセスのコマンド行を採れないので働かない（明示的に開く経路だけが使える）	実機実測: #1090 の Windows 11 実測: ControlMaster 系を渡した sftp は `getsockname failed: Not a socket` で握手にすら進まないが、渡さないと同じ相手へ SSH の握手が進む（`Host key verification failed` まで到達）。渡さない形で `tako remote-folder open` / `ls` が実 SSH 先の一覧を返すことを実測
`tako_ssh_hosts`	対応	—	実機テスト: ~/.ssh/config の解析は純粋関数で、remote_fs / ssh_hosts の単体が実機で緑（ホーム解決は #870 で一本化）
`tako_remote_shortcuts`	未対応 / 未実測	#1038 で serve の中継先をループバック TCP へ変えたので、`unix socket serve target is not supported on Windows` で止まる原因は無くなった。ただし Windows 実機での通し（setup の 4 段目 → デーモン起動 → スマホからの接続）は未実測（#971）	未実測

アップデート

一部対応 1

機能	状態	差分	根拠
`tako_update`	一部対応	更新の確認・リリースノートの表示・適用（インストーラーを取得元・大きさ・sha256 で検査して無言で起動し、tako が終わってから入れ替えて起動し直す）は実装済みだが、適用の通しは Windows 実機で未実測（#2434）。ポータブル版・開発ビルドはアプリ内では更新しない	実機セルフテスト: 項目 90（更新画面と Markdown のリリースノート）+ #587 / #723 で実機の配布物生成とバージョン解析を実測。適用（#2434）は偽の配布元からの取得・検査・インストーラーへの指定を単体（Windows CI を含む）で確認、実機の通しは未実測

この表の作り方

正本は crates/tako-core/src/platform/support.rs の対応マトリクスです。判定を変えるときは根拠（実機セルフテストの項目・実機で緑のテスト名・実測の記録）を同時に書く必要があり、書かずに「対応」へ倒すとテストが落ちます。

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

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

作者のサイト（takushio2525.com） tako のデータの扱いプライバシーポリシー Cookie 設定