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

---

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 | bash

Or download and inspect first:

bash
wget 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)

📦 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

---

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:

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver xxx.xx.xx.xx

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

bash
# Test if this fixes it (temporary)
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'

Try accessing the internet now (e.g., ping google.com). If it works, make it permanent:

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

💡 What this does: The chattr +i command makes the file immutable, so even if WSL tries to regenerate it, the change won't stick.

Credit: Solution adapted from this Stack Overflow discussion.

---

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 the browser subagent fails after an update, don't panic—just re-run Steps 2 and 3.

The patched WSL_EXT_ID and helper scripts (Step 2) are the most likely to be overwritten during updates. Bookmark this guide for quick reference!

---

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.