Resolving Friction
Last year when the very cool Google Antigravity (Agy) was first launched, there were some teething issues when working with the Windows Subsystem for Linux (WSL) environment. These caused some friction, but they could all be solved. So I wrote a blog to consolidate the fixes. This blog turned out to be very popular, with about 40,000 of you having read it in the last six months!
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.
No Way To Execute or Approve Interactive Commands
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 waiting for approval, but never actually ask for it.
- Move the command to a background thread.
- Never complete the command. Or alternatively, complete the command and not notice it has done so.
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:
Here’s the interesting thing: it says it’s waiting for approval , but there’s actually no prompt from Agy and no way to provide it. 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.
I found a LOT of posts about this on the Internet. But this one is the only one that worked for me. (My own flavour of the fix is mostly built on that thread.)
The Cause
It appears 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.
The Fix
Modify your ~/.bashrc so that it doesn’t load any funky shell prompts or other interactive prompt intelligence. Add the “Antigravity Agent fix” block in your ~/.bashrc, like this:
### TOP OF .bashrc
# Enable the subsequent settings only in interactive sessions
case $- in
*i*) ;;
*) return;;
esac
# Antigravity Agent fix - clean the terminal
if [[-n "$ANTIGRAVITY_AGENT"]]; then
# Force the shell to behave as a simple pipe
export TERM=dumb
export DEBIAN_FRONTEND=noninteractive
# Disable aliases that might wait for terminal polling
unalias -a
# Clean prompt
export PS1='$ '
unset PROMPT_COMMAND
# exit early, without running the rest of .bashrc, e.g. bypassing oh-my-bash
return
fi
# The REST of your .bashrc
# E.g.
export OSH='/home/dazbo/.oh-my-bash'
Okay, 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!
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.
But… It doesn’t work in WSL out-of-the-box, of course.
I test 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%\.wslconfig
Just make sure the file has this block:
[wsl2]
networkingMode=mirrored
Then shutdown and restart WSL, from your Windows Command Prompt or Powershell:
wsl --shutdown
# Wait a few seconds
wsl
Now we restart Agy, and let’s see what happens…
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.
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 interact or leave a comment 💬.
