MXC: Microsoft's Cross-Platform Sandbox for Untrusted Code

What Microsoft eXecution Container (MXC) is

MXC, short for Microsoft eXecution Container, is a sandboxed code execution system for running untrusted code on Windows, Linux and macOS. The README names the kinds of workloads it targets: model output, plugins and tools. That makes it relevant to anyone building AI agents that execute generated code, developer tools that run third-party extensions, or any application that needs to launch a command without trusting it with the user's files and network.

MXC is not a standalone container runtime you install as a daemon. The README describes it as an SDK dependency that builds into your application. Your app describes the container type, the containment rules and the command to run; MXC validates the request, picks a backend appropriate for the platform and launches the workload inside the resulting container. SDKs are available for Rust, .NET and Node.

The project is aimed at application developers who want one containment API across three operating systems instead of writing separate code for Windows process isolation, Linux namespaces and the macOS sandbox.

How MXC works

The README's architecture diagram is short: your application calls the launch API, the MXC SDK runs in-process, the selected backend also runs in-process, and the backend creates the isolated workload. The consumer glossary defines the vocabulary:

• Container: the isolated environment the command runs in, which may be process isolation, a Linux container, a user session or a VM.
• Backend: MXC's implementation of one container technology, such as Bubblewrap on Linux.
• Workload: the command or program running inside the container.
• Policy: the access rules the container enforces, for example a filesystem policy listing readable, writable and denied paths.

Each platform has a default backend and optional alternatives. Per the README's support table, Windows 11 (x64 and ARM64) defaults to processcontainer, with windows_sandbox, wslc, microvm, hyperlight and isolation_session also available; Windows Sandbox, MicroVM and Hyperlight are marked experimental on Windows. Linux (x64 and ARM64) defaults to bubblewrap, with lxc, microvm and hyperlight as options. macOS (ARM64 and x64) uses seatbelt.

Workloads can run in two styles. Create-and-run is a one-shot transient container: setup, execution and cleanup in a single call. The lifecycle style provisions a persistent container, starts it, runs one or more executions, stops it and deprovisions it. Provisioning returns an opaque container ID that callers must pass back unchanged. The lifecycle docs note that neither style promises a container survives a host reboot.

Requests can also be expressed as versioned JSON. Platform-specific executor binaries such as wxc-exec.exe accept container-creation requests defined by the stable schema, which is useful for testing or when the SDK cannot be embedded.

Key features

• Cross-platform containment: one request model across Windows, Linux and macOS, mapped to platform-native backends.
• Filesystem policy: read-only, read-write and denied path lists. On macOS, the Seatbelt guide explains that denied paths are emitted last so they override broader allows.
• Network policy: directional egress and ingress rules, proxy support and backend-dependent host filtering. An omitted network section takes deny defaults on the Bubblewrap backend.
• UI policy: controls for clipboard, display and GUI access; the Rust SDK disables UI by default.
• Three I/O models: captured output after completion (run), streaming output during execution (spawn) and an interactive pseudoterminal (spawnWithPty in Node).
• Dry-run validation: explicit validation APIs and executor --dry-run flags check a request without launching anything.
• Diagnostics and audit mode: a --debug mode prints MXC diagnostics, and Windows audit mode records the accesses a trusted tool needs so you can build a ProcessContainer policy from them.
• Typed SDKs: Rust (mxc-sdk), .NET (Microsoft.Mxc.Sdk) and Node (@microsoft/mxc-sdk), each exposing the versioned V1 API.

Getting started with MXC

The README says you do not need to clone the repository; install an SDK from your package manager. The Node package's README gives:

npm install @microsoft/mxc-sdk

The Node SDK requires Node.js 24 or later and exports its APIs from @microsoft/mxc-sdk/v1. A request object sets the command, an optional filesystem policy, a network policy such as egress: { default: 'deny' } and a timeout, then run returns captured stdout, stderr and the exit code, while spawn returns a process handle with live streams. The Node and .NET packages include the native runtime assets; the Rust crate compiles the SDK, engine and selected backends into your application.

On Linux, the default Bubblewrap backend needs bwrap 0.5.0 or newer on the PATH. The backend guide gives the Debian and Ubuntu install as:

sudo apt install bubblewrap

When a sandboxed program fails because of an access it was not granted, the executor's debug mode helps:

wxc-exec.exe --debug config.json

To build from source, the README lists Rust 1.93 (pinned by src/rust-toolchain.toml), Node.js 24 or later and the selected backend's platform prerequisites. On Linux the build command is:

./build.sh --all

The repository's samples/ directory has matching Rust, .NET and Node samples for transient and persisted containers, filesystem and network containment, captured, streaming and PTY I/O, telemetry consent and checking platform support without launching a container.

Use cases

• Running AI-generated code: an agent can execute model output in a container with no network egress and a single read-only project directory.
• Plugin and tool hosts: applications that load third-party tools can confine each one to the paths and network access it actually needs.
• Cross-platform desktop apps: one containment request works on Windows, Linux and macOS, with the platform default backend chosen automatically.
• Policy authoring for trusted tools: Windows audit mode captures what a known-good tool touches and produces policy-authoring artifacts to turn into a ProcessContainer policy.
• Long-lived sandboxes: the lifecycle API keeps a provisioned container around for repeated executions, for example an agent session that runs many commands.

How MXC compares

MXC is a layer on top of existing isolation technologies rather than a replacement for them. On Linux it drives Bubblewrap and LXC, on macOS Apple's Seatbelt sandbox, and on Windows several Microsoft mechanisms including Windows Sandbox and WSL containers. Teams that only target Linux could call Bubblewrap directly, and the macOS guide is candid about Seatbelt's limits: it can block or allow outbound network and allow loopback, but has no primitive for allowing one hostname and denying another, so MXC rejects such requests on that backend instead of silently weakening them. The value MXC adds is one typed policy model, consistent validation and structured errors across all three platforms. Its unit of work is a command running under a policy, embedded in your own process through the SDK, rather than a separately managed container service.

Things to know before adopting MXC

• License: MIT.
• Young project: the repository was created in February 2026. Several Windows backends are marked experimental, and older request schema versions are rejected by current contracts, so expect API and schema evolution.
• Platform requirements: Windows support is tied to specific Windows 11 builds listed in the OS-version support page; the macOS Seatbelt backend requires macOS 15 or later; Linux network-enabled modes need extra tools such as slirp4netns, iptables and the nf_conntrack kernel module.
• Audit mode is not a sandbox: the README warns that --audit turns off all sandbox security for the workload and must never be used with untrusted code.
• Telemetry: official Microsoft builds can send optional diagnostic telemetry, but only when the run opts in, the Windows user has consented, administrative policy permits it and the application enables it. Local open-source builds are not configured to send telemetry to Microsoft, and it is a no-op on non-Windows platforms.
• Expect tuning: the README says applications will hit access issues in the sandbox until containment rules are tuned, and provides diagnostics for that.

Project activity

As of October 2026 the repository has about 2,800 stars. It was created in February 2026, is written mainly in Rust with .NET and Node SDKs, and is licensed under MIT, with commits landing in October 2026. The source, samples and documentation are at github.com/microsoft/mxc, and the SDKs are published on crates.io, NuGet and npm.