The Windows Subsystem for Linux keeps picking up momentum. GitHub Copilot‘s desktop app just added experimental WSL support, and while that marinates, Google quietly confirmed it is working on WSL for Antigravity, its agentic development platform, along with better native support for Windows, which is rare from a company with a spotty history of supporting Windows.

WSL lets you run a Linux distribution directly inside Windows, without dual-booting or using a full virtual machine. So much of modern software, such as build pipelines, cloud infrastructure, and AI frameworks like PyTorch and llama.cpp, is written and tested on Linux first.

In case you didn’t realise it already, both Antigravity and GitHub Copilot are in the same category of AI development tools, and while WSL is now experimentally supported in the GitHub Copilot app, Google is working on WSL for Antigravity. 

WSL2 runs a Linux kernel inside a lightweight, Microsoft-managed VM, so tools like Docker, bash, and Linux-native package managers work as developers expect, all while staying on Windows. Microsoft has been working on improving WSL as a serious platform, and this week’s news from Google is the clearest sign yet that the bet paid off.

Google is finally supporting WSL and native Windows, and that’s rare

It’s an open secret that Google has rarely been generous toward Windows. Most of its developer tools either treat Windows as an afterthought or bring in RAM-heavy browser-based apps instead of native ones. But things seem to be changing, at least for Antigravity.

Rody Davis, a senior developer relations engineer at Google’s Antigravity division and DeepMind, posted on X:

“We are working on WSL and better native windows support. Taking some time to really get it right and work how we want. For the other features will pass that along to the team!”

Windows Latest spotted this while checking out a thread Davis started, listing recent Antigravity updates like custom sub-agents, remote control, IDE extensions, and enterprise API key support, then asking users what gaps remained in their workflows.

One user asked for the ability to change the agent environment to WSL inside the Antigravity 2.0 app. Davis confirmed WSL and native Windows support are both being worked on.

The WSL part is easy to picture. Antigravity’s agents could run file operations, shell commands, and builds inside Linux instead of translating everything through Windows first.

The “native windows support” part is surprising, because Davis did not say what it means. He did not name WinUI, but it is the only candidate that fits. Microsoft confirmed at Build 2026 that WinUI is the permanent native app framework for Windows, dropping the “3” from WinUI 3 to show there is no future framework. Microsoft has also started open sourcing WinUI on GitHub, with external contributions and public issue tracking already live.

Ironically, most AI-based cross-platform dev tools default to Electron because it ships everywhere faster. However, we all know how they eat RAM like it’s cheap. A native WinUI app from Google would be one of the only Google products on Windows not running on Chromium. Funnily enough, I won’t be believing my optimism until it ships, but Davis’s reply doesn’t seem to be something Google says lightly, although he mentions that it will take a lot more time.

GitHub Copilot’s app now runs agent sessions inside WSL

But to developers, this second half of the story is likely to be the more interesting one. Pierce Boggan, who is the PM lead on GitHub Copilot and previously at Xamarin, posted that “Windows Subsystem for Linux (WSL) is now experimentally supported in the GitHub Copilot app!”, with a video demo attached.

The setup is under Settings, Experimental, where a new “WSL hosts (Preview)” toggle lets the app “connect to and create sessions inside WSL.” Once enabled, a separate Environments page lists every WSL 2 distribution installed through wsl.exe, in this case an Ubuntu distro marked default and running. Connecting it shows a live WebSocket address, and from there, you register a project by pointing to its absolute Linux path, something like /home/pboggan/coloring-book, which the app validates before adding.

Starting a new session against that project shows a “WSL: Ubuntu” badge at the top, confirming the session runs inside the Linux distro. In the demo, Boggan typed a prompt asking the agent to add a footer reading “Made in Park City, UT”. The agent loaded a frontend-design skill, searched the Next.js project’s page.tsx, layout.tsx, and globals.css files, ran git status –short && git branch directly inside WSL to check the current state, found an existing styled footer, and edited it with a single-line change.

It then re-checked the file to confirm the new text was correct and ran git diff –check to validate the change before showing a “Create PR” button. The whole loop with reasoning, file edits, and git validation ran inside WSL, powered by a model listed as GPT-5.6 Sol.

GitHub’s internal feedback thread for the Copilot app had flagged “Windows + WSL support is limited” as a known complaint. Replies confirm more is coming. Remote SSH is expected as soon as next week, since the WSL groundwork doubles as the base architecture for connecting to any generic remote host.

Another user asked for adding or cloning a project directly from the main menu instead of digging through settings, which Boggan confirmed is next. Microsoft engineer Michael Tierney noted that WSL support doesn’t change how Copilot generates code, only where the agent’s filesystem and shell execution happen.

WSL is now one of the most active parts of Windows. The latest stable build, version 2.7.3, added directory-level VirtioFS mounting, IPv6 for virtio networking, and DNS tunneling for VirtioProxy mode, on top of a kernel bump to 6.18. We already covered Microsoft’s broader 2026 plan to upgrade WSL with faster file access, better networking, and easier setup. Separately, Microsoft shipped WSL Containers, which lets you build and run Linux containers straight from Windows without Docker Desktop. We also went hands-on with WSL Containers to see how it holds up in practice.

Windows is quietly becoming a serious developer platform again

Despite the near-constant negative press Windows 11 gets over ads, bugs, and forced AI features, the developer side of the OS has had a strong stretch. At Build 2026, Microsoft rolled out Coreutils for Windows, bringing over 75 familiar Linux command-line utilities like ls, grep, and mv natively to Windows without needing WSL at all, built on the open-source uutils project in Rust. WinUI’s commitment as the permanent native app framework, plus its move toward full open source, shows Microsoft treating native Windows development as a priority again.

We recently covered how Ubuntu is growing faster on Windows 11 than on native Linux PCs, according to Canonical’s numbers, which speaks volumes about where developers are choosing to run Linux workloads from.

Windows 11 still has plenty to answer for. But WSL Containers replacing Docker Desktop, Copilot running agents inside Linux distros, WinUI going open source, and now Google building for WSL and Windows, all show Microsoft doing everything to circle back to its roots.

The post In a rare move, Google is bringing native Windows 11 and WSL support to its new AI tools appeared first on Windows Latest