Antigravity CLI (agy) on WSL: broken launcher & missing scripts (manual repair report

Google Antigravity
1

I wanted to use the agy CLI from inside a WSL environment so that I could run agy . in a WSL terminal and have Antigravity open that directory, similar to how code . works with VS Code.
Out of the box this does not work due to several packaging issues in the current Windows installer.
Below is a full repair report with the manual steps I had to perform to make it work.

1. Making agy visible from WSL

Problem
When running agy from a normal WSL shell, the command is not found.

Fix
Create a symlink in WSL that points to the main launcher script installed on Windows:

ln -sf "/mnt/c/Users/<USER>/AppData/Local/Programs/Antigravity/bin/antigravity" \
  ~/.local/bin/agy

After this, agy is at least callable from WSL, but the next issues appear.

2. Wrong WSL extension id in the launcher

Problem
Even after agy is callable, running agy . opens an empty window and does not attach to the WSL folder. Antigravity starts, but it is not connected to the WSL workspace.

Root cause
The launcher script shipped by Antigravity still looks for the Microsoft WSL extension:

WSL_EXT_ID="ms-vscode-remote.remote-wsl"

However, Antigravity actually bundles a Google-branded WSL extension instead:

google.antigravity-remote-wsl

Fix
I edited the launcher script to use the correct extension id.

Target file

C:\Users\<USER>\AppData\Local\Programs\Antigravity\bin\antigravity

Change

- WSL_EXT_ID="ms-vscode-remote.remote-wsl"
+ WSL_EXT_ID="google.antigravity-remote-wsl"

After this change Antigravity at least tries to talk to the correct extension, but another error shows up.

3. Missing WSL helper scripts

Problem
With the extension id fixed, running agy . now fails with:

wslCode.sh: not found

Root cause
The Antigravity Windows installer does not include the WSL helper scripts that the WSL extension expects. Those scripts are present in the official VS Code Remote WSL extension, but missing from the Antigravity installation.

Fix (local workaround)
I copied the helper scripts from the VS Code extension into the corresponding Antigravity extension folder.

  • Source (VS Code WSL extension):

    %USERPROFILE%\.vscode\extensions\ms-vscode-remote.remote-wsl-0.104.3\scripts\

  • Destination (Antigravity WSL extension):

    C:\Users\<USER>\AppData\Local\Programs\Antigravity\resources\app\extensions\antigravity-remote-wsl\scripts\

  • Files restored:

    • wslCode.sh

    • wslDownload.sh

After copying these files, the agy launcher can finally start Antigravity attached to a WSL folder.

Result

With all three fixes applied:

  • Running agy . from a WSL terminal correctly launches Antigravity.

  • The IDE automatically attaches to the current WSL directory, which I assume is the intended behavior (parity with code .).

This suggests that the current Antigravity installer has:

  1. A wrong WSL extension id in the antigravity launcher script; and

  2. Missing WSL helper scripts (wslCode.sh, wslDownload.sh) in the bundled extension.

Note that a future Antigravity update will likely overwrite these local changes, so the workaround would need to be reapplied unless the installer is fixed.

I hope this report helps reproduce and fix the issue on the official side. If additional logs or environment details are useful, I am happy to provide them.

21 Likes
AntiGravity can't access the browser while running in WSL
Antigravity stuck in a zombie state, "Antigravity server crashed unexpectedly. Please restart to fully restore AI features."
3

Thank you this is extremely helpful! Hopefully the devs see it.

1 Like
4

Signed up to leave a like. I used the same steps from different sources. The only missing thing from here is to make the browser work too. Here are the steps for it:

3 Likes
5

Thank you very much!! It helped a lot!!! :partying_face:

I just needed to skip the first step because agy was not available on my system, the command was antigravity instead. But it was already working calling from WSL

1 Like
7

Very helpful, this should be a very quick fix on the side of the Google Antigravity devs, not sure why this manual workaround still has to be done. Either way, you saved me quite a lot of headaches.

1 Like
9

The simplest was i found is to connect to wsl with ssh since ssh works in antigravity.
this works perfectly, and fast.

guide: [How to Enable SSH Access to WSL2](somoit net)

1 Like
12

@googleplsfix Annoying and seemingly have to do this after each Antigravity update that comes..

1 Like
13

This may sound crazy but can’t we just install agy for Linux from Windows WSL?

14

[GUIDE] Fix Antigravity CLI (agy) on WSL: From Setup to Repair

If you are trying to use Antigravity with WSL and encountering “Command not found” or “404 Not Found” errors, follow these steps to perform a complete manual repair.

Step 1: Install and Initialize Ubuntu

If you haven’t already, install Ubuntu from your Windows Terminal:

  1. Install: wsl --install.

  2. Initialize: Open the Ubuntu app, create your username (e.g., everarpitraj), and set a password.

Step 2: Configure WSL Networking (.wslconfig)

To ensure the IDE can communicate with the Linux subsystem without network blocks, create a configuration file.

  1. In Windows, press Win + R, type %userprofile%, and press Enter.

  2. Create a new file named .wslconfig (ensure there is no .txt at the end).

  3. Paste the following content:

    Ini, TOML

    [wsl2]
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

  4. Restart WSL by running wsl --shutdown in PowerShell.

Step 3: Make the agy Command Visible in WSL

Create a shortcut so you can launch the IDE by typing agy . in your terminal.

  1. Run this in your Ubuntu terminal:

    Bash

    mkdir -p ~/.local/bin
ln -sf "/mnt/c/Users/abhis/AppData/Local/Programs/Antigravity/bin/antigravity" ~/.local/bin/agy
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

Step 4: Fix the Extension ID in the Launcher

The default launcher looks for the wrong extension ID. You must manually correct it.

  1. Open Notepad as Administrator.

  2. Open: C:\Users\abhis\AppData\Local\Programs\Antigravity\bin\antigravity.

  3. Find WSL_EXT_ID="ms-vscode-remote.remote-wsl".

  4. Change it to: WSL_EXT_ID="google.antigravity-remote-wsl".

  5. Save the file.

Step 5: Restore Missing Helper Scripts

Antigravity is missing critical scripts that bridge the two systems. You can “borrow” these from VS Code.

  1. Open CMD as Administrator and run:

    DOS

    xcopy /E /I /Y "%USERPROFILE%\.vscode\extensions\ms-vscode-remote.remote-wsl-*\scripts\*" "%LOCALAPPDATA%\Programs\Antigravity\resources\app\extensions\antigravity-remote-wsl\scripts\"

    (If you use VS Code Insiders, change .vscode to .vscode-insiders).

Step 6: Fix the “404 Not Found” Server Error

Because Antigravity’s server isn’t on the public Microsoft servers, you must manually download and install the “REH” (Remote Extension Host).

  1. Run this in your Ubuntu terminal:

    Bash

    COMMIT="1504c8cc4b34dbfbb4a97ebe954b3da2b5634516"
mkdir -p ~/.antigravity-server/bin/$COMMIT
cd ~/.antigravity-server/bin/$COMMIT

# Download the official Antigravity Linux Server
wget https://edgedl.me.gvt1.com/edgedl/release2/j0qc3/antigravity/stable/1.16.5-$COMMIT/linux-x64/Antigravity-reh.tar.gz

# Extract and cleanup
tar -xzf Antigravity-reh.tar.gz --strip-components=1
rm Antigravity-reh.tar.gz

Step 7: Final Launch

Navigate to Ubuntu and launch:

Bash

agy .

Result: Antigravity should now launch on Windows, automatically attach to your WSL folder, and activate the AI Agent without any “command not found” or “404” errors.

15

Is this the same error?

Invalid command line argument: -c
Please use ‘wsl.exe --help’ to get a list of supported arguments.

I have wasted days trying to solve this.

If Google is releasing new versions that must be downloaded for the wonderful new reasoning of Gemini 3.1, wouldn’t it be reasonable to fix the “packaging” to make this work? I have to guess there are some of the 1 billion Windows users fighting this problem. It makes the app worthless, with five other IDE choices available, all pushing them away from Gemini. What am I missing?

16

I get the frustration. I spent days stressed out over this. The manual workarounds with scripts or hardcoded commit IDs are super fragile—as soon as Antigravity updates, everything breaks with a 404 error because the hashes don’t match anymore.

Instead of patching the IDE every week, I just created a bash function in WSL that calls the Windows binary directly with the native remote flag. It’s cleaner and survives updates.

How to fix it for good:

  1. Clean up: Delete old symlinks and broken server downloads.

    Bash

    rm -rf ~/.antigravity-server ~/.local/bin/ag ~/.local/bin/agy

  2. Initialize once: Open Antigravity from Windows (Start Menu). Press Ctrl+Shift+P, select Remote-WSL: Connect to WSL, and let it load. This installs the correct server for your current version. Close the app.

  3. Add the smart launcher: Add this to your ~/.bashrc (replace elias with your Windows user).

Bash

ag() {
    local DIR=$(readlink -f "${1:-.}")
    ( /mnt/c/Users/elias/AppData/Local/Programs/Antigravity/Antigravity.exe --remote "wsl+$WSL_DISTRO_NAME" "$DIR" > /dev/null 2>&1 & )
}

Run source ~/.bashrc and you’re set. Now ag . opens the project instantly from WSL without terminal noise, and it won’t break on the next update. Cheers!

1 Like
17

Just adding to the solution pool as this worked for me and automates handling for product updates.

# Antigravity IDE: WSL2 Troubleshooting & Agent Execution

This document outlines the known issues and solutions for running Antigravity IDE agents within a Windows Subsystem for Linux 2 (WSL2) environment, specifically addressing execution permission failures.

## Issue: Agents Cannot Execute Scripts in Workspace

When using Antigravity IDE connected to a WSL2 workspace, agents may fail to execute scripts or terminal commands, often throwing permission errors or indicating they cannot access the workspace correctly.

### Root Causes

There are two distinct layers of security/permission issues that cause this behavior:

1. **WSL Remote Extension Mismatch:** The Antigravity IDE server background processes expect the standard VS Code WSL extension identifier (`ms-vscode-remote.remote-wsl`). However, Antigravity uses its own fork (`google.antigravity-remote-wsl`). This mismatch prevents the proper delegation of execution permissions within the WSL environment.

2. **Agent Workspace Validation:** Antigravity agents have strict safety filters that ensure they only run commands inside allowed folders. Because Windows accesses WSL via translated paths (e.g., `/wsl+ubuntu/home/…`) while the internal WSL path is direct (e.g., `/home/…`), the agent’s path-matching filter rejects execution attempts, believing they are outside the allowed workspace.

## Solution

To permanently resolve these issues, you must apply a background patch script to correct the extension IDs and disable the agent’s workspace validation check.

### Step 1: Create the Persistent Patch Script

This script actively sweeps the Antigravity server directories to fix the remote-wsl extension IDs.

Create a new bash script at `~/.local/bin/patch-antigravity.sh`:

```bash

#!/bin/bash

# Patch Antigravity Server for WSL2 execution permissions

# Finds files that contain ms-vscode-remote.remote-wsl and replaces it with google.antigravity-remote-wsl

if [ -d “$HOME/.antigravity-server/bin” ]; then

find "$HOME/.antigravity-server/bin" -type f \\( -name "product.json" -o -name "\*.js" -o -name "agy" \\) -exec grep -l "ms-vscode-remote.remote-wsl" {} + 2>/dev/null | xargs -r sed -i 's/ms-vscode-remote.remote-wsl/google.antigravity-remote-wsl/g'

fi

```

Make the script executable:

```bash

chmod +x ~/.local/bin/patch-antigravity.sh

```

### Step 2: Hook the Script into Shell Startup

To ensure the patch survives Antigravity IDE updates (which download new server bundles), hook the script into your shell profile so it runs automatically in the background when a new terminal starts.

Append the following lines to the end of your `~/.bashrc` file:

```bash

# Auto-patch Antigravity IDE server for WSL execution on shell startup

if [ -f “$HOME/.local/bin/patch-antigravity.sh” ]; then

bash "$HOME/.local/bin/patch-antigravity.sh" &

fi

```

### Step 3: Disable Workspace Validation

To bypass the path-translation security block for agents:

1. Open Antigravity IDE **Settings** (press `Ctrl + ,` or click the gear icon → Settings).

2. Search for **“workspace validation”**.

3. Under the Agent settings pane, scroll down to the **FILE ACCESS** section.

4. Toggle ON the setting named **Agent Non-Workspace File Access**.

*(This allows the agent to navigate the native Linux `/home/…` paths even when the IDE technically registers the workspace as `/wsl+ubuntu/…`)*.

*(Note: Alternatively, you can simply authorize the agent in the chat window by typing “I am willing to turn off workspace validation” when it hits a directory block. However, this text-based override is **only valid for the current conversation**. You will need to type it again in any new chat thread.)*

### Step 4: Apply and Verify

After completing the setup steps above:

1. Fully reload the Antigravity IDE window (Command Palette → **Developer: Reload Window**).

2. Ask an agent to run a simple command (e.g., `pwd` or `./your-script.sh --help`) to verify execution capabilities are restored.

1 Like