WSL has had a busy year. Microsoft open-sourced it under MIT in May 2025, and since then the pace of visible change has picked up noticeably. The stable line is sitting at 2.7.12, but the pre-release line has jumped to 2.9.x and it carries the most interesting new work: a first-party Linux container runtime called WSL Containers (wslc.exe), a faster file-sharing transport called virtiofs, a renamed networking mode called Consomme, and a kernel bump from 6.6 to 6.18 LTS.
While reviewing what these changes mean for WSL UI, I went through the release notes, the Build 2026 material, the docs and a fair number of GitHub issues. This post is the write-up. It covers what each feature is, how to try it today, what's still rough, and which of it touches your existing distros versus staying safely fenced off in the container preview.
The short version: almost nothing changes for existing distros unless you opt in. The container runtime lives in its own VM, virtiofs is off by default, and the kernel bump has already landed on stable without anyone much noticing. But the direction is clear, and a couple of the opt-ins are worth understanding before they become defaults.
Where the release lines are
WSL now ships two lines in parallel, and it's worth knowing which one you're on before reading further:
| Line | Latest | What it carries |
|---|---|---|
Stable (wsl --update) | 2.7.12 (18 Aug 2026) | Kernel 6.18, VHD ownership fixes, security backports |
Pre-release (wsl --update --pre-release) | 2.9.9 (25 Aug 2026) | Everything in stable plus WSL Containers public preview |
Check yours with:
wsl --versionThere's no 2.8.x on the releases page. The Build 2026 demo repo asks for "WSL 2.8+" but in practice the container feature arrived in 2.9.3 on 29 June 2026, and that's the floor the official docs give.
WSL Containers (wslc)
This is the headline. WSL Containers adds two things: a CLI called wslc.exe for building and running OCI containers, and an API (shipped as a NuGet package) that lets Windows applications run Linux containers as part of their own logic. Microsoft's pitch is an "enterprise-ready way to create, run, and manage Linux containers on Windows, without requiring additional third-party tooling." Read that as: a first-party answer to Docker Desktop's licensing conversation.
Getting it
wsl --update --pre-release
wslc --versionAfter the update, wslc.exe is on your PATH. There's also a container.exe alias that just invokes it. Inside a WSL distro it's reachable as wslc.exe via the normal Windows interop path.
It looks like Docker
The CLI was deliberately designed to match the Docker muscle memory you already have. From the official docs:
# Run a container
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"
# List available images
wslc image ls
# Run a web server
wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080
# List and stop
wslc container ps
wslc container stop webGPU passthrough works from day one via the Container Device Interface (CDI):
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime python -c "import torch; print(torch.cuda.is_available())"The 2.9.x releases have been steadily closing the gap with Docker's flag surface: --stop-timeout, healthchecks, container cp, --ip, --link, --network-alias, UDP and IPv6 port publishing, and volume list --format json matching Docker's key names all landed between 2.9.4 and 2.9.9.
It is not a WSL distro
This is the bit that matters most for anyone running tooling against WSL. Containers do not go through wsl.exe. They run inside a separate utility VM managed by a session, and a session is not a distribution:
Some consequences of that design:
wsl --list --verbosewill never show your containers. They're not registered distributions.wsl --shutdowndoes not stop the container VM. You needwslc system session terminatefor that.- Session storage is separate from distro VHDs. The default session gets 32 GB of storage, and the path became configurable in 2.9.4.
- Volumes are VHD-backed rather than directories on a shared filesystem.
- The container VM uses virtiofs for Windows file access and Consomme for networking by default, whereas your distros still use Plan 9 and NAT unless you change them. More on both below.
The upside of the separation is that the container platform can move fast without destabilising distros. The downside is that any management tool, WSL UI included, has to learn a second set of primitives if it wants to show containers alongside distributions.
The SDK
The API is the part I find more interesting long-term. The Microsoft.WSL.Containers NuGet package ships C# and C++/WinRT projections (plus a flat C surface), and integrates with MSBuild and CMake so a Windows app can pull, build and run a Linux container as part of its normal build and runtime:
var session = new Session(new SessionSettings("MyApp", @"C:\WslcData")
{
CpuCount = 4,
MemoryMB = 4096
});
session.Start();
await session.PullImageAsync(new PullImageOptions("docker.io/library/alpine:latest"));
var container = session.CreateContainer(new ContainerSettings("alpine:latest")
{
Name = "hello-container",
InitProcess = new ProcessSettings
{
CmdLine = new[] { "/bin/echo", "Hello from WSL Container!" },
OutputMode = ProcessOutputMode.Event
}
});
container.InitProcess.OutputReceived += data => Console.Write(Encoding.UTF8.GetString(data));
container.Start();
The Build 2026 demos packaged a Linux renderer as a Windows executable, streamed a containerised Linux desktop into a WinUI 3 app, and ran PyTorch with GPU access from a Windows front end. The obvious near-term use cases are reusing Linux-only code without a rewrite, running cloud workloads locally, and sandboxing a process's access to the host. Microsoft has said the API will be supported for production use, which is something the Docker Desktop model never really offered to Windows app developers.
Enterprise plumbing
Because this is Microsoft, the management story shipped alongside the runtime rather than after it:
- Group Policy / Intune: ADMX policies to allow or block distros versus containers, and to allowlist container registries. Available via GPO now; Intune dashboard support was promised "within the next few weeks" of the June announcement.
- Microsoft Defender for Endpoint: the existing WSL plugin was extended to see container events, so coverage is the same whether you're in a distro or a container.
- VS Code Dev Containers: supported from extension release 0.462.0-pre-release. Set the Docker Path setting to
wslcand it works the same way the Podman trick does.
What doesn't work yet
It's a preview, and the community has found the edges fast. As of early September 2026:
- No Docker Compose equivalent. Microsoft calls this a top feature ask and says it's under investigation.
- Repos living inside a WSL distro's filesystem can't be bind-mounted into a container. The endjin hands-on called this "the single biggest blocker", and Microsoft's response on the issue was that the scenario isn't supported yet. If your workflow is "clone into
~in Ubuntu, then run containers against it",wslcisn't for you today. - No
--platformon build, which trips up the devcontainers CLI. - No
--privilegedor--deviceinwslc run --help, so Docker-in-Docker and USB passthrough are out. - Tooling that hard-codes Docker (.NET Aspire,
az acr login) doesn't know about it.
GA is targeted for autumn 2026. Given the cadence of 2.9.x releases, a lot of the above will move before then, but the WSL-filesystem bind mount limitation is the one to watch if you care about parity with Docker Desktop.
virtiofs: faster Windows file access, still opt-in
If you've ever run npm install against a project living on /mnt/c, you know WSL's Windows file access is slow. The reason is Plan 9: WSL serialises every file operation over a 9P protocol channel to a server on the Windows side. It's correct, it's been stable for years, and it's not quick.
virtiofs replaces that with a shared-memory VirtIO transport. Microsoft's headline claim for the container runtime is "2x faster" Windows file access. The endjin write-up was more measured, calling it "a little quicker than the old approach" and still far slower than files living inside the Linux filesystem. Both can be true depending on the workload.
For containers, virtiofs is the default. For distros, it's opt-in. Add this to %USERPROFILE%\.wslconfig:
[wsl2]
virtiofs=trueThen wsl --shutdown and relaunch. Verify from inside a distro:
findmnt -T /mnt/c -o TARGET,SOURCE,FSTYPE,OPTIONSYou want FSTYPE to read virtiofs rather than 9p.
A few things to know before flipping it:
- It's not in the official
.wslconfigdocs yet. The key is real and has been in the source since the experimental work started, but the Learn page doesn't list it. Treat it as experimental regardless of which section it lives in. - The performance patch needs a recent kernel. The per-device SWIOTLB pool optimisation that gives virtiofs its speed requires kernel 6.18.26.3-1 or later. On an older kernel WSL logs a warning that "the running kernel is missing a patch that significantly improves virtio device performance" and falls back to the slower path. Keep at least 1 GB assigned to the VM; the pool needs 64 MB of headroom.
- There are real bugs in 2.7.7 and 2.7.8. Issue #40773 reports that a failure to share any one fixed drive silently skips automounting all of them, so
/mnt/cand/mnt/djust don't exist, with nothing indmesg. Issue #40790 is the same failure with a visible warning and a fallback to Plan 9. Issue #40719 covers files created by a non-root user on a Windows bind mount showing up as root-owned and unwritable. The workaround in every case is the same: removevirtiofs=true,wsl --shutdown, relaunch. - Mounted disks don't appear as
/dev/sd*devices. Anything that discovers mounts by scanning block devices, which includes WSL UI's current mounted-disk view, won't see virtiofs shares. We've documented this in the WSL UI troubleshooting guide and are tracking the upstream fixes before changing the discovery logic.
Microsoft has said it is "working towards enabling by default in the future." When that happens it'll be the biggest change to day-to-day WSL behaviour in years, so it's worth understanding now while it's still a switch you control.
Consomme: VirtioProxy gets a name and a job
If you've read the .wslconfig docs recently you'll have seen networkingMode = virtioproxy listed alongside nat and mirrored. In 2.9.3 Microsoft renamed VirtioProxy to Consomme, and made it the default networking mode for WSL Containers.
Consomme relays Linux traffic through Windows rather than giving the VM its own virtual NIC on a NAT network. The point is that containers inherit Windows networking wholesale: VPN routes, proxy configuration, firewall policy and whatever enterprise integrations the IT department has bolted on. If you've ever fought WSL and a corporate VPN, you can see why Microsoft wants this to be the default for the enterprise-facing container story.
For distros, nothing changes. NAT is still the default, mirrored is still there, and since WSL 2.3.25 NAT has quietly fallen back to VirtioProxy when it fails to start. The rename just formalises a mode that's been load-bearing in the background for a while. Whether Consomme becomes the distro default is not something Microsoft has committed to.
Kernel: 6.6 to 6.18 LTS
This one already happened, on stable, and most people didn't notice. WSL 2.7.8 (June 2026) moved the kernel from the 6.6 LTS line to 6.18.33.1-1, and 2.7.9 bumped it to 6.18.33.2-2 to fix a boot regression on older AMD hosts under KVM.
For most workloads the jump is transparent. Where it matters:
- Newer filesystem, cgroup and eBPF features that userland tooling (recent systemd, Podman, containerd) has started to assume.
- It's the prerequisite for the virtiofs performance work above.
- If you're running a custom kernel via
kernel=in.wslconfig, you're on your own timeline as always, and you'll need 6.18.26.3-1 or newer to get the virtiofs optimisation.
The bits that haven't changed
Three things I checked specifically because they'd have broken WSL UI, and all three are the same as before:
- Windows 10 is still supported. Build 19041 and later, including for WSL Containers. There's no new minimum OS.
wsl.exestill emits UTF-16LE by default. SettingWSL_UTF8=1in the environment switches it to UTF-8, and has since WSL 0.64.0. If you parsewsl --listoutput from scripts and see null bytes between every character, that's why.- There's still no
--jsonoutput. The request (microsoft/WSL#6235) has been open for years. The registry underHKCU\Software\Microsoft\Windows\CurrentVersion\Lxssis still the only structured source of truth for installed distributions.
That last point is the one I'd most like to see move. With wslc growing a proper --format json surface, the asymmetry with wsl.exe is getting harder to justify.
Should you try any of this today?
WSL Containers: yes, if you're curious or if Docker Desktop licensing is a live question in your organisation. The CLI is genuinely Docker-shaped and the GPU story works. Don't expect to replace Docker Desktop for a workflow that keeps source inside a WSL distro until the bind-mount limitation is fixed.
virtiofs on distros: only if you're on the latest pre-release and comfortable diagnosing a missing /mnt/c. The performance win is real but modest, and the automount bugs are still open. If you do try it, verify with findmnt before assuming it took.
Kernel 6.18: you already have it if you're on stable 2.7.8 or later. Nothing to do.
For WSL UI, the immediate work is making sure nothing we do assumes Plan 9 mounts or that wsl --shutdown stops everything. The longer-term question is whether a WSL management tool should show wslc sessions and containers alongside distributions. Given that they share a kernel, a settings file and increasingly a networking stack, I suspect the answer is yes. Let me know what you'd want to see.
Useful links: