How I Got Google Antigravity Working Perfectly with WSL

As a Data Engineer, I spend most of my life in the terminal. Whether I'm optimizing Spark queries or building Python-based Gen AI tools (like my recent work on AI-Hub), Windows Subsystem for Linux (WSL) is non-negotiable. It gives me the rich ecosystem of Linux with the productivity of Windows.

Why WSL? WSL gives you a full Linux kernel on Windows - meaning bash scripts and containers run exactly as they would in production (like Google Cloud). No dual-booting, no VMs. Just native Linux tooling with Windows convenience.

Recently, I started exploring Google Antigravity, Google’s new agent-first IDE. It looks promising for building AI agents, but out of the box, it didn't play nice with my WSL setup.

If you’re like me and trying to run Linux scripts or Python agents inside Antigravity on Windows, you might hit some frustrating walls. Here is the developer log of how I fixed them—specifically getting the CLI, the workspace, and the browser subagent to work natively in Ubuntu.

---

TL;DR

Quick fix checklist:

1. ✅ Ctrl+Shift+P → "Remote-WSL: Connect to WSL"
2. ✅ Create symlink + patch WSL_EXT_ID to google.antigravity-remote-wsl
3. ✅ Enable mirrored networking in .wslconfig
4. ✅ Install Chrome extension manually if needed
5. ✅ [New] Run antigravity-repair if updates break the setup

---

The Problem

I opened a project workspace in Antigravity on Windows. The interface looked great (very VS Code-like), but when I asked the AI agent to run a simple bash command like ls -latr, it choked.

The error was:

text
Invalid command line argument: -l
Please use 'wsl.exe --help' to get a list of supported arguments.

Basically, the Windows-based agent was trying to execute Linux commands via wsl.exe wrappers rather than running them inside Linux. This breaks almost every setup script I use.

---

Step 1: Switch Context, Don't Install

I initially looked for a "WSL Extension" in the marketplace, but the standard Microsoft one wasn't available. It turns out you just need to force Antigravity to look at the "Linux" side of your machine.

1. Open Antigravity.
2. Press Ctrl+Shift+P (Command Palette).
3. Type and select: Remote-WSL: Connect to WSL.

💡 Pro Tip: When the new window opens, make sure you open your project folder using the Linux path (e.g., ~/workspace/dotfiles) rather than the Windows mount path (\\wsl.localhost\...). The Windows mount path (\\wsl.localhost\Ubuntu\home\...) is how Windows accesses your Linux files, but it causes permission issues. Always use the native Linux path (~/...). You'll know it worked when the bottom-left status bar says >< WSL: Ubuntu.

---

Step 2: Fixing the CLI (agy)

I prefer launching tools from the terminal. But if you run agy . from your WSL terminal, it defaults to opening the Windows version of the app, disconnecting you from your Linux environment.

To fix this, we need to patch the launcher.

1. Create a Symlink: First, create a shortcut in Linux that points to the Windows executable:

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

(Make sure ~/.local/bin is in your $PATH).

2. Patch the Config: We need to tell the launcher to use Google's specific remote extension ID instead of Microsoft's. Open the file at %USERPROFILE%\AppData\Local\Programs\Antigravity\bin\antigravity in a text editor (like VS Code) and change the WSL_EXT_ID:

bash
# Old Line (Comment this out)
# WSL_EXT_ID="ms-vscode-remote.remote-wsl"

# New Line
WSL_EXT_ID="google.antigravity-remote-wsl"

3. Add the Helper Scripts: The installer is missing some script files that the remote extension expects. You can copy them from your existing VS Code installation.

• Source: %USERPROFILE%\.vscode\extensions\ms-vscode-remote.remote-wsl-<latest_version>\scripts\
• Destination: %USERPROFILE%\AppData\Local\Programs\Antigravity\resources\app\extensions\antigravity-remote-wsl\scripts\

(Note: You will likely need to create the scripts folder manually in the destination).

Now, running agy . inside WSL launches the editor in the correct context immediately.

---

🚀 Quick Setup: One-Command Automation (Recommended)

Don't want to do Steps 2-3 manually? I've created an automation script that handles all of the above configuration steps.

Run from your WSL terminal:

bash
curl -L [https://raw.githubusercontent.com/smaxiso/antigravity-wsl/master/setup-antigravity-wsl.sh](https://raw.githubusercontent.com/smaxiso/antigravity-wsl/master/setup-antigravity-wsl.sh) | bash

Or download and inspect first:

bash
wget [https://raw.githubusercontent.com/smaxiso/antigravity-wsl/master/setup-antigravity-wsl.sh](https://raw.githubusercontent.com/smaxiso/antigravity-wsl/master/setup-antigravity-wsl.sh)
chmod +x setup-antigravity-wsl.sh
./setup-antigravity-wsl.sh

What the script does:

• ✅ Auto-detects your Windows username
• ✅ Creates the agy symlink (Step 2, part 1)
• ✅ Patches Antigravity config (Step 2, part 2)
• ✅ Copies helper scripts from VS Code (Step 2, part 3)
• ✅ Enables mirrored networking (Step 3, covered below)
• ✅ Installs antigravity-repair tool automatically (See update below)

📦 View Source on GitHub | 🐛 Report Issues

💡 Note: The script is idempotent (safe to run multiple times) and creates backups before modifying files. After Antigravity updates, simply re-run it to restore the setup.

---

Step 3: The Browser Subagent (Mirrored Networking)

If you are building agents that need to browse the web, the agent might fail to connect to Chrome. This is because WSL usually runs on its own virtual network, so 127.0.0.1 in Linux isn't 127.0.0.1 in Windows.

The fix is to enable Mirrored Networking.

1. Go to your Windows user directory: C:\Users\<your_username>\.
2. Look for a file named .wslconfig. If it doesn't exist (it didn't for me), create it.
3. Add the following lines:

ini
[wsl2]
networkingMode=mirrored

4. Restart WSL: Open PowerShell and run wsl --shutdown.

After restarting, the Antigravity agent in WSL could see my Windows Chrome browser flawlessly.

For more details on why this works, check out the official Microsoft documentation on Mirrored Mode Networking.

Alternative Method: Port Forwarding (If Mirrored Mode Fails)

If you are on an older version of Windows or the mirrored network trick doesn't work, you can use Port Forwarding.

1. Windows Setup (PowerShell Admin)

powershell
New-NetFirewallRule -DisplayName "Chrome Remote Debug" -Direction Inbound -LocalPort 9222 -Protocol TCP -Action Allow

2. WSL Setup (~/.bashrc)

Install socat (sudo apt install socat) and add this to your .bashrc:

bash
# --- Antigravity / Chrome Bridge Setup ---
WIN_IP=$(ip route show | grep -i default | awk '{ print $3}')
if ! pgrep -f "socat TCP-LISTEN:9222" > /dev/null; then
    socat TCP-LISTEN:9222,fork,reuseaddr TCP:$WIN_IP:9222 &> /dev/null &
fi

---

🔁 Update (Feb 2026): Antigravity WSL Breakage After Updates

Even after following the guide above, you might suddenly encounter errors like remote-cli/antigravity: not found or "Remote Extension host terminated unexpectedly". This happens because Antigravity updates (or VS Code updates) often break the WSL bootstrap process.

The Root Cause: Antigravity dynamically creates commit-specific server directories inside WSL (e.g., ~/.antigravity-server/bin/1504c8cc...). Sometimes, it creates the bin folder as a symlink to a non-existent path instead of a real directory. Since you cannot create files inside a symlink, the server fails to start.

**The Fix: antigravity-repair** I wrote a robust script that detects the active Antigravity commit, fixes the broken bin directory structure, and links your existing VS Code server binaries so Antigravity can use them.

Note: If you used the Automation Script above, this tool is already installed! You can just run antigravity-repair.

For manual installation, save this as ~/.local/bin/antigravity-repair:

bash
#!/usr/bin/env bash
set -e

# Detect local VS Code commit
VS_COMMIT="$(ls -1 ~/.vscode-server/bin 2>/dev/null | head -n1)"
if [[ -z "$VS_COMMIT" ]]; then
    echo "❌ No VS Code server found. Run 'code .' first."
    exit 1
fi

AG_BIN_DIR="$HOME/.antigravity-server/bin"
# Find real directories
AG_DIRS=$(find "$AG_BIN_DIR" -maxdepth 1 -mindepth 1 -type d 2>/dev/null || true)

# FALLBACK: If no directories, check for failed tarballs (common on fresh installs)
if [[ -z "$AG_DIRS" ]]; then
    # Look for files like <COMMIT>-<TIMESTAMP>.tar.gz
    FAILED_TAR=$(ls -1 "$AG_BIN_DIR"/*.tar.gz 2>/dev/null | head -n1)
    
    if [[ -n "$FAILED_TAR" ]]; then
        FILENAME=$(basename "$FAILED_TAR")
        # Extract the first 40 chars (the commit hash)
        RECOVERED_COMMIT="${FILENAME:0:40}"
        
        echo "⚠️  Found failed download artifact: $FILENAME"
        echo "🔨 Force-creating directory for commit: $RECOVERED_COMMIT"
        
        mkdir -p "$AG_BIN_DIR/$RECOVERED_COMMIT"
        AG_DIRS="$AG_BIN_DIR/$RECOVERED_COMMIT"
        
        # Cleanup the bad file
        rm -f "$FAILED_TAR"
    fi
fi

if [[ -z "$AG_DIRS" ]]; then
  echo "❌ No Antigravity directories or artifacts found."
  echo "👉 Run 'agy .' once to generate them."
  exit 1
fi

echo "🔧 Repairing Antigravity WSL server..."
echo "   VS_COMMIT=$VS_COMMIT"

for AG_BASE in $AG_DIRS; do
  AG_COMMIT=$(basename "$AG_BASE")
  
  # Skip non-server dirs (safety check)
  if [[ ! -f "$AG_BASE/product.json" && ! -e "$AG_BASE/bin" && "$AG_BASE" != *"$RECOVERED_COMMIT"* ]]; then
      continue
  fi

  echo "   → Patching $AG_COMMIT"

  # 1. Fix symlink bug
  if [[ -L "$AG_BASE/bin" ]]; then
    rm "$AG_BASE/bin"
    mkdir -p "$AG_BASE/bin"
  fi

  # 2. Create structure
  mkdir -p "$AG_BASE/bin/remote-cli"

  # 3. Link binaries
  ln -sf \
    "$HOME/.vscode-server/bin/$VS_COMMIT/bin/remote-cli/code" \
    "$AG_BASE/bin/remote-cli/antigravity"
done

echo "✔ Antigravity WSL server repaired"

Make it executable: chmod +x ~/.local/bin/antigravity-repair.

How to use it: If agy ever breaks (especially after a fresh install or update):

1. wsl --shutdown (Required to clear the "terminated unexpectedly" crash loop).
2. antigravity-repair inside WSL.
3. agy .

---

📁 Workspace Performance Best Practice

Another important lesson learned: **Do not develop inside /mnt/c**.

If you keep your projects in C:\Users\Sumit\Workspace (/mnt/c/...), tools like Git, Python, and Node will be painfully slow because every file operation has to cross the NTFS-to-Linux bridge.

The Correct Layout:

1. Store code in Linux: ~/workspace (This uses the fast ext4 filesystem).
2. Access from Windows: Open File Explorer and go to \\wsl.localhost\Ubuntu\home\sumit\workspace.

This gives you native Linux speed for tools, but you can still edit files using Windows apps.

---

Troubleshooting: No Internet Connection in WSL

If you suddenly find that nothing in WSL can connect to the internet—Antigravity can't access models, git commands fail, curl times out—this is likely a DNS resolution issue.

The Problem: WSL auto-generates /etc/resolv.conf with a dynamic nameserver that can change every time you restart WSL. Sometimes this nameserver stops working, breaking all internet connectivity.

Quick Check:

bash
cat /etc/resolv.conf

You'll see something like:

nameserver xxx.xx.xx.xx

The Fix: Replace the dynamic nameserver with Google's public DNS (8.8.8.8):

bash
# Permanent fix (prevents WSL from regenerating the file)
sudo rm /etc/resolv.conf
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "[network]" > /etc/wsl.conf'
sudo bash -c 'echo "generateResolvConf = false" >> /etc/wsl.conf'
sudo chattr +i /etc/resolv.conf

---

Troubleshooting: "Download Error" for Extension

Even after fixing the networking, you might see the browser subagent crash with a generic "Download error" or "Something went wrong" message.

This happens because the agent is trying (and failing) to side-load the Chrome extension into the profile.

The Fix: Simply install the extension manually in your Chrome browser:

• Antigravity Browser Extension (Chrome Web Store)

Once installed, restart Antigravity, and the agent should pick it up immediately.

---

⚠️ Important Note: Updates May Break This Setup

Heads up: Antigravity updates can sometimes reset these configurations. If your agy command suddenly stops connecting to WSL or fails with a server error after an update, don't panic.

Just run the antigravity-repair script mentioned above. It is idempotent and safe to run repeatedly.

---

Final Thoughts

Antigravity + WSL is a powerful combo for building AI agents on Windows. With these fixes, you get the best of both worlds: Windows UI polish and Linux toolchain power.

Now that it's talking to WSL correctly, I can finally get back to building Gen AI tools without context-switching between environments.

Hit a different error? Feel free to reach out - I'll update this guide as Antigravity evolves.

Happy coding! 🚀

---

Huge thanks to Dazbo (Darren Lester) for the original deep-dive article that helped me figure this out.