WSL で antigravity が「command not found」になるとき、PATH を触る前に確かめる 4 つのこと

WSL のターミナルで antigravity . と打って、command not found が返ってきた夜がありました。Windows 側ではアイコンから普通に開けるのに、ターミナルからは存在しないことになっておりました。個人開発で Linux 側のリポジトリを触る機会が増えてから、こういう「入口だけ見えない」状態に何度か当たっております。

最初にお伝えしたいのは、この記事の検証範囲です。私の手元では、実際の WSL 上で Antigravity を起動して確かめたわけではありません。確かめたのは、次に載せるシェル関数の分岐（見つかる場合・見つからない場合）を、擬似コマンドで動かすところまでです。フォーラムで報告されている直し方は、報告者ごとに食い違っています。ですから、ここでは「どれが正解か」ではなく「どの順で何を見れば、自分の環境の原因が絞れるか」を書き残します。

まず、何が「見つからない」のかを言葉にする

command not found には、実は二通りの意味が混ざっています。

コマンドの実体が、そもそも WSL から見える場所にないケース
実体はあるのに、PATH に入っていないケース

前者なら、探す場所を増やす必要があります。後者なら、PATH か別名で済みます。この二つを分けずに .bashrc を書き換え始めると、直ったのか偶然通ったのかが分からなくなります。

最初の一手は、次の 1 行です。

type -a antigravity agy 2>&1

何も出なければ、どちらの名前も PATH 上にありません。コマンド名が antigravity なのか agy なのかは、版や入れ方で違うという報告があります。両方を並べて見ておくと、名前の思い込みを先に消せます。

次に、Windows 側のランチャーが見える場所にあるか

WSL からは、Windows のドライブが /mnt/c として見えます。コミュニティの報告では、ランチャーは Windows 側の次のような場所にあるとされています。

ls /mnt/c/Users/*/AppData/Local/Programs/Antigravity/bin/ 2>&1

ここにファイルが見えれば、「実体はあるが PATH にない」状態です。見えなければ、インストール先が違うか、ドライブの割り当てが違うか、そもそも別ユーザーで入れている可能性があります。パスの細部は環境で変わるので、報告されている場所をそのまま信じず、ご自身の画面で確かめていただければと思います。

見つからない理由を教えてくれる関数にする

毎回この確認を手で打つのは面倒です。そこで、PATH にあればそれを使い、無ければ Windows 側を探し、それでも無ければ理由を言って止まる関数を .bashrc に置いています。

# 何を解決するか: antigravity が PATH に無い WSL でも、同じ 1 語で開けるようにする
# 見つからないときは、黙って失敗せず、どこを探したかを表示する
ag() {
  local target="${1:-.}" bin
  if command -v antigravity >/dev/null 2>&1; then
    bin="antigravity"
  else
    bin="$(ls /mnt/c/Users/*/AppData/Local/Programs/Antigravity/bin/antigravity 2>/dev/null | head -n 1)"
    if [ -z "$bin" ]; then
      echo "ag: antigravity が PATH にも /mnt/c 配下にも見つかりません" >&2
      return 127
    fi
  fi
  "$bin" "$target"
}

なぜこう書くかというと、ポイントは終了コード 127 と標準エラーへのメッセージです。無言で何も起きないより、「探したが無かった」と分かるほうが、次の切り分けに進めます。

擬似コマンド（引数を表示するだけの小さなスクリプト）を PATH の先頭に置いて動かしたところ、見つかる場合は渡したパスがそのまま表示され、置かない場合は 127 とメッセージが返りました。分岐は意図どおりでした。ただし、これは関数の論理の確認にすぎません。実際の Antigravity が WSL のフォルダを正しく開くかどうかは、別の話です。

開けたのに「Windows 側のアプリ」が立ち上がるとき

関数が通っても、Linux 側のフォルダが Windows のアプリとして開き、WSL の中身を見ていないことがあります。報告では、ランチャー内部で使う WSL 拡張の識別子が合っていない、というのが原因候補に挙がっています。ここはランチャーのファイル自体を書き換える対処で、版が上がると上書きされるかもしれません。

私はこの対処を、まだ自分では試しておりません。試すなら、書き換え前に元のファイルをコピーしておく。それだけは守ってください。戻せない変更は、動作確認より先にバックアップを——これが私の線引きです。

認証のやり取りが WSL と Windows のブラウザのあいだで止まる、という報告もあります。その場合は .wslconfig のネットワーク設定が話題になりますが、全体に影響する設定なので、症状がはっきりしてから触るのが安全だと思います。

切り分けの順番

ここまでを、手を動かす順に並べ直します。

順番	確かめること	分かること
1	`type -a antigravity agy`	名前の違い・PATH の有無
2	`ls /mnt/c/Users/*/AppData/...`	実体が WSL から見えるか
3	上の `ag` 関数	見つかる／見つからないを即判定
4	開いた先が Linux か Windows か	拡張の識別子・ランチャーの問題

直らない場合の手がかりとして、フォーラムのWSL でのランチャー破損の報告と、WSL での利用をまとめた投稿が参考になりました。内容は版によって古くなりうるため、読むときは日付と版を見比べてください。

まずは type -a antigravity agy の 1 行だけを、いまの環境で打ってみていただければと思います。出力を一つ持っているだけで、次に何を疑えばよいかが、ずいぶん見えやすくなります。