Four things to check before touching PATH when antigravity says command not found in WSL

I typed antigravity . in a WSL terminal one evening and got command not found. The app opened fine from the Windows icon, yet the terminal insisted it did not exist. As an indie developer who keeps more and more repositories on the Linux side, I have run into this "visible from one side only" situation a few times.

First, an honest note about scope. I did not launch Antigravity on a real WSL setup for this article. What I did verify is the branching of the shell function below (found and not found), using a stand-in command. Fixes reported in forums disagree with each other, so I will not claim to know the one right answer. What I can offer is an order of checks that narrows down the cause on your own machine.

Say what exactly is "not found"

command not found hides two different situations.

1. The executable is not reachable from WSL at all.
2. The executable exists but is not on PATH.

The first needs a wider search. The second needs a PATH entry or an alias. If you start editing .bashrc before separating them, you will not know whether you fixed anything or just got lucky.

Start with one line:

type -a antigravity agy 2>&1

If nothing prints, neither name is on PATH. Reports differ on whether the command is antigravity or agy depending on version and install method, so checking both removes a naming assumption early.

Is the Windows launcher visible from WSL?

WSL exposes Windows drives under /mnt/c. Community reports place the launcher somewhere like this on the Windows side:

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

If a file shows up, you are in the "exists but not on PATH" case. If not, the install location, the drive mapping, or the Windows user may differ. Paths vary, so please confirm on your own screen rather than trusting any reported location.

A function that explains itself

Typing those checks every time gets tiring. I keep a function in .bashrc that uses PATH if possible, falls back to the Windows side, and otherwise stops with a reason.

# What it solves: open Antigravity with one word even when it is not on PATH in WSL.
# When nothing is found, fail loudly and say where it looked.
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 not found on PATH or under /mnt/c" >&2
      return 127
    fi
  fi
  "$bin" "$target"
}

Why it is written this way: the exit code 127 and the message on stderr matter. A silent failure gives you nothing to act on; "I looked and it was not there" tells you which check to run next.

I put a tiny script that just echoes its argument at the front of PATH and ran the function. When the stand-in was present, the path I passed was printed back; when it was absent, I got 127 and the message. The branches behaved as intended. That only proves the function's logic, though. Whether the real Antigravity opens a WSL folder correctly is a separate question I have not tested.

It opened, but as the Windows app

Even when the function succeeds, the folder may open in the Windows app without seeing the Linux filesystem. One report points at the WSL extension identifier used inside the launcher. That means editing the launcher file itself, which an update may overwrite.

I have not tried this fix myself. If you do, copy the original file first. Back up before you change anything you cannot easily undo is the line I keep.

Some people also report the sign-in handshake stalling between WSL and the Windows browser, where .wslconfig networking settings come up. That setting affects everything in WSL, so I would wait until the symptom is clear.

The order, in one table

If it still fails, a forum report on a broken launcher under WSL and a write-up on using it in WSL helped me. Both may age with new versions, so compare dates and versions as you read.

Start by running type -a antigravity agy in your own environment. Holding one real output makes the next suspect much easier to see.