Antigravity CLI on Windows: Native or WSL, and the Gotchas

Native or WSL: decide by where your code lives

The rule is short and it beats every other consideration: run the agent on the same side of the filesystem boundary as your repository.

• Code in C:\Users\you\projects → run Antigravity natively on Windows.
• Code in ~/projects inside WSL → run Antigravity inside WSL.

Crossing that boundary is where the pain lives. A native Windows agent reaching into WSL files, or a WSL agent reaching into /mnt/c, works but is slow enough to change how the agent behaves: file reads that should be instant take long enough that an agent scanning a repository spends most of its time on I/O. On a large codebase the difference is not subtle.

Beyond speed, crossing the boundary also breaks things quietly. File watching does not propagate reliably across it, permissions do not map cleanly, and line endings become a recurring irritation.

Where Antigravity keeps its files on Windows

Antigravity reuses the Gemini home directory, so on Windows its data lives under %USERPROFILE%\.gemini, which is normally C:\Users\yourname\.gemini. Conversations sit in the antigravity-cli folder inside it.

Two consequences worth knowing. First, the directory name has a leading dot, which Windows does not treat as hidden the way Unix does, so it will simply be visible in your user folder. Second, and more important: native Windows and WSL have completely separate homes. A conversation started in WSL is not visible to a native Windows session and vice versa, because they are looking at two different .gemini directories on two different filesystems.

The rest of the storage behaviour, including the flat conversation layout and the way the project is recorded, is the same on every platform and is covered in the conversation history guide.

The two path traps

UNC paths. If you start the agent from a directory reached over a network share or through the WSL bridge, the working directory is a UNC path (\\wsl$\Ubuntu\home\you\project or \\server\share) rather than a drive letter. A lot of tooling handles UNC paths badly, and the failure is rarely a clear error: commands fail with odd messages about the current directory, or silently run somewhere other than where you expect.

The fix is to give the path a drive letter. Map the share with net use, or simply work from a real local directory. If you are reaching into WSL through \\wsl$, that is the configuration the previous section told you to avoid anyway.

Spaces and long paths. Windows still has a 260-character path limit unless long path support is enabled, and deep node_modules trees under a project already nested in C:\Users\yourname\Documents\... get there faster than you would think. An agent that fails to write a file for no apparent reason in a deeply nested project is usually hitting this.

Why the quota indicator can insist Antigravity is not running

This one is worth its own section because it wastes real debugging time. Antigravity exposes its state through a local language server, and anything that wants to read your quota has to find that server first.

On macOS and Linux that discovery is normally done with Unix process utilities. On Windows those utilities do not exist, so any tool that assumes them reports nothing rather than failing loudly: your quota display says "Antigravity is not running" while the agent is visibly working in front of you. The correct approach on Windows is to enumerate listening ports instead, which is what netstat does.

There is a second failure that looks identical and is not platform-specific: a logged-out session is externally indistinguishable from no session at all. The server behaves the same way whether your credentials expired or Antigravity was never started.

Windows on ARM

Antigravity itself is fine on Windows on ARM, and a Go binary is exactly the kind of thing that ports cleanly. What is not always fine is the surrounding ecosystem.

The recurring problem is native modules: anything in your project that compiles against a specific architecture, SQLite bindings being the classic example, needs an ARM64 build. A prebuilt binary downloaded for x64 will fail to load with an error that mentions the module rather than the architecture, which sends people looking in the wrong place.

If you hit that, the fix is to rebuild the native modules for your actual architecture rather than to reinstall the agent. The agent is not the thing that is broken.

Running several Antigravity sessions on Windows

Each agy session is an independent process, so nothing stops you running several. What stops you in practice is Windows terminal management: several PowerShell windows with no indication of which is which, no per-session status, and no notification when one finishes.

This is genuinely worse than on macOS or Linux, where tmux is a reasonable answer that most Windows developers do not have set up. It is the main reason parallel agent workflows feel harder on Windows than they are.

CodeAgentSwarm runs on Windows natively and gives each Antigravity session its own labelled terminal in one window, with live status, desktop notifications when a session finishes, and searchable history across all of them. It handles the Windows-specific quota discovery described above, so the indicator reflects what is actually happening rather than what a Unix-shaped check would report.

Combined with a git worktree per agent, which matters as much on Windows as anywhere else, that is what makes a swarm of Antigravity agents practical on the platform.