Store WSL vs. Inbox WSL: Why the Servicing Channel Changes Available Features

Two machines that both report running “Windows 11” can have meaningfully different WSL behavior, supporting different features, because WSL itself ships through two different servicing channels — and which one a given machine is actually using changes what’s available, how quickly it updates, and how you should reproduce a reported bug.

WSL as a Windows optional component, originally

WSL originally shipped primarily as a Windows optional component, meaning its updates were tied to Windows’s own servicing and release cadence — a new WSL feature or fix generally had to wait for the next Windows feature update or cumulative update to reach users, the same cadence governing every other built-in Windows component. This is straightforward but slow for a piece of software whose Linux ecosystem moves considerably faster than annual or semi-annual Windows feature update cycles.

The shift to Microsoft Store delivery

Microsoft moved WSL to Microsoft Store-based delivery specifically to decouple its update cadence from the broader Windows release cycle — the Store-delivered package lets Microsoft ship WSL kernel updates, feature additions, and fixes on its own independent schedule, considerably faster than waiting for the next Windows feature update. The Store version became generally available (dropping its “Preview” label) in November 2022, and critically, it was made available on Windows 10 as well as Windows 11 — addressing a specific, longstanding community request from Windows 10 users who wanted access to newer WSL features without needing to be on the latest Windows 11 build.

What became available through Store delivery that wasn’t before

The Store-delivered channel is how systemd support and Linux GUI application support (WSLg) reached Windows 10 users, not just Windows 11 — features that would otherwise have been tied to whichever Windows version’s inbox WSL component happened to include them. This is a direct, concrete illustration of why the delivery channel matters beyond an abstract “which is newer” question: a Windows 10 machine on the Store channel can have access to features a Windows 11 machine still running only the older inbox WSL component doesn’t.

Checking which channel and version you’re actually running

wsl --version
wsl --status

wsl --version reports the specific installed WSL package version and its component versions (kernel, WSLg, and others), which is the reliable way to confirm what’s actually installed rather than inferring it from the Windows version alone. wsl --update updates the Store-delivered package independently of any Windows update.

Why enterprise environments sometimes standardize on one specific channel

Organizations managing WSL through Intune or Group Policy can specifically disable the inbox version (AllowInboxWSL) and standardize on the Store-delivered channel, which gives IT a single, more centrally manageable update path rather than two independent version histories to track and support. This is a reasonable, common choice for organizations that want predictable, centrally-controlled WSL versioning rather than whatever mix of inbox and Store versions individual users might otherwise end up running.

Why “same Windows build” doesn’t mean “same WSL behavior”

This is the single most practically important consequence of the two-channel history: a bug report, a missing feature, or unexpected behavior can’t be reliably attributed to “Windows 11” or “Windows 10” alone, because the actual WSL version and delivery channel is the more specific, relevant variable. Two people on the identical Windows build can have different WSL versions if one is on the Store channel and current, and the other is on an inbox version that hasn’t been updated in a while, or has policy preventing Store WSL from being used at all.

What this means for reproducing a reported bug

When trying to reproduce a colleague’s or a user’s reported WSL problem, record and compare both the Windows build and the output of wsl --version before assuming “same Windows version, should behave the same.” A bug specific to a particular WSL package version, independent of the underlying Windows build, is a common enough occurrence that skipping this check leads to wasted time trying to reproduce something that was never going to reproduce identically given a version mismatch neither side had actually confirmed.

Migrating from inbox to Store WSL deliberately

For a machine still running the older inbox component, moving to the Store-delivered version isn’t automatic — it’s worth doing deliberately rather than assuming it happens as a side effect of an ordinary Windows update. Running wsl --update on a system without the Store package present, or explicitly installing WSL from the Microsoft Store, brings a machine onto the newer channel. Existing distributions and their data aren’t lost in this transition, since the distributions themselves are separate from the WSL platform package delivering the underlying engine, but confirming this with a test distribution before relying on it for anything important remains sensible practice given how much the specific behavior can depend on the exact starting state.

The direct fix when a needed feature is simply missing

If documentation describes a feature that isn’t present on your system, the first, most likely explanation is a version or channel gap rather than a configuration mistake — checking wsl --version against the documented minimum version requirement, and running wsl --update if you’re behind and permitted to use the Store channel, resolves the large majority of “the documented feature doesn’t seem to exist” reports.

Keep this distinction in mind the next time a “just update Windows” suggestion doesn’t actually resolve a WSL-specific problem — the more precise fix is usually updating WSL itself through its own channel, which is a separate action from a general Windows update regardless of how closely the two are otherwise associated in most users’ minds. Related: WSL Reaches 1.0 as a Standalone Microsoft Store App · Running a Custom WSL 2 Kernel Without Losing the Supported Rollback Path

Sources: