WindowsにPi（pi-coding-agent）を入れた直後に「fd not found. Downloading…」で失敗する原因と最短で直す手順

WindowsにnpmでPi（pi-coding-agent）を入れて初回起動したら、fd not found. Downloading... のあとに「Binary not found in archive」などのエラーで止まる。これは「fd自体が壊れている」のではなく、初回セットアップ時に必要な展開コマンドがWindows側で見つからないことが主因になりやすいトラブルです。この記事では、最短で復旧する回避策から、再発させないための恒久対応までをまとめます。

WindowsにPi（pi-coding-agent）を入れた直後に「fd not found. Downloading…」で失敗する原因と最短で直す手順

起きている現象：初回起動でfdの自動導入が失敗する

典型的には、PowerShell（Windows Terminal）で pi を初めて実行した直後に、次の流れで止まります。

fd が見つからないため自動ダウンロードを開始する
ダウンロード後の展開・配置で失敗して「fd.exeが見つからない」系のエラーになる
（例：展開先フォルダにはあるはずなのに fd.exe を発見できず終了）

この時点でPiが完全に壊れたように見えますが、実際は「展開処理が成立していない」ケースが多いです。

根本原因：Windows環境でzip/tarを展開する前提が崩れている

Piは初回起動時に、必要な外部ツール（fd や rg など）を自動で揃えようとします。ところが、その実装が「tar や unzip コマンドがシェルから呼べる」ことを前提にしている場合、Windowsの標準環境ではこの前提が崩れます。

unzip：多くのWindows環境では標準で存在しません
tar：Windows 10/11でも入っていることはありますが、環境やPATH次第で見つからないことがあります
その結果、アーカイブの展開が失敗 → 期待する場所に fd.exe が置かれない → 「アーカイブ内にない」扱いでエラーになる、という流れが起きがちです

「ダウンロードはできたのに、バイナリが見つからない」と表示されるのはこのためです。

まずは最短で直す：Git Bashで一度だけ起動してセットアップを完了させる

もっとも手早い回避策は、Windows Terminalから Git Bash を起動して pi を一度実行する方法です。Git for Windows には、展開系コマンド（環境によっては tar 相当など）が揃っているため、初回のツール導入が最後まで通りやすくなります。

手順

Windowsに Git for Windows を入れている（未導入ならインストール）
Windows Terminalでプロファイルを Git Bash に切り替える（またはGit Bashを直接起動）
pi を実行して初回セットアップを完走させる
以後はPowerShellから pi を実行してもエラーが出なくなることが多い

一度 fd が正しく配置されれば、次回以降は再ダウンロードが走らず安定します。

再発防止の恒久対応：PowerShell側で展開コマンドを用意する

「毎回Git Bashを使うのは避けたい」「自動導入をPowerShellで完結させたい」場合は、PowerShell側で展開手段を整えるのが確実です。方針は大きく3つあります。

対応A：Windows標準の`tar`が使えるか確認してPATHを通す

Windows 10/11でも tar が動く環境は多いです。まずPowerShellで次を確認します。

tar --version が通るか
通らない場合は、Windowsの環境差・PATH問題の可能性があるため、次の対応B/Cへ

対応B：unzip相当を導入する（おすすめはscoop / winget）

unzip が無いのが原因なら、導入するだけで解決することがあります。

Scoop を使う場合：scoop install unzip
winget で導入できるツールを選ぶ（7-Zipなど）
7-Zipはコマンドライン連携もでき、zip展開の代替になりやすいです

環境管理をまとめたい人はScoopが相性良いです。

対応C：アーカイブ展開をPowerShellで完結させる発想に切り替える

もし「unzip コマンド」が前提の実装に当たっているなら、根本的にはアプリ側が Expand-Archive（PowerShell標準）などで展開できる設計のほうがWindowsに強いです。利用者側でできることとしては、次のような運用が現実的です。

初回だけGit Bashで通す（最小労力）
もしくは unzip/tar を用意してPowerShellでも同条件を満たす

「Windowsの標準だけで全自動」は、アプリ側がPowerShellネイティブ展開を採用しない限り難しい場面が出ます。

`rg` も同種の影響を受けることがある

同じ仕組みで rg（ripgrep）も自動導入対象になっている場合、環境によっては fd と同様の症状が出る可能性があります。すでに rg がPATHに入っている人は表面化しませんが、初回セットアップの安定性を上げたいなら、fd と合わせて展開手段を整えておくのが安全です。

うまくいかないときのチェックリスト

最後に、復旧が詰まるポイントを潰すためのチェック項目をまとめます。

PowerShellで where fd / where rg を実行して、既存の同名ツールが干渉していないか
~\.pi 配下（ユーザーフォルダ内のPi作業ディレクトリ）に、途中まで展開された残骸が大量に残っていないか
- 失敗を繰り返す場合は、fd 関連の一時フォルダを整理してから再実行すると通ることがあります
セキュリティソフトが実行ファイルの生成・配置をブロックしていないか
Windows Terminalのプロファイル違い（PowerShell / Command Prompt / Git Bash）で挙動が変わるか

まとめ：最短復旧は「Git Bashで一度だけ起動」、根治は「展開コマンドを揃える」

このエラーは「fdが壊れている」よりも、「Windows環境でzip/tar展開の前提が満たされていない」ことが原因になりがちです。まずは Git Bashで一度だけ pi を動かして初回セットアップを通すのが最短ルート。継続的にPowerShell運用したいなら、tar / unzip 相当の展開手段を整備して、初回の自動導入が確実に完走する状態を作るのが効果的です。