You type antigravity . in a WSL2 terminal and a window does open. But it isn't quite the Linux build you expected, and every save has a small pause. Which Antigravity is actually running? Many of us keep tweaking settings without ever answering that.
A write-up on Zenn lays out the situation well: the deb package in WSL only points you back to a Windows install, uninstalling it can leave another entry point behind, and the Windows executable can be found first on the PATH. This article takes that report as a starting point and narrows it to two questions — what launches, and which one to keep.
One caveat up front. I work on a Mac as an indie developer and haven't reproduced WSL2 myself. The commands below rely on standard Linux and WSL behavior; anything Antigravity-specific comes from public reports. Please compare the output on your own machine as you read.
List everything that could be called
which antigravity prints only the first hit. type -a prints them all.
hash -r # drop the shell's cached lookups
type -a antigravity # every match, in PATH orderThe first line is what actually runs. If it starts with /mnt/c/, you're launching the Windows executable. If it's under /usr/local/bin or /opt, it's the Linux side.
/mnt/c/ shows up because WSL appends the Windows PATH to the Linux PATH by default. The appendWindowsPath option in /etc/wsl.conf controls that.
When there are several entry points, look inside
Even if the first line is /usr/bin/antigravity or /bin/antigravity, that may not be the real program. In the Zenn report, the deb installs a thin entry that only tells you to install on Windows; while it's first, the Linux build never runs.
p="$(command -v antigravity)"
readlink -f "$p" # where a symlink really points
file "$p" # ELF = real binary, script = relay
head -c 300 "$p" | cat -v # peek inside if it's a scriptIf file says "ASCII text executable" or "shell script", it's a relay. Open it and check whether it calls the Windows side or just prints a message.
Decide by where your code lives
Once you know what launches, the next question is which build to keep. One axis settles it: which filesystem holds your code.
| Where the code lives | Better fit | Why |
|---|---|---|
/home/<user>/ (WSL ext4) | Linux build, or the Windows app connecting into WSL | I/O stays on the Linux side |
/mnt/c/ (Windows NTFS) | Windows build | Avoids crossing the boundary |
| Scattered across both | Consolidate first | It matters more than the launcher |
I wrote about slow file watching across /mnt/c in WSL2 file watching problems. If the launcher is right and things are still slow, location is the next suspect.
Narrowing it to one entry point
If you decided to keep the Linux build, here is the cleanup. Only remove what you've inspected.
sudo apt purge -y antigravity || true # remove the deb that creates the thin entry
hash -r
type -a antigravity # recheck what remainsIf you unpack a tar.gz under /opt, add a single symlink in /usr/local/bin. Don't unpack under /mnt/c; permissions break there. To drop Windows from the PATH entirely, add this to /etc/wsl.conf:
[interop]
appendWindowsPath = falseYou'll need to run wsl --shutdown from Windows for it to take effect. Note that this removes every Windows command from the PATH — code, explorer.exe, and so on — not just Antigravity. If you call those from WSL, putting /usr/local/bin first in ~/.bashrc has a smaller blast radius.
The line I'd draw
Before blaming settings or versions, be able to say in one line what launches. Once you can paste the first line of type -a, the rest of the investigation gets much shorter.
If the app itself fails to start, see triaging "server crashed unexpectedly". For agent commands failing in Windows shells, the PowerShell preflight is a good companion.
Start by running type -a antigravity once in your current terminal and noting the first line.