# Microsoft eXecution Container (MXC) Microsoft eXecution Container (MXC) is an open-source ([[MIT License]]) sandboxed code execution system from Microsoft for running untrusted code (model outputs, plugins, tools) safely on Windows, Linux, and macOS. Instead of shipping one isolation technology, it puts multiple containment backends, from OS-native process sandboxes to full VMs, behind a unified JSON configuration schema and SDKs for Rust, .NET and Node. It is the engine behind [[GitHub Copilot Sandboxing|local sandboxing in GitHub Copilot CLI]]. ## Architecture - **Policy-driven**: JSON configs (versioned schemas) define execution parameters and security policy across three layers: filesystem (read-only/read-write path whitelists), network (allow/block outbound, proxy support), and UI (clipboard, display, GUI access) - **Lifecycle**: one-shot execution or a stateful provision → start → exec → stop → deprovision flow - **Implementation**: Rust native binaries and shared library crates, exposed through three SDKs since the first stable release (October 2026): Rust (`mxc-sdk`), .NET (`Microsoft.Mxc.Sdk`) and Node (`@microsoft/mxc-sdk`) ## Per-OS backends | OS | Default backend | Alternatives | |----|-----------------|--------------| | Windows | ProcessContainer (Windows 11 24H2+, AppContainer-based) | [[Windows Sandbox]], WSLC, MicroVM (NanVix), Hyperlight, IsolationSession | | Linux | Bubblewrap (namespaces + seccomp) | LXC, MicroVM, Hyperlight | | macOS | Seatbelt (`sandbox-exec` profiles) | | ## Stable release (October 2026) MXC shipped its first stable SDK on 2026-10-07, and a patch release followed on 2026-10-17. The day before, the team removed the early-preview warning from the README (the one quoted under Caveats). - There are three SDKs now instead of one: [[Rust]] (`mxc-sdk` on crates.io), .NET (`Microsoft.Mxc.Sdk` on NuGet) and Node (`@microsoft/mxc-sdk`). They share one operation model behind explicit V1 entry points, and Microsoft commits to semver for the 1.x line - You pick how a workload runs: to completion with captured output, with live stdin/stdout/stderr pipes, or with a PTY when the backend supports it - The SDK builds into your app and runs in process. Standalone executors (`wxc-exec.exe` on Windows, `lxc-exec` on Linux, `mxc-exec-mac` on macOS) accept the same JSON requests, for testing or when you can't embed the SDK - Audit mode (`--audit`) records what a trusted tool actually touches and produces a ProcessContainer policy from it. It switches the sandbox off for that run, so the README says never to use it on untrusted code - Telemetry is optional and off by default. It only flows when the run opts in, the Windows user consents and admin policy allows it. Builds from source aren't wired to Microsoft at all ## The VM backends Two experimental backends add hardware isolation on top of the process sandboxes, using [[microVM]]s: - Nanvix MicroVM runs guest code in a lightweight VM through the Windows Hypervisor Platform or KVM. The docs claim about 100 ms from spawn to guest code and about 100 MB of resident memory. The fast warm start relies on a snapshot that only exists on Windows; on Linux, every run cold-boots the VM - Hyperlight boots a Unikraft unikernel inside a Hyperlight micro-VM, restored from a warm snapshot on each run, with a choice of guest runtimes (Python and Node among them) Neither of them is [[Firecracker]] or [[gVisor]], the hardened runtimes [[OpenSandbox]] offers. On Linux, MXC can also use [[Linux Containers (LXC)|LXC]], and on Windows it can use [[WSL Container|WSLC]]. ## Where it fits MXC is a library, and everything runs on your own machine: no account, no hosted service. Your app declares the container type, the policy and the command; MXC maps that onto whatever sandbox the OS offers (Bubblewrap on Linux, Seatbelt on macOS, ProcessContainer on Windows). An HN commenter (bri3d) described it as "a container security policy orchestration layer", which matches my reading of the README. I like the idea for local coding agents and [[AI Agent Harness|agent harnesses]]. You write one policy, and getting each OS's sandbox right becomes Microsoft's job. The downside is what [[Simon Willison]] called, in the thread, the universal challenge of an abstraction layer over different technologies: you only get what each backend can enforce, and today macOS enforces the least. ## Reception on Hacker News The repo hit the Hacker News front page on 2026-10-09 (196 points, 85 comments). - dannyw said you could see it as a frontend for bubblewrap, Seatbelt and ProcessContainer, and argued that's the value: setting those up consistently is hard, and rolling your own is a bad idea. He liked the learning mode, the [[MIT License]] and the clear telemetry disclosure. gandreani added that audit and debug modes replace the rounds of `strace` it usually takes to get a new harness running under bubblewrap - Simon Willison (simonw) pointed out the missing piece for him: fine-grained networking on macOS. The Seatbelt backend rejects allow/deny rules by hostname and by IP, CIDR, port or protocol; the MXC docs say Seatbelt has no such primitive and suggest putting hostname lists on a proxy. He noted that Anthropic's sandbox-runtime, built on the same macOS primitives, does support domain allowlists. Others mentioned smolvm and microsandbox as cross-platform options with host allowlists - Several commenters doubted the code. amluto said the backend docs read as if a recent LLM had been told to "make these things work at all costs", and that he had approximately zero confidence in the result. kernc counted about 350,000 lines of Rust; dannyw replied that the counting tool misreads Rust comments and that at least half of it is comments or unit tests. its-summertime noted that one month of MXC has more line changes than two or three years of runc. rfgplk claimed a sandbox escape but posted no evidence when asked - minraws, who builds on [[OpenShell]], asked why everyone ships their own sandbox runtime instead of agreeing on a common policy model. hobofan answered that MXC treats multi-platform support as a hard requirement, which OpenShell doesn't meet. torginus and spankalee argued for [[Web Assembly (WASM)|WebAssembly]] instead of OS-level sandboxes; plq asked why Microsoft doesn't package the Firefox or Chromium sandboxes as an SDK - neobrain asked for sandboxes that start minimal and let you grant blocked accesses later from a dashboard, without blocking the agent while it waits (permission fatigue, see [[AI Agent Permissions]]). Replies pointed to nono.sh and OpenShell as partial answers - wild_pointer noted that Windows gained a documented `Experimental_CreateProcessInSandbox` API the month before. fassssst wrote that Codex uses MXC on Windows; I couldn't confirm that from the repo or the docs ## Caveats During the early preview, the README warned that "no MXC profiles should be treated as security boundaries currently" and the default policies generated by the SDK are "overly permissive". At the time, denied paths weren't supported on Windows and network proxying was cooperative on Linux and macOS. The docs (as of October 2026) cover both: ProcessContainer enforces denied paths (natively on BaseContainer hosts, otherwise through temporary deny ACEs on the host files), and on Linux and macOS outbound traffic is confined to the proxy, so a client that ignores it reaches nothing. Using the proxy is still up to the client. Treat it as a guardrail against accidents, not as a boundary against a determined attacker, at least for now. **Update (October 2026)**: [[GitHub Copilot Sandboxing|Copilot's local sandboxing]], built on MXC, went generally available on 2026-10-07. GitHub's docs still describe it as lighter-weight isolation (process and filesystem containment, no VM or container), so the guardrail framing above still holds. **Update (October 2026)**: the preview warning quoted above was removed from the README on 2026-10-06, the day before the first stable release. No backend changed with it: the macOS network gap and the experimental status of the VM backends still apply, so I'd keep treating MXC as a guardrail for now. ## References - Repository: https://github.com/microsoft/mxc - Node SDK: https://www.npmjs.com/package/@microsoft/mxc-sdk - Used by Copilot CLI local sandboxing: https://docs.github.com/en/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing - Copilot local sandboxing GA (2026-10-07): https://github.blog/changelog/2026-10-07-local-sandboxing-for-github-copilot-now-generally-available/ - MXC v1.0.0 release notes (2026-10-07): https://github.com/microsoft/mxc/releases/tag/v1.0.0 - .NET SDK: https://www.nuget.org/packages/Microsoft.Mxc.Sdk - Rust SDK: https://crates.io/crates/mxc-sdk - Seatbelt backend docs (network policy limits): https://github.com/microsoft/mxc/blob/main/docs/backends/seatbelt/seatbelt-backend.md - Nanvix MicroVM backend docs: https://github.com/microsoft/mxc/blob/main/docs/backends/nanvix/nanvix.md - Hyperlight backend docs: https://github.com/microsoft/mxc/blob/main/docs/backends/hyperlight/hyperlight-backend.md - Hacker News discussion (2026-10-09): https://news.ycombinator.com/item?id=50016489 - Anthropic sandbox-runtime (cited on HN): https://github.com/anthropics/sandbox-runtime ## Related - [[GitHub Copilot Sandboxing]] - [[GitHub Copilot CLI]] - [[Windows Sandbox]] - [[Docker Sandboxes]] - [[OpenSandbox]] - [[AI Agents]] - [[AI Agent Permissions]] - [[microVM]] - [[OpenShell]] - [[Linux Containers (LXC)]] - [[WSL Container]] - [[Firecracker]] - [[gVisor]] - [[Web Assembly (WASM)]] - [[AI Agent Harness]] - [[Rust]] - [[Simon Willison]]