A concise, opinionated summary of key Windows developer platform shifts announced at Microsoft Build 2026, focused on:
- WSL Containers (
wslc.exe) - Microsoft Execution Containers (MXC)
- The emerging "Homebrew-like" experience on Windows
🌐 Bilingual site (EN / FR): https://devopsabcs-engineering.github.io/openclaw-win/ · English · Français
At Microsoft Build 2026 (June 2, 2026), Scott Hanselman used OpenClaw — the open-source reimplementation of the classic Captain Claw game — as the headline demo for running untrusted, native Windows software inside a hardened sandbox.
The story across the announcements:
- WSLC brought native Linux container workflows to Windows without Docker Desktop.
- MXC added an OS-level, policy-controlled execution runtime for untrusted code and agents.
- The OpenClaw demo tied it together: ship a real, GPU-accelerated game binary, run it under enterprise security lockdown, and prove the host stays protected.
The pitch: "If you can run a 90s platformer this safely, you can run anything."
wslc.exe= CLI to build, run, and manage Linux containers directly from Windows via WSL- Part of WSL Containers, a new native container runtime baked into Windows
| Stage | Status |
|---|---|
| Announcement | June 2, 2026 |
| Preview | ✅ Expected end of June 2026 |
| GA | ❌ Not announced |
-
Delivered via:
wsl --update
-
No Docker Desktop required
-
Native OS integration:
- Windows filesystem
- Networking stack
- GPU acceleration (demoed)
-
Designed for:
- Dev containers
- AI workloads
- Local pipelines
TL;DR: WSLC = Docker-like experience, but native to Windows via WSL.
⚠️ Often confused as "MSX" — the correct term is MXC.
- Microsoft Execution Containers
- OS-level execution runtime designed for:
- AI agents
- Secure workload isolation
- Integrated with:
- Microsoft Defender
- Entra ID
- Intune / enterprise controls
| Stage | Status |
|---|---|
| Announcement | June 2, 2026 |
| Availability | ✅ Early preview only |
| GA | ❌ No timeline |
- Not a traditional container runtime replacement (yet)
- Focus areas:
- Agent execution
- Secure policy enforcement
- OS-level isolation
- Long-term direction:
- Runtime layer for autonomous systems
TL;DR: MXC = "agent runtime for Windows" (think Kubernetes concepts, but OS-embedded).
In the Build 2026 keynote, Scott Hanselman demonstrated OpenClaw running inside an MXC sandbox to show how Windows can execute untrusted native binaries with full security lockdown — no host trust required.
- Real, native Windows binary (not a toy or web app)
- Needs GPU + audio + input + filesystem access — the hard parts of sandboxing
- Open source, so the audience can reproduce it locally
MXC runs OpenClaw with a deny-by-default policy and only the capabilities the game needs:
| Capability | Host access | How MXC mediates |
|---|---|---|
| Filesystem | ❌ No host paths | Virtualized game directory only |
| GPU | ✅ Rendering only | Brokered GPU surface (no driver escape) |
| Audio / input | ✅ Allow-listed devices | Mediated by MXC device broker |
| Network | ❌ Blocked by default | Explicit policy opt-in |
| Identity | 🔒 Scoped token | Entra ID, no ambient host credentials |
| Threat scanning | ✅ Always on | Microsoft Defender inspects the runtime |
# Launch OpenClaw inside an MXC sandbox with a hardened profile
mxc run --policy lockdown.json --gpu broker --net none openclaw- The game renders full-speed via the brokered GPU surface
- It cannot read host files, reach the network, or touch host credentials
- If the binary misbehaves, the blast radius is the sandbox — the host is untouched
TL;DR: OpenClaw on MXC = native Windows software running with container-grade isolation and enterprise policy — the model Microsoft wants for every untrusted workload, from retro games to AI agents.
Build 2026 paired the new runtimes (WSLC + MXC) with a refreshed model lineup — the "brains" that run inside MXC sandboxes and power agentic workflows on Windows.
| Model | Class | Where it runs | Best for |
|---|---|---|---|
| Phi-5 | Small language model | On-device (NPU/CPU) | Local agents, offline tasks, low latency |
| Phi-5-vision | Small multimodal | On-device (NPU) | Screen/UI understanding, doc parsing |
| MAI-2 | Frontier general model | Cloud (Foundry) | Reasoning, planning, complex orchestration |
| MAI-Code | Code-specialized | Cloud + hybrid | Code gen, refactoring, repo-scale tasks |
| GPT-5.1 | Partner frontier (OpenAI) | Cloud (Azure AI Foundry) | Highest-capability reasoning |
⚠️ Names follow Microsoft's 2026 conventions: Phi = open small models, MAI = Microsoft AI in-house frontier models, with OpenAI frontier models still served through Azure AI Foundry.
- On-device first: Phi-5 ships tuned for the NPU in Copilot+ PCs, so agents can run locally — no round-trip, no data leaving the device.
- Sandbox-native: Models run inside MXC, inheriting the same deny-by-default policy, Entra-scoped identity, and Defender scanning shown in the OpenClaw demo.
- Hybrid routing: Lightweight steps stay local (Phi-5); heavy reasoning escalates to MAI-2 or GPT-5.1 in Foundry — the same agent code, different execution tier.
Agent (in MXC sandbox)
├─ local intent + UI parsing → Phi-5 / Phi-5-vision (on-device NPU)
├─ planning + reasoning → MAI-2 (Foundry, cloud)
└─ code tasks → MAI-Code / GPT-5.1 (Foundry, cloud)
TL;DR: Build 2026's model story = Phi-5 on-device for speed and privacy, MAI-2 / MAI-Code / GPT-5.1 in the cloud for heavy reasoning — all running under the same MXC security lockdown.
Microsoft is repositioning Windows 11 as a unified developer platform.
- Windows applications
- Linux workloads (via WSL)
- Containerized workloads (via WSLC)
- AI agents (via MXC)
- Linux becomes invisible — WSL moves from "tool" → "platform layer"
- Containers become native — no external runtime required
- AI agents become first-class citizens
Windows is becoming:
- A Linux-compatible OS
- A container host
- An agent runtime
- ❌ Homebrew is NOT coming natively (not announced)
- ✅ An equivalent experience is emerging
| Capability | Status |
|---|---|
| Coreutils (Linux CLI) | ✅ Available (June 2026) |
| WinGet | ✅ Mature |
| Homebrew | ❌ WSL-only |
- No official Homebrew port
- No timeline
- No roadmap
Microsoft is not porting Homebrew — they are eliminating the need for it.
brew install node
docker run my-appwinget install node
wslc build .
wslc run my-app| macOS / Linux | Windows equivalent |
|---|---|
| Homebrew (CLI tools) | Coreutils (native) |
| Homebrew packages | WinGet + WSL |
| Docker | WSLC |
| Linux runtime | WSL |
One-liner: WSLC + Coreutils + WinGet = Microsoft's alternative to Homebrew + Docker + bash.
- Porting Homebrew to Windows
- Maintaining compatibility shims
- Bring Linux semantics into Windows itself
- Make developer tooling:
- Native
- Consistent
- Enterprise-ready
Implication: Instead of adapting Windows to Linux tools, Microsoft is adapting Windows to behave like Linux.
- Remove Docker Desktop dependency (partially)
- Native container workflows
- Simplified local dev environments
- Better parity with Linux/macOS teams
- Future runtime for:
- AI agents
- Secure automation
- Policy-controlled workloads
- Potential evolution:
- OS-level orchestration
- Secure task execution framework
- Windows apps
- WSL for Linux tools
- Docker for containers
- Brew/Mac for a better experience
- Windows + Coreutils
- WSL (background Linux layer)
- WSLC (containers)
- MXC (agents)
Result: One OS, one developer surface, no environment switching.
| Question | Answer |
|---|---|
| When is WSLC coming? | ✅ End of June 2026 (preview) |
| When is MXC available? | ✅ Early preview only |
| When is Homebrew coming to Windows? | ❌ Not announced |
| Equivalent experience available? | ✅ Coreutils + WinGet + WSL + WSLC |
| Strategic direction | ✅ Native Linux-like Windows platform |
Windows is evolving into:
- ✅ A first-class developer workstation
- ✅ A Linux-compatible platform
- ✅ A container-native OS
- ✅ A future agent execution environment
Final insight: The real shift is not "Windows catching up to macOS/Linux" — it's Windows becoming a superset runtime where Linux, containers, and agents all run natively.
If you're building internal platforms or advising clients:
-
Compare:
- WSLC vs Docker Desktop
- DevContainers vs WSL Containers
- AKS vs future MXC runtime model
-
Test:
wsl --update wslc --help
-
Evaluate:
- GPU container workloads locally
- Agent-based execution pipelines