What MXC is trying to unify
Microsoft eXecution Container, or MXC, tackles a real problem for agent developers: running code you did not write without giving it the keys to the host. Instead of making an application speak separately to Windows ProcessContainer, Linux Bubblewrap or LXC, macOS Seatbelt, and several virtual-machine backends, MXC offers versioned JSON policies and a TypeScript SDK. Policies cover filesystem access, outbound networking, UI access, timeouts, and the process itself. The SDK supports both a one-shot spawn call and a state-aware provision, start, execute, stop, and deprovision lifecycle.
That common surface is valuable. An agent runner can ask the same broad questions on three desktop platforms: which directories are readable, which are writable, whether outbound traffic is allowed, and how long a task may live. The repository also separates immutable stable schemas from a development schema, which gives integrators a chance to pin behavior rather than silently inherit every experiment.
The catch is written at the top of the README, not hidden in fine print. MXC is an early preview, some SDK-generated policies are known to be overly permissive, and Microsoft says no current profile should be considered a security boundary. That warning must govern every adoption decision.
Backends do not erase platform differences
The backend list is impressive: ProcessContainer and Windows Sandbox, Bubblewrap and LXC, Seatbelt, WSLC, Hyperlight, IsolationSession, and a NanVix microVM path. Only a subset is considered stable enough to run without the experimental flag. Windows 11 24H2 or newer is required for the default Windows backend, while Linux needs the corresponding Bubblewrap or LXC tools installed. macOS uses Seatbelt.
A unified schema does not mean uniform enforcement. The README says denied filesystem paths are not yet supported on Windows. Network proxy controls on Linux and macOS can be cooperative, meaning a hostile process may not respect the intended route. Individual backends have their own lifecycle and policy limits, so an application cannot safely assume that a rule accepted by the schema has equivalent force everywhere.
Open issue 824 shows why careful backend tests matter. It reports that the experimental WSLC one-shot and state-aware paths interpret some network and port settings differently, including a configuration combination that can permit broader egress than its author likely intended. Issue 764 reports that the LXC backend can start a container before its firewall hook is installed, creating a temporary unfiltered network window. Another report, issue 777, says LXC policy currently fails closed on RHEL 10 because of an obsolete iptables match. Failing closed is preferable to a bypass, but it still turns a nominally supported path into an operational failure.
These are not arguments that MXC is carelessly built. They are evidence that sandbox composition is difficult, and that the project's preview label is accurate.
Setup is an engineering task
For a quick SDK trial, install @microsoft/mxc-sdk, check platform support, create a policy, and spawn a child. Building the complete project needs Node 18 or newer, npm, and Rust 1.93, plus platform-specific toolchains. The repository provides Windows, Linux, and macOS build scripts, unit tests, integration tests, end-to-end tests, lint commands, schema references, diagnostics, and backend design documents. This is excellent documentation for contributors.
Production evaluation is harder than compilation. You must choose a backend based on the host, enumerate enforcement gaps for that exact OS release, build adversarial tests, and decide what happens when policy setup fails. Stable and development schemas need deliberate pinning. The state-aware lifecycle also creates more cleanup and authorization questions than a one-shot process. A successful sample that prints from Python proves the plumbing works, not that containment does.
Audit mode deserves special caution. On Windows ProcessContainer it intentionally puts AppContainer restrictions into permissive learning mode, allowing denied actions so developers can discover required capabilities. That is useful for authoring policy, but a disastrous production default. The CLI rejects audit mode for backends that cannot honor it, and the README clearly warns what it does. Operators still need controls that prevent a diagnostic flag from reaching an untrusted run.
Documentation and project health
MXC's strongest quality is unusually direct documentation. The README distinguishes stable and experimental backends, lists minimum host requirements, explains what telemetry can do, and admits enforcement limits. Telemetry is off by default and requires both an experimental CLI flag and an enabled configuration. Local open-source builds lack Microsoft's provider group identifier, so their events remain in local Windows ETW rather than being routed to Microsoft by default.
The repository had 1,219 stars, 87 open issues and pull requests, and an MIT license when researched. Its last push was August 12, 2026, the same day this review was prepared, and current issue and pull-request discussion is active. There is no latest GitHub release, however, which fits the early-preview status. Activity is strong; maturity is not. Those are separate judgments.
Recent security-focused pull requests are also revealing. Pull request 727 proposes restricting a macOS Seatbelt profile override that can replace the deny-first profile. Pull request 728 documents a one-principal trust assumption and warns embedders that accept lower-trust configuration to impose their own constraints. Whether or not each change lands in its current form, the discussions show the team is still defining important trust boundaries.
The practical verdict
MXC is worth watching and worth testing if you build local agents or developer tools across operating systems. The shared schema, lifecycle API, candid documentation, and active development provide a strong foundation for experimentation. It could also reduce large amounts of platform glue once its guarantees settle.
Today, use it as an integration layer inside a threat model that already assumes MXC may fail open. Put sensitive credentials outside reachable paths, restrict the host or VM around it, test every chosen backend, and pin schemas. If your requirement is a dependable isolation boundary now, choose a narrower established runtime such as Firecracker, gVisor, or Bubblewrap and accept the platform-specific work. MXC's promise is broad, but its own warning is decisive.