微软执行容器（Microsoft eXecution Container, MXC）是一个沙盒化代码执行系统，用于在 Windows、Linux 和 macOS 上运行模型输出、插件和工具等不受信任的代码。它在统一隔离模型和类型化 SDK 背后提供多种隔离后端，涵盖从操作系统原生进程沙盒到完整虚拟机。

Microsoft 执行容器（MXC）

MXC 是一个沙盒代码执行系统，用于在 Windows、Linux 和 macOS 上运行不受信任的代码（模型输出、插件和工具）。它在统一的隔离模型和类型化 SDK 之下，提供从操作系统原生进程沙盒到完整虚拟机的多种隔离后端。

功能

• 跨平台：支持 Windows、Linux 和 macOS，并使用适合各平台的隔离后端
• 基于 JSON 的配置：带版本的容器创建请求和安全策略
• 多种隔离后端：ProcessContainer、Windows Sandbox、LXC、Bubblewrap、Seatbelt、MicroVM（Nanvix）、Hyperlight、IsolationSession 和 WSLC
• 策略驱动的沙盒：
  • 文件系统策略：只读、读写和拒绝路径列表
  • 网络策略：代理支持、出站控制，以及依赖后端的主机过滤
  • UI 策略：剪贴板、显示和 GUI 访问控制
• 状态感知生命周期：配置、启动、执行、停止和解除配置持久化容器
• Rust、.NET 和 Node SDK：为一次性执行和状态感知执行提供带版本 API
• 诊断：用于理解容器内访问被拒绝失败的工具

什么是 MXC？

MXC 是一个会编译进你应用的 SDK 依赖。你的应用通过 Launch API 调用进程内的 MXC SDK（Rust / .NET / Node），SDK 再调用选定的后端（进程内），最后由后端启动隔离的工作负载（ProcessContainer / WSLC / Bubblewrap 等）。

你的应用指定：容器类型、隔离规则、工作负载命令。MXC 验证请求、选择后端，并在生成的容器中启动工作负载。

支持哪些容器类型？

MXC 通过适合平台的容器后端在 Windows、Linux 和 macOS 上运行工作负载。

• Windows 11 x64 / ARM64：默认后端 processcontainer；其他后端有 windows_sandbox、wslc、microvm、hyperlight*、isolation_session；最低主机系统要求见 Windows OS-version support
• Linux x64 / ARM64：默认后端 bubblewrap；其他后端有 lxc、microvm、hyperlight
• macOS ARM64 / x64：默认后端 seatbelt，无其他后端

带 * 的后端为实验性。

如何使用 MXC？

通过包管理器安装 SDK，无需克隆本仓库。

• Rust：mxc-sdk
• .NET：Microsoft.Mxc.Sdk
• Node：@microsoft/mxc-sdk

Node 和 .NET 包包含原生运行时资产。Rust crate 会把 MXC SDK、引擎和选定后端编译进使用方应用。

非 SDK 使用方式：平台特定的执行器二进制文件（如 wxc-exec.exe）接受由稳定 schema 定义的 JSON 容器创建请求，适用于测试或应用无法内嵌 SDK 的情况。

运行受隔离的工作负载

完整 SDK 示例见 Rust、.NET 和 Node 示例。

示例 Node 片段

示例代码从 @microsoft/mxc-sdk/v1 导入 spawn 和 ContainerRequest，构造请求：命令为 node -e "console.log('hello from container')"，网络 egress 的 default 设为 deny，timeoutMs 为 30_000，然后 await spawn(request) 启动容器。

可运行的流式标准 I/O 示例和 SDK API 参考见对应链接。

我的应用无法在沙盒中运行！

在调整好隔离规则之前，应用在沙盒中会遇到访问问题。我们可以提供帮助。

调试控制台模式

原生执行器通常把标准输入、输出和错误保留给工作负载。使用 --debug 获取 MXC 诊断输出：

wxc-exec.exe --debug config.json

完整开发者参考见 MXC diagnostics。

审计模式

警告： --audit 会关闭正在分析的工作负载的所有沙盒安全机制，切勿用于运行不受信任的代码。

审计模式帮助策略作者发现访问被拒绝的失败，并重建 ProcessContainer 策略，以授予受信任工具实际需要的文件和权限。在支持的 Windows 版本上运行：

wxc-exec.exe --audit policy.json

MXC 会记录观察到的访问并生成策略编写产物。安全拒绝并记录诊断、审计输出和支持的工作流见记录访问被拒绝。

遥测

官方 Microsoft 构建可以发送可选诊断遥测给 Microsoft。除非单次运行选择加入、Windows 用户明确同意、管理策略允许收集，且应用在受隔离工作负载请求中启用遥测选项，否则遥测关闭。管理员可以阻止遥测，但不能代替用户给予同意。

本地开源构建未配置将遥测发送到 Microsoft，且遥测在非 Windows 平台上是空操作。控制和隐私细节见遥测策略与同意。

从源码构建

在开发 MXC、修改原生运行时，或使用独立执行器二进制文件而非打包 SDK 时，可从源码构建。仓库构建会生成平台原生运行时和执行器，并暂存 Node SDK 使用的原生资产。

构建先决条件：

• Rust，由 src/rust-toolchain.toml 固定为 1.93 版本
• Node.js 24 或更高版本及 npm
• 所选后端描述的平台工具链和先决条件

构建

Windows

build.bat --all：为当前架构生成 Release 构建。

Linux

./build.sh --all：Release 构建。

macOS

./build-mac.sh --all：为原生架构生成 Release 构建。

文档

使用者文档

• SDK 示例：samples/ — 可运行的 Rust、.NET 和 Node 场景
• SDK API 参考：docs/api-reference/ — 支持的 V1 操作和类型
• 容器生命周期：docs/container-lifecycle.md — 持久化容器生命周期概述
• 记录访问被拒绝：docs/logging-access-denied.md — 诊断被阻止的访问并编写策略
• 遥测：docs/telemetry.md — 同意和管理控制
• 后端指南：docs/backends/ — 平台和后端先决条件与行为

仓库贡献者应从 MXC 开发文档 开始。

贡献

见 CONTRIBUTING.md 的贡献指南。

许可证

详见 LICENSE.md。

多数声音质疑 MXC 的安全性、复杂度与是否只是重复造轮子，少数人认为它作为统一抽象确有实用价值；反微软的品牌抵触与务实接受并存，且普遍焦虑代理沙箱碎片化。

认为 MXC 把跨平台沙箱后端封装得实用，但 macOS 仍有短板

• 正面评价集中在它像 bubblewrap、seatbelt、processcontainer 的统一前端/SDK：手工把这些后端配一致远非易事，自己从零撸是糟糕主意；学习模式、MIT 许可、清晰的遥测披露和轻量文档都加分，且 Codex 已在 Windows 上用它，说明首版就有落地价值（较多人） > 把它看成 bubblewrap、seatbelt 等后端的统一前端就好，手工保持一致远非易事，自己从零撸是糟糕主意（@dannyw）
• 也有人以 @simonw 为代表提醒：macOS 端缺少按主机名、IP、CIDR、端口或协议的细粒度网络控制，只是 Linux/Windows 上没有这个限制，这正是跨平台抽象层的通用难题（少数人）

认为 MXC 及其底层后端存在真实安全缺陷

• 最尖锐的指控是 MXC 自身就能被沙箱逃逸，能力顺序、setuid 与能力丢弃都有问题，且底层 bubblewrap 无法抵御已受损的内核，安全上完全不可信（少数人） > 它里面就有沙箱逃逸，能力顺序、setuid 和能力丢弃都不对，底层 bubblewrap 也挡不住被攻陷的内核，正是微软该有的水平（@rfgplk）

认为沙箱运行时正在重复造轮子，应先统一最小策略

• 与其每个项目都自己实现代码执行代理运行时，不如像 Unix 那样先设计沙箱策略，再在其上构建，并形成各项目共通的最小子集，否则差异会让移植和验证安全面都很痛苦；一旦某个公共 CVE 爆发，几十个“氛围编码”的拷贝版都会同时裸奔（较多人） > 大家都在各造各的代码执行代理运行时，不如像 Unix 那样先定沙箱策略，再在其上构建，至少要有共通的最小子集，否则移植和验证安全面都很痛苦（@minraws）
• 连@pprotas都调侃“微软偷了我的主意”，因为现在真是人人都在做沙箱，这种玩笑反映出社区对重复造轮子的疲惫（少数人）

认为项目过于庞大、不可审计，不如小而可控的实现

• 有开发者指出 MXC 仅 Rust 就约 35 万行，且上游沙箱没有被 vendored，和“建立在自己能看懂、能审计的东西上”相比，这种规模让人不安（少数人） > 这个仓库光 Rust 就有约 35 万行，上游沙箱甚至没有 vendored，我更愿意建立在自己能看懂、能审计的东西上（@kernc）

认为微软品牌让人直接失去信任

• 反微软情绪很直接：有人看到 M 代表 Microsoft 就关掉标签页，认为这个前缀只是“看我”的自我宣传，加上公司本身有毒，连代码都不想看（少数人） > 看到 M 代表 Microsoft 就关掉了标签页，这个前缀纯粹是自我宣传，而且公司本身有毒（@zenapollo）

认为代理执行必须被严格隔离，不能默认信任

• 支持严格隔离的人认为，面向模型的执行早该有类似 Docker 的边界，不能让代理进程拥有运行 rm -rf / 的能力，它应被当作和 wget 管道给 sh 一样危险的操作来对待（少数人） > 我们早就该有面向模型的 Docker 了，不能让这些进程拥有运行 rm -rf / 的能力，它应当和 wget 管道给 sh 一样被严格对待（@superxpro12）

认为现有沙箱缺少动态授权与外部审批机制

• 理想中的最小沙箱应先挡住访问，再把被拦的请求聚合到外部 TUI 面板里异步放行，而不是每次都阻塞代理等待确认，否则会逼出“一律同意”的疲劳；这类动态授权能力目前还很稀缺（少数人） > 理想情况是最小沙箱先挡住访问，再把被拦的请求聚合到外部 TUI 面板里异步放行，而不是每次都阻塞代理等确认（@neobrain）

认为 Rust SDK 接口不错但构建脚本和依赖太重

• 从工程角度看，Rust mxc-sdk 的 API 设计漂亮，但构建脚本里塞了二进制、在全部平台做 Windows 专属工作，后端也没用 feature 隔离，未来 Cargo 版本可能踩坑，依赖也偏重（少数人） > Rust SDK 的 API 看着漂亮，但构建脚本里塞了二进制、在全部平台做 Windows 专属工作，后端也没用 feature 隔离，依赖还偏重（@epage）

质疑这层复杂度只是大公司管控需求

• 也有人从个人使用经验出发怀疑必要性：给 Codex 每线程全权限跑了一年多也没出事，所以怀疑这层沙箱复杂度未必对个人必要，可能主要是大公司出于控制需求才需要（少数人） > 我给 Codex 每个线程都开全权限跑了一年多也没出问题，真需要这层复杂度吗，还是只有要管控的大公司才需要（@mintflow）

有价值的补充

• MXC 与 Flatpak 的定位差别：MXC 是面向代理的跨平台“这个工作负载能碰什么”抽象层，Flatpak 则是 Linux 应用格式，其沙箱在 Linux 上恰好与 MXC 共用后端（由 @smitty1e 借 Grok 给出）。
• Windows 上个月才新增 ExperimentalCreateProcessInSandbox 进程沙箱 API，如今既已公开文档化，这个带 Experimental 的名字就会永久定型（@wildpointer）。
• 已有开发者用 wasmtime 搭配 wasm32-wasip3 写沙箱插件，Rust 工具链体验不错；wasip3 尚未稳定，但相比 wasip2 对异步代码集成更友好（@eminence32）。
• 跨平台细节仍有未解疑问：@arj 问 Windows 沙箱容器能否继续在 WSL 里执行命令，@ranger_danger 问它与 Sandboxie 的区别，这些对比还没有结论。