But the claim that Google is only now bringing Windows support to Antigravity needs qualification. Google launched Antigravity as a cross-platform product in November 2025, explicitly listing Windows alongside macOS and Linux, and its May 2026 announcement for the standalone Antigravity 2.0 desktop app again listed Windows as a supported platform. What Rody Davis, a Google developer-relations engineer associated with Antigravity and DeepMind, appears to have confirmed in a reply highlighted by Windows Latest is better Windows support, plus WSL—not Antigravity’s first arrival on Windows.
That distinction is more than semantic for developers deciding whether to standardize on the tool. Windows availability means the application launches on a PC. WSL support would determine whether an autonomous agent can work where many modern projects actually build and test: a Linux userland running locally on that Windows PC.
Antigravity’s missing environment is WSL
Google’s own Antigravity documentation presents the product as an agentic development platform capable of coordinating work through an editor, terminal, and browser. Antigravity 2.0 moved that concept into a standalone desktop application designed to run multiple local agents across workspaces and projects.
The unresolved detail is how the current Windows version handles those local workspaces. A Windows-native desktop client can still be a poor fit for repositories that assume Bash, GNU tooling, Linux file permissions, Linux package managers, container tools, or scripts written and validated on Ubuntu. Those are common requirements in cloud application development, data engineering, infrastructure-as-code, and AI projects.
According to Windows Latest, a user asked Davis for the ability to switch Antigravity 2.0’s agent environment to WSL. Davis replied that Google was working on WSL and improved native Windows support, adding that the work was taking time so the implementation would behave as intended. Google has not published a product roadmap, release date, supported Windows versions, supported Linux distributions, or an explanation of whether WSL will be available in Antigravity 2.0, the Antigravity IDE, or both.
Those omissions matter. There is a large difference between opening a project stored in a WSL distribution and offering a complete WSL host model: selectable distributions, environment-aware terminals, Linux-path project registration, extension compatibility, process supervision, credential handling, and reliable handoff between Windows UI elements and Linux commands. Google has confirmed none of those implementation details publicly.
“Better native Windows support” is still undefined
The second half of Davis’s response has generated more speculation than evidence. Windows Latest suggested a native Windows framework such as WinUI could be a candidate. There is no public confirmation from Google that Antigravity will use WinUI, Windows App SDK, Win32, .NET, or any other Windows-specific application framework.
Readers should treat that part as conjecture, not a product announcement.
Google’s official launch materials call Antigravity cross-platform, but do not explain the Windows client’s rendering stack or whether it is fundamentally different from the macOS and Linux editions. A native application can refer to several things: a Windows installer and desktop integration, a Windows-specific UI toolkit, a native host process around web content, or simply better behavior with Windows paths, keyboard shortcuts, authentication, notifications, and file pickers. Davis’s wording does not settle which of those Google means.
For Windows administrators, the lack of detail means there is no deployment change to plan around yet. There is no announced MSI or MSIX package, no enterprise management guidance, no documented policy surface, and no support statement for Windows 10, Windows 11, ARM devices, or managed WSL configurations. Organizations using Antigravity should not assume that a future WSL option will inherit existing endpoint controls or behave like Visual Studio Code’s mature Remote - WSL workflow.
The most defensible reading is narrower: Google knows that its Windows experience and its local execution model have gaps, and it is working on them. That is useful acknowledgment, but it is not evidence of a coming WinUI rewrite.
GitHub Copilot has put a usable comparison on the table
The immediate comparison comes from GitHub Copilot’s desktop app. GitHub’s official changelog says the Copilot app became generally available for Windows, macOS, and Linux in June 2026, positioning it as a desktop workspace for agent-driven development with repositories, branches, terminals, diffs, and pull-request workflows.
Windows Latest reports that GitHub has now added experimental WSL host support to that app. In a demonstration shared by GitHub Copilot product lead Pierce Boggan, the app’s experimental settings included a “WSL hosts” preview option, an environments screen recognized an installed WSL 2 distribution, and a project could be registered with its Linux path. The agent then performed file and Git operations from within that WSL environment.
GitHub has not yet published a corresponding changelog entry or full support document for the WSL-host preview, so the feature’s availability and limitations should be treated as preview-stage information rather than a broad production commitment. Still, its design illustrates the capability Google needs to deliver: the desktop app is merely the control surface, while the agent’s shell and filesystem work occurs inside the developer’s selected Linux environment.
That approach avoids an especially awkward failure mode for coding agents on Windows. If an agent runs on the Windows filesystem while the repository’s dependencies, shell scripts, and container configuration expect Linux behavior, every task becomes an exercise in translation. When the agent runs in WSL, its commands and file access happen under the same Linux assumptions that the project’s CI pipeline or deployment target may use.
Microsoft engineer Michael Tierney made the boundary clear in a response cited by Windows Latest: WSL support does not change the code Copilot generates; it changes where filesystem operations and shell execution happen. That is the correct way to frame the feature. The model is not made smarter by WSL. Its work becomes more reproducible for projects already designed around Linux tooling.
Why this is a meaningful signal for Windows development
WSL has become a strategic compatibility layer for Windows developers precisely because Linux remains the baseline environment for a substantial share of server-side development. Instead of dual-booting, maintaining a heavyweight virtual machine, or working against a remote Linux box for every command-line task, developers can run a Linux distribution alongside Windows applications.
For agentic tools, that arrangement is unusually valuable. These products do more than offer a code completion suggestion. They inspect repositories, modify files, execute commands, install dependencies, run tests, use browsers, and interact with version control. The closer the agent’s execution context is to the project’s expected runtime, the fewer invisible incompatibilities it must work around.
Google’s Antigravity and GitHub Copilot are therefore converging on the same practical requirement, even if only one has shown a preview implementation so far. Both need to support a Windows developer who uses Windows as the desktop operating system and Linux as the build and command-line environment.
The signal is not that Windows suddenly became Antigravity’s target platform; it already was one. The signal is that Windows-only local execution is no longer sufficient for serious agent-assisted development. Google’s eventual WSL implementation will need to prove that it can handle real repositories and real Linux workflows, not merely open a Windows client beside an Ubuntu terminal.
