WSL Linux Containers Now GA: Key Features and What to Verify

Microsoft moved WSL Linux containers out of preview and into general availability on September 29, 2026, giving Windows users a built-in command-line tool and programmable API for building, running, and deploying Linux containers on Windows through the Windows Subsystem for Linux. Microsoft says users can access it by running wsl --update or installing the latest WSL release from GitHub. Its announcement does not list supported Windows editions or Server versions, so availability should be verified on the specific system, according to the Windows Developer Blog.

The release caps roughly three months of public testing that began on June 29, when Microsoft opened WSL containers to public preview following its introduction at Build 2026, with a stated goal of reaching general availability by fall 2026, a target the company hit, according to the Windows Command Line blog.

What WSL Linux containers change for Windows developers

The CLI ships as wslc.exe, with a built-in container.exe alias. Microsoft describes the CLI as having a familiar format and capabilities, language it used when the feature entered public preview on June 29, framed as a way to preserve existing muscle memory for developers who already work with container tools, according to the Windows Command Line blog. Developers starting a fresh local container workflow face the fewest unknowns here, since there's no existing setup to migrate.

Compatibility with Docker Desktop and Podman remains unconfirmed. Microsoft says its goal is for wsl compose up to work with existing compose.yaml files unchanged, but that's a stated aim rather than a demonstrated result, and the cited announcements don't specify image-format or Kubernetes compatibility with either tool, according to the Windows Developer Blog.

VS Code integration is documented across both posts, though the details shifted slightly. The June 29 preview instructed developers to open the Dev Containers settings and change the "Docker Path" entry to wslc, according to the Windows Command Line blog. The GA announcement now describes wslc as a supported default driver for creating and managing dev containers, and a separate VS Code container-management extension also added wslc support with the release, according to the Windows Developer Blog. Check which setting applies to the installed VS Code version rather than assume.

How WSLC containers differ from standard WSL

Session architecture changed along with the branding. Standard WSL has client processes call into wslservice.exe, a privileged Windows service capable of creating virtual machines to run Linux workloads. WSLC breaks from that model: instead of wslservice.exe retaining ownership of the virtual machine, it spins up a child process, wslcsession.exe, which runs on behalf of the calling user and performs session operations like mounting directories and binding network ports, according to the Windows Command Line blog. Microsoft says this gives WSLC stronger isolation between sessions and runs them with fewer privileges than the main WSL service, which is the company's own architectural description rather than an independently audited one.

File access speed got attention in the GA announcement, which says Windows file access from Linux containers is now up to 2x faster, according to the Windows Developer Blog. The underlying mechanism, a file system called virtiofs, was named as the new default when the feature entered public preview on June 29; the GA post repeats the performance figure without naming that component again, according to the Windows Command Line blog.

Memory handling changed too. Microsoft says WSL containers gradually return unused memory from the Linux virtual machine to the Windows host instead of holding onto it, a behavior enabled for containers first, with plans to bring it to standard WSL by default later, according to the Windows Command Line blog.

Networking runs through a mode Microsoft calls Consommé, which routes container traffic through a process acting on behalf of the user owning the WSLC session. Microsoft says this makes outbound traffic look like it came from a regular Windows process, improving compatibility with VPNs and firewalls, according to the Windows Command Line blog. The June 29 preview post labeled this mode "experimental." The GA announcement says Consommé is now enabled for container workflows but doesn't clarify whether that experimental designation changed in the months since, according to the Windows Developer Blog.

What to check before you rely on it

After updating, check whether wslc.exe or its container.exe alias actually shows up on the path. From there, several GA-specific additions are worth testing directly rather than assumed:

• --mount support in wslc create and wslc run, plus a configurable storage path for container data
• wslc system info, which reports the state of the container environment, and container health checks, a separate supported capability
• wslc events for streaming real-time container activity

Microsoft's documentation makes networking a relevant area to verify, especially on VPN-restricted or firewalled corporate networks. The company documents wslc network connect, wslc network disconnect, and wslc network create as the commands for attaching and configuring container networks, but the cited posts don't demonstrate that DNS resolution, port mapping, and host loopback all work cleanly in locked-down environments, according to the Windows Developer Blog.

The cited posts don't provide a migration guide for moving an existing Docker Desktop or Podman project into WSLC. Running a small, disposable test container first is one way to see how it behaves before anything production-dependent points at it.

Developers embedding containers directly into native Windows apps have a separate option: a NuGet package with C, C++, and C# support that integrates with MSBuild and CMake build pipelines. Microsoft product manager Craig Loewen said this was intended for production use when the feature was still in preview, according to the Windows Command Line blog, a vendor statement rather than formal support documentation.

Enterprise controls through Intune and Defender for Endpoint

Microsoft says Intune administrators can now enable or disable WSL containers organization-wide and restrict image pulls to an approved registry allow list, according to the Windows Developer Blog. Microsoft Defender for Endpoint's existing WSL plugin has also been updated to recognize container-specific events, giving security teams the same visibility into containers that they already had into WSL distros, according to the Windows Developer Blog.

These controls build on mechanisms Microsoft introduced during the June 29 preview, when organizations could already toggle container access and set registry restrictions through Group Policy and an ADMX template, with native Intune dashboard support promised "within the next few weeks," according to the Windows Command Line blog. Admins should confirm their Intune console now shows these settings natively rather than assume it from the GA post alone, since Microsoft's GA materials don't state whether that promised dashboard rollout finished.

The cited announcements don't address which Intune or Defender for Endpoint tiers include container-specific policies, so administrators should check their current licensing agreement before scheduling a rollout.

What to do now

Microsoft has released WSL Linux containers as a built-in Windows feature rather than a separate download. Running wsl --update and checking whether wslc.exe appears on the path is how to confirm the update applied.

Organizations should confirm their Intune console displays the new container controls and check licensing coverage before planning a wider rollout. Microsoft's GA and preview posts don't establish production suitability for every workflow, supported Windows editions and Server versions, or compatibility with Docker Desktop and Podman, so those are points to verify directly rather than assume.