mxc

What MXC provides

MXC is a sandboxed code execution system for running untrusted code, which the README describes as model output, plugins, and tools. It targets Windows, Linux, and macOS and offers several containment backends behind a single JSON configuration schema and a TypeScript SDK. The listed backends include ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seatbelt on macOS, a MicroVM called NanVix, Hyperlight, IsolationSession, and WSLC. The point is that you describe what an execution is allowed to do once, in JSON, and MXC maps that to whatever sandbox the platform supports. Policies are split into filesystem rules with read-only and read-write path lists, network rules with proxy support and allow or block outbound behavior, and UI rules covering clipboard, display, and GUI access. A state-aware lifecycle moves a session sandbox through provision, start, exec, stop, and deprovision. Diagnostics include debug logging and Event Tracing for Windows for troubleshooting. The breadth of backends means the same policy can run under a heavyweight VM on one machine and a light process sandbox on another, which is the practical reason to adopt a unified schema instead of learning each platform's isolation primitives separately. For teams running model-generated code, one description is far easier to review than a pile of OS-specific scripts.

Building and platforms

The building section shows the project is a Rust workspace with a native container wrapper plus the TypeScript SDK. Platform tables list a default backend per operating system and the other backends available there, with minimum build requirements such as Windows 11 24H2 or later. Lint and format commands are given for Windows, Linux, and macOS Rust builds. The SDK README covers the full API. Because the SDK is published to npm as @microsoft/mxc-sdk, application code can stay in TypeScript while the heavy isolation work runs in the native layer. The unified schema is the practical benefit: a developer writes one policy document instead of learning each platform's sandboxing primitives. For teams running model-generated code, that single description is easier to review and audit than a pile of OS-specific scripts. The repo also notes that individual components can be built separately, which helps when you only need the wrapper or only the SDK. The separation of the Rust core from the npm SDK also means web-focused developers can consume MXC without touching Cargo, while systems developers can build the sandbox layer alone. That split is reflected in the project structure section, which organizes the workspace so each piece builds on its own.

Preview status and cautions

The README is clear that this is an early preview published to gather integration feedback from developers. It warns that the underlying sandboxes are expected to change as they are under ongoing development, though the team aims to limit compatibility impact. There are known cases where the policies generated by the current MXC SDK are overly permissive, and those will be addressed before the system is made more generally available. The document states plainly that no MXC profiles should be treated as security boundaries yet, and it welcomes partnership with security researchers while MXC matures. That honesty is important: the tool is useful for structuring execution today, but you should not rely on it as a hard security wall in production. Given the MIT license and Rust implementation, the code is open for review, and the preview label tells you exactly how much trust to place in the current policy enforcement. The warning about denied paths not yet being supported on Windows is a concrete example of a gap you must design around. Until those gaps close, treat MXC as a structuring and isolation aid, and keep a real security boundary, such as a separate machine or account, underneath it for anything genuinely untrusted.

Editorial conclusion

MXC is published under the MIT license, written in Rust, and ships a TypeScript SDK on npm as @microsoft/mxc-sdk.