Resolving WSL Friction with Google Antigravity: the Agy App (formerly Antigravity 2.0) / Agy IDE / Agy Extension Edition
Resolving Friction
Last year when the very cool Google Antigravity (Agy) was first launched, there were some areas of friction when working with the Windows Subsystem for Linux (WSL) environment. But they were generally all solvable. So I wrote a blog to consolidate the fixes.
The blog turned out to be very popular, with about 40,000 of you having read it in the last six months! This shows that WSL is not a niche environment. In fact, according to a recent Stack Overflow survey to over 65,000 poeple, approximately 17% of all developers use WSL as their primary OS for development, across both professional and personal use.
So, WSL definitely needs to be treated as a first-class citizen with any developer tooling.
Enter the New Agy 2.0 Ecosystem
In May 2026, Google dropped the new Antigravity suite. This was a major overhaul of Antigravity, and a split into these four products:
- Antigravity 2.0, which is now the dedicated agent-first “builder” environment on your desktop. Notably, it doesn’t itself include an IDE. Instead, we now interact only with the agent manager. This surface aims to usher in the era of “idea to product” using agents, without concerning ourselves over the code. Many builders who don’t come from a coding background will love this.
- Antigravity IDE, which gives us the more familiar VS Code-esque coding environment, supported by the Antigravity agent harness. Here we can do agent-assisted development, and we always see the code. Coders will feel at home here.
- Antigravity SDK, which gives you the harness and tools that power Antigravity, but exposed as a Python Agent SDK. By importing from
google.antigravitywe can programmatically leverage Antigravity’s capabilities. - Antigravity CLI, which is the next evolution of the the extremely awesome Gemini CLI. It’s still a terminal-first environment for interacting with Gemini models. But the new Antigravity CLI is built in Go, and you can tell; it feels much faster than Gemini CLI, both during startup and in general use. It leverages the same agent “harness” as Antigravity 2.0 and the IDE, and this allows for common settings and configuration across the Antigravity suite.
What Does This Mean for WSL?
Surprise: this introduces some new friction with WSL. But good news: once again, these friction areas are easily resolved!
Here I’ll list some of the problems I’ve encountered with Agy in WSL, and how to fix them.
I should add: the friction areas do not necessarily imply any bugs with Antigravity. It’s generally that a little additional config is sometimes required to get it to place nicely with WSL. In some cases, these will be opportunities for Agy to be improved to potentially detect and handle some of these configurations for us.
Problem 1: Shell Commands Don’t Run or Get Stuck
This one was causing me a lot of strife: when the agent was executing shell commands in my WSL environment, it would often:
- Start running the shell command.
- Show in the conversation window that it’s running.
- Move the command to a background thread.
- Never complete the command.
It’s easy to reproduce. In Agy IDE, whilst connected to WSL, I can issue a prompt like this:
“Try running some interactive shell commands”
And this is what happens:
If you click on the first blue dot you’ll see this:
We see the interactive command. But there’s no way to interact with it! The dropdown arrow at the bottom right simply hides this line. All we can do is terminate the background command by pressing the X.
The Cause
For me, the cause was that my bash shell prompt includes funky characters that are polluting the prompt to the agent. In my case, this is almost certainly because I’m using oh-my-bash shell customisation. When I say shell prompt, I mean the thing that looks like this…
Or this:
Furthermore, my oh-my-bash is actually configured to pick a random prompt from a list. This explains another thing that was confusing me: sometimes, my Agy agent was able to run these shell commands. But most of the time it couldn’t.
By the way, this is not a niche shell extension! Loads of people use oh-my-bash for shell enhancement and optimisation.
The Fix
There are two things you need to do.
First, you need to make sure your workspace is in your trustedWorkspaces list in your ~/.gemini/settings.json file. For me, it turned out that my actual /home/darren/.gemini was missing from this file, so the Antigravity security engine was simply preventing any background execution from here, but not telling me so.
{
"trustedWorkspaces": [
"/home/darren/.gemini",
"/home/darren",
"/home/darren/some/repo"
]
}Next, modify your ~/.bashrc so that it doesn’t load any funky shell prompts or other interactive prompt intelligence (like oh-my-bash), if the shell is running inside Antigravity. My solution looks like this:
### TOP OF .bashrc
# Enable the subsequent settings only in interactive sessions
case $- in
*i*) ;;
*) return;;
esac
# Rest of your .bashrc
_is_antigravity_session() {
# Check for known Antigravity / IDE environment variables and non-interactive pipes
[[ -n "$ANTIGRAVITY_AGENT" || -n "$ANTIGRAVITY_IDE" || -n "$VSCODE_IPC_HOOK_CLI" || -n "$VSCODE_CWD" || -n "$GIT_ASKPASS" || "$PAGER" == "cat" || "$TERM" == "dumb" || ! -t 1 ]] && return 0
# Inspect parent process command line in /proc for IDE / PTY daemon binaries
if [[ -r "/proc/$PPID/cmdline" ]]; then
grep -q -a -E "(antigravity|pty-host|code|electron|node)" "/proc/$PPID/cmdline" 2>/dev/null && return 0
fi
return 1
}
# Only load Oh-My-Bash in interactive user terminals outside of Antigravity sessions
if ! _is_antigravity_session; then
source "$OSH"/oh-my-bash.sh
fiOkay, let’s restart Agy and see if it has worked…
It created a script, executed it, injected interactive responses to the script, and completed!
Woop!
Problem 2: Browser Agent is Broken
The browser agent is the thing that allows you to launch a browser from your chat, and then navigate. It can also take screenshots or even record a video of the session.
Get Dazbo (Darren Lester)’s stories in your inbox
Join Medium for free to get updates from this writer.
But… It doesn’t work in WSL out-of-the-box.
I tested it with a prompt like this: “Use the browser agent to navigate dazbo.co.uk”
Agy fails, and gives me a response like this.
The Fix
This is super-easy to fix!
We just need to enable mirroring mode in our WSL config!
In Windows, we just need to edit our .wslconfig file (or create it, if it doesn’t yet exist):
notepad %userprofile%\.wslconfigJust make sure the file has this block:
[wsl2]
networkingMode=mirroredThen shutdown and restart WSL, from your Windows Command Prompt or Powershell:
wsl --shutdown
# Wait a few seconds
wslNow we restart Agy, and let’s see what happens…
That was easy!
How Does It Work?
By default, WSL2 uses a Network Address Translation (NAT) architecture, which essentially places your Linux environment behind a virtual router on a separate network isolated from Windows. When Agy triggers its browser agent, it spins up a browser instance on Windows and attempts to talk to it via the Chrome DevTools Protocol (CDP). In NAT mode, that connection slams straight into a networking wall because your Linux-based Agy harness can’t seamlessly see or route traffic to Windows localhost ports (like Chrome’s default debug port 9222).
Switching your networking mode to mirrored solves this. Instead of treating Linux as a detached VM on a virtual router, Windows literally mirrors its exact network interfaces directly into WSL2. This completely removes the network isolation barrier. Now, localhost means the exact same thing to both Windows and Linux, allowing Agy in WSL to hook straight into Chrome's remote debugging interface on Windows with zero port-forwarding friction, and no firewall headaches.
Update: The ‘DevToolsActivePort’ Hurdle (and the Agent Skill That Fixes It for You!)
Even with networkingMode=mirrored enabled and Chrome’s remote debugging switched on at chrome://inspect/#remote-debugging, you might still hit one final hurdle when using Antigravity’s native browser subagent (or the Chrome DevTools MCP with --autoConnect).
Why? Because Chrome is running on Windows, so it writes its session discovery file (DevToolsActivePort — which contains the active port and the session-specific WebSocket UUID path) to your Windows AppData directory:
/mnt/c/Users/<WINDOWS_USER>/AppData/Local/Google/Chrome/User Data/DevToolsActivePortMeanwhile, the Antigravity browser subagent runs inside a Linux sandbox in WSL2 and looks for that file at:
~/.config/google-chrome/DevToolsActivePortAnd here’s the kicker: you cannot simply symlink the file across /mnt/c/...! Because the browser subagent executes inside a containerised sandbox that doesn’t mount /mnt/c, a symlink fails with ELOOP: too many symbolic links encountered. It must be copied as a regular file inside your WSL home directory whenever Chrome starts a new session.
Rather than fixing this by hand, you can install my fix-wsl-browser-agent skill from my dazbo-agent-skills repository and let Antigravity configure everything for you automatically:
npx skills add derailed-dash/dazbo-agent-skills --skill fix-wsl-browser-agent -gOnce installed, simply ask your agent to run the fix-wsl-browser-agent skill. It will:
- Check whether Google has already patched native
/mnt/cdiscovery in your current version of Antigravity (so it won’t apply redundant workarounds if an upstream update has already fixed it). - Locate your Windows Chrome
DevToolsActivePortfile and copy it into~/.config/google-chrome/DevToolsActivePortas a regular file. - Optionally add a lightweight, fast hook to the top of your
~/.bashrcso the file stays automatically synchronised whenever Chrome restarts!
That’s It
Hope this has saved you some bother.
Until next time!
You Know What To Do!
- Please share this with anyone who you think will be interested. It might help them, and it really helps me!
- Please give me 50 claps! (Just hold down the clap button.)
- Feel free to leave a comment 💬.
- Follow and subscribe, so you don’t miss my content. Go to my Profile Page, and click on these icons:
