Microsoft's MXC: one SDK to sandbox agent-run code on Windows, macOS and Linux

MXC is Microsoft's open-source SDK for sandboxing model-written code across three OSes, for builders shipping agents that run commands locally.

Picture a two-person shop building an internal coding agent in Node. It writes small scripts, runs tests and edits a client's repo. Half the team is on MacBooks and half on Windows laptops. Today the agent's shell commands run with the full rights of whoever launched it. That covers their SSH keys, their Documents folder, every network destination, and the production config file the agent was only meant to read. The usual fixes don't fit well. Wrapping everything in Docker adds a heavy dependency for a desktop tool. Hand-rolling Seatbelt profiles on macOS and something else on Windows means maintaining a different sandbox per OS. And nobody can easily say why a command failed once it's locked down.

That is the gap Microsoft Execution Containers (MXC) targets. It's an open-source SDK, published on GitHub, that puts one policy model in front of each operating system's own sandbox. Microsoft declared it generally available on October 7, 2026, according to the Windows Developer Blog. Simon Willison flagged it the next day as "very promising."

What it is

The README describes MXC as "a sandboxed code execution system for running untrusted code (model output, plugins, and tools) on Windows, Linux, and macOS." It is an SDK dependency that builds into your app, not a service you run. Your application supplies three things: the container type, the containment rules and the workload command. MXC validates the request, picks the backend and launches the workload.

Here is how the pieces map to the lede's pain:

The design rule, per Microsoft, is that "an agent cannot be its own security authority": the policy sits outside the workload, so generated code can't grant itself more access. Pureinfotech reports that Microsoft lists GitHub Copilot, OpenAI Codex, OpenClaw, Replit, LM Studio and Unsloth AI as already supporting MXC, with Claude Code, Perplexity, Raycast and others said to be coming. Microsoft's Command Line post says Copilot can run commands "with controlled access to files, networks, system capabilities, and credentials."

Alternatives worth weighing:

Who it's for

Pick it up if you ship an app or agent harness, in Node, Rust or .NET, that executes model-written code or third-party tools on users' own machines. It suits you most if those machines are a mix of Windows, Mac and Linux and you'd rather not maintain three sandbox configs. Windows-heavy teams get the most: session containers, WSLC and the audit tooling are Windows-only.

Skip it for now in three cases:

Before and after

Before:

  1. The agent proposes a shell command.
  2. Your harness runs it as the logged-in user, with full file and network access.
  3. You rely on prompt instructions and an approval click to keep it out of ~/.ssh or the production config.
  4. For real isolation you write per-OS sandbox code, or ship Docker.
  5. When a locked-down command fails, you guess why.

After:

  1. The agent proposes a command.
  2. Your harness wraps it in an MXC ContainerRequest that declares the command, network egress rules and a timeout.
  3. MXC picks the platform backend (Seatbelt, Bubblewrap or the Windows process container) and enforces the policy outside the agent's control.
  4. If the command hits a wall, MXC's diagnostics explain the access-denied failure.
  5. While authoring policy, you tune it in a learning-style mode. Ccleaks, a lower-reliability how-to outlet, describes three modes (Enforcement, Learning, Permissive) and says the activity report is available only on Windows.

Ccleaks reports that Microsoft suggests using a coding agent to integrate the SDK and draft the first policy, then reviewing and refining it by hand. That is a reasonable vibe-engineering loop, as long as a human owns the final policy.

Try it

You don't need to clone the repo. The README says to install an SDK from your package manager:

The Node and .NET packages include the native runtime assets. The Rust crate compiles the SDK, engine and chosen backends into your app. The README's Node example runs a command with outbound network denied and a 30-second timeout:

import { spawn, type ContainerRequest } from '@microsoft/mxc-sdk/v1';
const request: ContainerRequest = {
  command: 'node -e "console.log(\'hello from container\')"',
  network: { egress: { default: 'deny' } }, // block all outbound traffic
  timeoutMs: 30_000,
};
const child = await spawn(request);

The README notes that your app "will hit access issues when running in a sandbox, until you've had time to tune your containment rules." If you use the standalone executor, you can get diagnostic output with:

wxc-exec.exe --debug config.json

Building from source is only needed if you're changing MXC itself or using the executors directly. It requires Rust pinned to 1.93 and Node.js 24 or later. Our sources don't give SDK version numbers or a minimal file-policy JSON example. Use the repo's samples/ and docs/api-reference/ folders for those.

Where it breaks

Sources