"Antigravity ran beautifully on my Mac, but the moment I installed it on the work-issued Windows laptop with WSL2, it crawls. Saving a file doesn't even register — the AI keeps answering with the old contents." If that sounds familiar, you're almost certainly stuck behind a WSL2 filesystem boundary, not an Antigravity bug. I lost half an hour myself the first time I migrated to a Windows box, blaming the editor before I realized what was going on.
WSL2 performance issues come from a design tradeoff: anything that crosses the Windows–Linux boundary on disk goes through the 9P protocol and gets dramatically slower. Once you understand the cause, a few config tweaks can multiply your perceived speed. Let's walk through the diagnosis and the lasting fixes in order, and make sure you don't have to revisit this kind of pain again.
Step one: check where your project actually lives
The most common WSL2 mistake is leaving your project in C:\Users\xxx\projects. From inside WSL2 that path appears as /mnt/c/Users/xxx/projects, but every read and write is shuttled across the 9P bridge. It's not unusual to see 10x or worse slowdowns on the most basic operations like ls, git status, or any tool that walks a directory tree.
# Confirm where your project lives
pwd
# /mnt/c/Users/xxx/projects/myapp ← this is the bottleneckAntigravity indexes your codebase in the background, and the AI agent re-reads file diffs on every save. If that path is slow, every interaction inherits the lag. The most effective fix is to relocate your project under WSL2's native ext4 filesystem, where Linux tools can talk to disk directly.
# Move the project under your Linux home
mkdir -p ~/projects
mv /mnt/c/Users/xxx/projects/myapp ~/projects/myapp
cd ~/projects/myappThat single change often takes git status from minutes to under a second, and Antigravity's indexer finishes in a fraction of the time. It's the fastest "before vs. after" benchmark you'll see all week. If you absolutely must keep the project on the Windows side because of OneDrive sync or company policy, accept the cost: Antigravity will never be as fast there as it is on the Linux filesystem, and you'll want to compensate by tightening every other setting in this article.
When file changes don't propagate (inotify limits)
Save a file, but the AI keeps answering as though it never changed? Formatter not firing on save? HMR refusing to reload after edits? You're almost certainly out of inotify watch slots. WSL2's defaults are tuned for lightweight workloads, not for an editor that wants to monitor every file across a large codebase plus its node_modules.
# Inspect the current limit
cat /proc/sys/fs/inotify/max_user_watches
# Default values like 8192 fall over almost immediately on modern stacksA typical Next.js or Vite project can put tens of thousands of files in node_modules, blowing past the default in seconds. Make the fix permanent through /etc/sysctl.conf so it survives reboots.
# Append to /etc/sysctl.conf (sudo required)
echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.conf
# Apply immediately
sudo sysctl -pAfter applying, run wsl --shutdown from PowerShell and reopen the terminal for the cleanest restart. The watch count will be reset and Antigravity should start picking up file change events again. If you're seeing a wider variety of ENOSPC-related symptoms — including unrelated commands failing with "no space left on device" even when disk usage looks fine — the Antigravity file watcher ENOSPC fix guide covers adjacent failure modes worth checking too.
Revisit how much memory and CPU WSL2 is allowed
Resource allocation for WSL2 is controlled from the Windows side via .wslconfig. The default — 50% of system RAM up to 8 GB — is usually too tight for an AI editor that spawns Node.js processes and language servers freely. Four to six gigabytes runs out fast once you open a couple of project windows and load the AI agent into context.
# C:\Users\<your-user>\.wslconfig (on Windows)
[wsl2]
memory=12GB
processors=8
swap=4GB
localhostForwarding=trueA safe rule of thumb is 75% of your physical memory. That gives the agent breathing room even on big codebases and multi-file refactor flows. Allocating at least half of your CPU cores also makes a visible difference during the initial index, when Antigravity is parsing every source file in the workspace. Always restart WSL2 with wsl --shutdown after changing this file — the new limits don't apply until the lightweight VM has been restarted.
If raising the ceiling doesn't help, the ceiling probably wasn't the bottleneck. The Antigravity slow performance troubleshooting guide and the high CPU and memory usage fix help you keep narrowing things down without going in circles.
Don't overlook DNS and network paths
WSL2 routes traffic through a Hyper-V virtual network by default, which makes it sensitive to DNS misconfiguration. If Gemini API calls feel sluggish or time out intermittently, suspect DNS first — it's usually faster to verify than the application-layer culprits people tend to reach for.
# Verify DNS resolution
nslookup generativelanguage.googleapis.com
# If lookups are slow or fail
sudo rm /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.confWSL2 regenerates /etc/resolv.conf on every boot, so to make this permanent you also need to disable that behavior in /etc/wsl.conf. Otherwise your fix will look great today and silently revert tomorrow morning.
# /etc/wsl.conf
[network]
generateResolvConf = falseIf you're behind a corporate network, DNS is rarely the only thing involved — proxies and certificate inspection often play a part too, and they tend to interact with WSL2 in surprising ways. Pair this with the corporate proxy and firewall troubleshooting guide to round out the picture before you assume Antigravity itself is at fault.
When everything else looks right, check WSL itself
If you've worked through the steps above and the editor still drags, your WSL kernel may simply be out of date. Microsoft has shipped real performance improvements over the last year, especially around 9P throughput and inotify behavior, and older installs miss out on all of them. From an elevated PowerShell window:
# Run from PowerShell as administrator
wsl --update
wsl --version
# Aim for 2.x or newerI'd also encourage you to rethink the "Windows-side Antigravity opening a WSL2 folder" pattern. It's convenient, but every keystroke and every save crosses the file boundary, and the cost adds up over a workday. In my own testing, running Antigravity inside WSL2 (via WSLg for the GUI) or connecting through a remote workspace approach was noticeably more stable. As a team standard, it also tends to give every member roughly the same speed, which is worth a lot when you're triaging "works on my machine" reports between teammates running different setups.
A quick verification routine after each change
Whenever you change one of the settings above, it pays to verify the fix instead of trusting that "it should be better now." I keep a small checklist that takes under two minutes to run after every adjustment.
# 1. Confirm filesystem location
pwd | grep -q "^/mnt/c" && echo "still on Windows mount" || echo "on Linux fs"
# 2. Confirm inotify limits
echo "watches: $(cat /proc/sys/fs/inotify/max_user_watches)"
echo "instances: $(cat /proc/sys/fs/inotify/max_user_instances)"
# 3. Time a representative operation
time git status
# 4. Verify DNS latency
time nslookup generativelanguage.googleapis.com >/dev/nullIf any of those numbers look off, fix that one specific thing and re-run the checklist. I find this loop works better than tweaking three settings at once and trying to reason about which of them helped. When something breaks again three weeks later, you want to know exactly which knob to turn first, and a habit of measuring before and after gives you that confidence cheaply.
Wrap-up — the one move worth trying today
WSL2 + Antigravity slowness almost always boils down to two things: where your project lives and your inotify limit. So start there. Run pwd on your active project right now, and if you see /mnt/c/..., plan to move it under ~/projects before you sign off today. That single decision tends to be the one that changes how the next morning of coding feels — and it costs you nothing but a mv command.
It also stops you from accidentally regressing later: a teammate adds a new project under /mnt/c, copies your dotfiles over, and wonders why their machine is suddenly slow. Pointing them at pwd is faster than re-debugging the same problem from scratch.