WSL2 のターミナルで antigravity . と打つと、ウィンドウは確かに開きます。ところが、思っていた Linux 版の見た目ではなく、保存のたびに少し間が空く。どちらの Antigravity が動いているのか、その場では分からない——そういう状態で、設定をいじり続けてしまう方は少なくないと思います。
Zenn に、この状況を整理した記録があります。WSL に deb を入れても Windows 側のインストールを案内するだけで終わること、アンインストール後も別の入口が残ること、そして Windows 側の実行ファイルが先に呼ばれうること。この記事は、その記録を手がかりに、起動元の特定とどちらを残すかの判断に絞って書き直したものです。
最初にお伝えしておくと、私の作業環境は Mac で、WSL2 は手元で再現しておりません。ここに並べるコマンドは Linux と WSL の標準的な仕組みに基づくもので、Antigravity 固有の挙動は公開されている報告に拠っています。お使いの環境で出力を見比べながら読んでいただければ幸いです。
まず「どれが呼ばれているか」を一覧にする
which antigravity は最初の1件しか示しません。候補を全部並べるには type -a を使います。
hash -r # シェルが覚えている場所を捨てる
type -a antigravity # PATH 順に、見つかったものを全部表示する出力の一行目が、いま実際に呼ばれるものです。ここに /mnt/c/ で始まるパスが出ていれば、起動しているのは Windows 側の実行ファイルです。/usr/local/bin や /opt 配下なら Linux 側です。
/mnt/c/ が混ざる理由は、WSL が既定で Windows 側の PATH を Linux 側の PATH に連結するためです。この挙動は /etc/wsl.conf の appendWindowsPath で制御されます。
入口が複数あるとき、中身を見る
一行目が /usr/bin/antigravity や /bin/antigravity だったとしても、それが本体とは限りません。Zenn の記録では、deb が置くのは Windows 側のインストールを案内して終わる薄い入口で、これがあると Linux 版は一度も動きません。
p="$(command -v antigravity)"
readlink -f "$p" # シンボリックリンクの行き先
file "$p" # ELF なら本体、script なら中継役
head -c 300 "$p" | cat -v # script の場合は中身を少し読むfile が「ASCII text executable」や「shell script」と答えたら、それは中継役です。中を開いて、Windows 側を呼んでいるのか、メッセージを出しているだけなのかを確かめます。
どちらを残すかは、作業の置き場所で決める
起動元が分かっても、次に迷います。Windows 版を残すか、Linux 版を残すか。判断の軸は一つで、コードがどこのファイルシステムにあるかです。
| コードの置き場所 | 向いている側 | 理由 |
|---|---|---|
/home/<user>/ 配下（WSL の ext4） | Linux 版、または Windows 版からの WSL 接続 | ファイル I/O が Linux 側で閉じる |
/mnt/c/ 配下（Windows の NTFS） | Windows 版 | 越境の読み書きを避けられる |
| 両方に散らばっている | まず置き場所を一本化する | 起動元の問題より先に効く |
WSL2 で /mnt/c を跨ぐファイル監視が重くなる件は、同じサイトの WSL2 でファイル監視が効かないとき に詳しく書きました。起動元が合っていても重いなら、置き場所を疑う順番になります。
切り分けの流れを三行にすると
迷ったら、次の三つだけを順に確かめます。
type -a antigravityの一行目が/mnt/c/かどうか- 一行目が Linux 側なら、
fileで本体か中継役か - 本体なら、コードの置き場所が
/homeか/mnt/cか
この三つで原因の大半は絞れ、残った場合に初めてバージョンや設定を疑うことになります。
入口をひとつに絞る手順
Linux 版を残すと決めた場合の整理です。消してよいのは、中身を確かめたものだけにしてください。
sudo apt purge -y antigravity || true # 薄い入口を作る deb を外す
hash -r
type -a antigravity # 残った入口を再確認tar.gz 版を /opt に展開するなら、/usr/local/bin にシンボリックリンクを一本だけ張ります。展開先を /mnt/c 配下にしないのは、権限の扱いが崩れるためです。Windows 側を PATH から外したい場合は、/etc/wsl.conf に次を書きます。
[interop]
appendWindowsPath = false反映には、Windows 側で wsl --shutdown を実行して WSL を再起動する必要があります。ただし、これは Antigravity だけでなく code や explorer.exe など、Windows 側のコマンド全般を PATH から外します。普段それらを WSL から呼んでいる場合は、設定ごと変えるより、~/.bashrc で /usr/local/bin を PATH の先頭に置くほうが影響は小さく済みます。
私ならこう線引きします
同じ名前のコマンドが複数あるとき、答えを決めるのは PATH の先頭です。Mac で個人開発をしている私自身にも、古い方が呼ばれ続けていたと後から気づいた経験があり、WSL では Windows 側が加わる分だけ、その取り違えが起きやすいのかもしれません。
迷ったときの基準は、重さの原因を決めつける前に、起動元を一行で言えるようにしておくことです。type -a の一行目を貼れる状態になってから、設定やバージョンを疑うようにしています。この順番を守るだけで、遠回りがだいぶ減るのだと思います。
起動の失敗そのものを疑う場合は、server crashed unexpectedly の切り分け も併せてご覧ください。Windows 側のシェルでエージェントのコマンドが通らないときは PowerShell のプレフライト が手がかりになります。
まずは、いまのターミナルで type -a antigravity を一度だけ実行し、一行目を控えてみてください。