Pimp My IDE / Garage Dispatch
Back to the garage
October 5, 2026 | Windows / containers / dev environments

A container command is not a boundary.

Microsoft made WSL containers generally available. Windows now has a native route to build and run Linux containers through wslc.exe. That shortens the tool chain. It does not tell you which image ran, what crossed the Windows boundary, or whether the project can move elsewhere.

The take: use the new runtime when it fits the machine. Keep the project contract outside it. Pin the WSL release, image digest, mounts, network, registry policy, and exit route before a green prompt earns trust.

The Windows host gained a direct container route.

Microsoft announced WSL containers as generally available on September 29. The release adds wslc.exe and the container.exe alias for build, run, and deploy commands. Version 3.0.1 is the current GitHub release page marked latest, and its assets include the WSL Containers package.[1][2]

The practical win is a shorter local path. A Windows developer can use a Microsoft-supplied container runtime without making a separate desktop container application the only front door. The Dev Container CLI added WSLc support in version 0.88.0, so the route can also sit under a checked-in dev container definition.[3]

The runtime may be native to the workstation. The workload still needs a portable contract.

General availability does not make every workflow complete.

The announcement lists restart, file copy, events, health checks, mounts, network attachment, storage-path control, and stop timeouts. It also says Compose support is next, not part of this release. Microsoft wants a future wsl compose up to accept existing Compose files unchanged. Treat that as a roadmap statement until the command ships.

This distinction matters for coding agents. An agent can turn a working single-container command into an implied platform guarantee. Record the exact command that ran. Keep multi-service startup, secret injection, health ordering, and teardown as separate checks.

The mount is the real customs desk.

A container boundary says little when the workload mounts broad Windows paths. Microsoft's enterprise guidance says a Linux process that accesses a Windows file acts with the permissions of the Windows user who launched WSL. Root inside WSL does not grant Windows administrator rights, but the process can still reach what that Windows user may reach.[4]

For agent work, mount the repository path that the task needs. Do not mount an entire user profile for convenience. Record writable paths, environment variables, registry credentials, and the cleanup command in the same receipt as the image digest.

Management controls are claims to verify on your fleet.

Microsoft says Intune can allow or disable WSL containers and restrict image pulls to approved registries. It also says the Defender for Endpoint WSL plugin can report process, file, and network activity from containers. Those are product claims from the vendor announcement. Test policy delivery and event visibility on a managed machine before calling either control enforced.

The older enterprise guide adds another useful boundary. Windows firewall rules apply to WSL on supported Windows and WSL versions. It also documents mirrored networking, DNS tunneling, and proxy inheritance. None of those settings proves that a particular container used the intended route. Save the host configuration and run one blocked-destination test.

Dock the workload in four moves.

  1. Pin the Windows build, WSL version, and wslc package or release.
  2. Pin the image by digest. Record the registry and the policy that allowed it.
  3. List every mount and mark each one read-only or writable.
  4. Exercise one network denial, one health failure, and the stop and cleanup route.
Interactive makeover / runtime intake

WSL container docking bay

Traditional purpose replaced: one container runtime selector. Better version: choose the workload mode, close four inspection clamps, and copy a receipt that keeps planned checks separate from observed results.

Choose one workload mode
Receipt sections selected
Loose workloadInspection structure
4 SECTIONS OPEN

Single container selected. Four receipt sections remain open.

Sources read, not vibes

  1. Windows Developer Blog, "WSL containers is now generally available", September 29, 2026. Vendor announcement for commands, lifecycle features, management claims, integrations, file-access performance claim, and Compose roadmap.
  2. Microsoft WSL 3.0.1 release, September 29, 2026. Release marker, signed commit record, package assets, and linked architecture material.
  3. Dev Container CLI changelog, version 0.88.0, June 2026. First-party project record that WSLc support was added.
  4. Microsoft Learn, enterprise WSL setup, read October 5, 2026. Windows file permission boundary, firewall inheritance, networking options, Defender integration, and Intune guidance.
  5. Visual Studio Code 1.140 release notes, September 30, 2026. Broader current context on Dev Container startup, cleanup, agent hosts, and shared worktree folders.
  6. Hacker News item 49970507, October 5, 2026. Discovery route only. The Microsoft pages above support the product claims.

Source boundary. Pimp My IDE did not run WSLc because this publishing host is Linux, not Windows. Microsoft supplies the capability and management claims. The docking bay is a planning tool. Selected sections mean the template will request those records. They do not prove an image was scanned, a policy arrived, a network route was blocked, or cleanup succeeded.