Microsoft eXecution Container (MXC)

MXC is a sandboxed code execution system for running untrusted code (model output, plugins, and tools) on Windows, Linux, and macOS. It provides multiple containment backends, from OS-native process sandboxes to full VMs, behind a unified containment model and typed SDKs.

Features

• Cross-platform: Windows, Linux, and macOS support with platform-appropriate containment backends
• JSON-based configuration: Versioned container-creation requests and security policies
• Multiple containment backends: ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt, MicroVM (NVX on Windows x64), Hyperlight, IsolationSession, and WSLC
• Policy-driven sandboxing:
  • Filesystem policy: Read-only, read-write, and denied path lists
  • Network policy: Proxy support, outbound controls, and backend-dependent host filtering
  • UI policy: Clipboard, display, and GUI access controls
• Container lifecycle operations: Provision, start, execute, stop, and deprovision persistent containers
• Rust, .NET, and Node SDKs: Versioned APIs for create-and-run execution and container lifecycle operations
• Diagnostics: Tools to understand access-denied failures in a container

What is MXC?

MXC is an SDK dependency that builds into your app.

flowchart LR
    App["Your application<br/>Launch API"] --> SDK["MXC SDK<br/>Rust / .NET / Node<br/>(in process)"]
    SDK --> Backend["Selected backend<br/>(in process)"]
    Backend --> Container["Isolated workload<br/>ProcessContainer / WSLC / Bubblewrap / ..."]

Your application specifies:

• The container type
• The containment rules
• The workload command

MXC validates the request, selects the backend, and launches the workload in the resulting container.

What container types are supported?

MXC runs workloads through platform-appropriate container backends on Windows, Linux, and macOS.

Runtime platform	Default backend	Other backends	Minimum host OS
Windows 11 x64 / ARM64	processcontainer	windows_sandbox*, wslc, microvm*, hyperlight*, isolation_session	Windows OS-version support
Linux x64 / ARM64	bubblewrap	lxc, hyperlight	-
macOS ARM64 / x64	seatbelt	-	-

* These backends are experimental. MicroVM is currently available on Windows x64 only.

How do I use MXC?

Install an SDK through your package manager. You do not need to clone this repository.

SDK	Package
Rust	https://crates.io/crates/mxc-sdk
.NET	https://www.nuget.org/packages/Microsoft.Mxc.Sdk
Node	https://www.npmjs.com/package/@microsoft/mxc-sdk

The Node and .NET packages include the native runtime assets. The Rust crate builds the MXC SDK, engine, and selected backends into the consuming application.

Non-SDK consumption: Platform-specific executor binaries, such as wxc-exec.exe, accept JSON container-creation requests defined by the stable schema. Use for testing or when the SDK cannot be embedded in your app.

Running a contained workload

For complete SDK samples, see the Rust, .NET, and Node samples.

Sample Node snippet

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';

const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  network: { egress: { default: 'deny' } },
  timeoutMs: 30_000,
};

const child = await spawn(request);

See the runnable streaming standard-I/O sample and the SDK API reference.

My application won't run in the sandbox!

Your application will hit access issues when running in a sandbox, until you've had time to tune your containment rules. We're here to help.

Debug console mode

Native executors normally reserve standard input, output, and error for the workload. Use --debug for MXC diagnostic output:

wxc-exec.exe --debug config.json

See MXC diagnostics for the complete developer reference.

Audit mode

Warning: --audit turns off all sandbox security for the workload being analyzed. Never use it to run untrusted code.

Audit mode helps a policy author find access-denied failures and reconstruct a ProcessContainer policy that grants the files and capabilities a trusted tool actually needs. On supported Windows releases, run:

wxc-exec.exe --audit policy.json

MXC records the observed accesses and produces policy-authoring artifacts. See learning mode for safe deny-and-record diagnostics, audit outputs, and supported workflows.

Telemetry

Official Microsoft builds send Required diagnostic data to Microsoft for the development 1.1.0-alpha request contract. MXC is moving to Required telemetry to keep MXC secure, reliable, and up to date: four events describe execution start and end, categorized failures, and process exits. They need no user consent or per-request opt-in, and administrative policy does not block them.

Published 0.9.0-alpha and 1.0.0 requests keep optional telemetry. It is off unless the run opts in, the Windows user has consented, and administrative policy permits collection. An administrator can block that telemetry but cannot grant consent for the user.

Local open-source debug builds are not configured to route telemetry to Microsoft. Windows release builds from source use the bundled signed telemetry component and are routed; set an empty MXC_TELEMETRY_COMPONENT_PATH to build without routing. Telemetry is a no-op on non-Windows platforms. See telemetry policy and consent for controls and privacy details.

This is the beginning of the README. Read the rest at the original. Read the full README ↗