MXC: Microsoft's policy-driven sandbox for running untrusted code across three OSes

What MXC actually solves

MXC addresses a narrow but common problem: executing code you do not trust, such as large language model output, third-party plugins, or user-supplied tools, without letting that code reach the host system. The project is aimed at developers building agents, automation pipelines, or plugin hosts that need to run arbitrary code with some containment. The README frames it as a sandboxed code execution system, not a general virtualization product. The key differentiator is that MXC tries to give you one way to describe the containment policy, then picks a backend based on the host platform. That saves you from learning the native sandbox API on each OS, which is a real cost when you support more than one platform.

How the layered containment works

The core design is a policy-driven abstraction over multiple containment backends. You write a JSON configuration that describes filesystem, network, and UI restrictions. The native wrapper, named wxc-exec on Windows, lxc-exec on Linux, and mxc-exec-mac on macOS, reads that config and launches the appropriate backend. The backends range from OS-native process sandboxes like Windows processcontainer and macOS Seatbelt, to full isolation with LXC, Bubblewrap, and microVMs. The README lists nine backends total, including experimental ones like Hyperlight and IsolationSession. The lifecycle is state-aware: provision, start, exec, stop, and deprovision, which matters for session-based sandboxes that need to persist state across multiple commands. The policy schema is versioned, and the SDK can generate policies from helper functions like getTemporaryFilesPolicy and getAvailableToolsPolicy, which suggests a move toward safer defaults, though the warning says those defaults are currently too permissive.

Getting it running: commands and config

To use MXC you either call the native binary directly or use the TypeScript SDK. The native binary takes a JSON config file as an argument: wxc-exec.exe config.json on Windows, ./lxc-exec config.json on Linux, and ./mxc-exec-mac --experimental config.json on macOS. You can also pass the config as base64 with --config-base64, and add --debug for verbose output. The SDK is installed via npm install @microsoft/mxc-sdk, and the README shows importing spawnSandboxFromConfig, createConfigFromPolicy, getAvailableToolsPolicy, and getPlatformSupport. A typical flow starts with checking getPlatformSupport().isSupported, then building a config from a policy, then spawning. The build requires Rust 1.93, pinned via rust-toolchain.toml, and Node.js 18 or newer. Platform-specific build scripts exist: build.bat for Windows, build.sh for Linux, build-mac.sh for macOS.

Platform support and experimental backends

The platform table in the README is the first place to look before committing. Windows 11 24H2 or newer is the verified base, with processcontainer as the default backend and a minimum build of 26100. IsolationSession requires an Insider Preview build 26340.9212, which is a hard constraint for anyone on stable Windows releases. Linux x64 and ARM64 default to Bubblewrap, with LXC, microVM, and Hyperlight as alternates. macOS ARM64 and x64 use Seatbelt, and the schema version must be 0.7.0-alpha or later. The stable one-shot backends, processcontainer, bubblewrap, lxc, and seatbelt, do not require experimental mode. Everything else, including windows_sandbox, wslc, microvm, and hyperlight, requires setting experimental: true in SandboxSpawnOptions or passing --experimental on the CLI. That split is a practical gate: you can try the basic backends without opting into unstable code, but the more isolated backends are clearly not production-ready.

Known limitations and the wrong-tool cases

The most honest limitation is in the README's own warning block: the sandboxes are under development, policies generated by the SDK are overly permissive, and no MXC profile should be treated as a security boundary. That is a direct statement that you should not rely on MXC to contain a determined attacker. There are also feature gaps. Denied filesystem paths are not supported on Windows, which means you can whitelist read-only and read-write paths but cannot explicitly block a specific sensitive file. Network policy on Linux and macOS is cooperative, meaning the sandboxed process is expected to honor the proxy setting, which is not a hard enforcement. The macOS backend is marked experimental in the usage example, even though the platform table lists it as stable, which is a contradiction you should verify before relying on it. If your workload needs strong isolation on macOS today, this is not ready.

Alternatives and their different approaches

The obvious alternative is to use the native sandbox directly: Windows Job Objects and AppContainer, Linux namespaces and seccomp, or macOS Seatbelt. That approach gives you full control and no extra abstraction layer, but it means writing and maintaining three separate policy implementations. Another alternative is a VM-based sandbox like Firecracker or gVisor, which MXC itself can use as a microVM backend, but running those directly requires more infrastructure and a heavier runtime. The difference in approach is that MXC tries to unify the policy format and lifecycle, while native sandboxes and standalone VMs force you to handle each platform's quirks yourself. If you already have a team that knows Windows sandboxing deeply, the abstraction may add more complexity than it removes.

Maintenance and upgrade cost

The project is actively developed, with releases v0.6.1, v0.7.0-rc1, and v0.8.0 pushed in 2026, and the last push on 2026-08-22. The README says the underlying sandboxes are expected to change, and they aim to minimize compatibility impact but do not promise it. That means upgrading MXC could break your policy files or SDK calls. The Rust toolchain is pinned to version 1.93, so you need to keep rustup in sync. The build process is multi-step: build the Rust binary, copy it into sdk/node/bin/<arch>/, then build the TypeScript SDK. That is not a single-command install. The license is MIT, which is permissive for commercial use, but the early-preview status and the explicit non-security-boundary warning carry more risk than a typical MIT project. You should plan to re-test your policies after each MXC release, not just bump the version.

Editorial conclusion

Adopt MXC if you need a single configuration schema to run untrusted model output, plugins, or tools across Windows, Linux, and macOS and you can tolerate an early preview where policies are known to be overly permissive. Do not adopt it if you require a hardened security boundary today, because the README explicitly says no MXC profile should be treated as one. Before integrating, verify which backend your target OS supports, confirm whether you need experimental mode for that backend, and check the Windows OS-version policy support table, since filesystem and network enforcement varies by Windows release.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes