是否考虑引入MXC做windows沙箱

[whale4rain]

我看到 OpenAI 的 Windows Sandbox 文档 使用了 MXC，想问一下 DSH 后续是否考虑接入 MXC 作为 Windows 沙箱后端？

相比继续维护现有的 Windows 沙箱实现，MXC 是否有机会改善进程隔离、权限控制以及 Node.js 开发工具的兼容性？

[argszero]

I can't speak for the maintainers' roadmap, but I can answer the part that is decidable from the source today: where a different Windows backend plugs in, and what it would have to implement. That is the part that decides whether MXC is a backend swap or something larger.

Two different extension points exist, at different levels.

1. Runner override — no new package, config only. packages/sandbox/sandbox-local/src/index.ts:328-335 short-circuits everything when Config.runnerCommand is set (:55, with runnerFailureSignatures required alongside it, :56-60): the wrapped argv becomes

[...runnerCommand, ...bwrapProfileArgs(policy), '--', ...argv]

with enforcement: 'full' asserted by the operator (no probe), and the denial dialect fixed to ['read-only file system', 'permission denied'] (DENIAL_SIGNATURES.runnerCommand, :214). So this rung only fits a replacement runner that speaks bwrap's profile dialect — bwrap-compatible profile argv, then --, then the command. A backend with its own CLI vocabulary does not fit here.

2. Backend replacement — a package. ctx.sandbox is an abstract service, packages/sandbox/sandbox/src/index.ts:159, with exactly one method to implement (:177):

confine(argv, policy, signal): Promise<ConfinedArgv>

A package that mounts itself as the sandbox service replaces the whole backend for the composition. The contract it must honour is the ConfinedArgv shape (:88-117): enforcement (full | partial, :60), the backend's own denial dialect in denialSignatures (:109), and runnerFailureRules (:116) — the exit-code-plus-stderr rules that distinguish "the confinement runner failed" from "the command ran and was denied". Consumers match against those two fields rather than a cross-backend union: the denial marker and the escalation prompt are keyed off denialSignatures, so a backend that reports them loosely loses the distinction the rest of the stack depends on.

What ships today on Windows is the windows-acl rung: enforcement: 'partial' (sandbox-local/src/index.ts:188), runner failure identified by exit 127 plus the windows-acl-run: signature (:241), and the three named reasons for the partial verdict in that package's module doc (:17-20: NTFS hard links alias one file object; reads stay unconfined; a tree another AppContainer tool has ACL'd with a package SID is unreadable by the Low-integrity child).

The framing that decides your question is in packages/sandbox/sandbox/README.md: the service is same-world confinement — "the process still shares the host kernel and filesystem; use a container, microVM, or remote executor when the whole environment must be isolated", and such a backend "replaces the whole ctx.shell / ctx.fs capability rather than adding a backend here". So:

• if MXC presents itself as this process, wrapped, it belongs at level 2 (or level 1 if it can be spoken to in bwrap's dialect);
• if it is a microVM/container boundary, the honest shape is a replacement for the shell/filesystem capability, not a fourth rung in the same-world chain.

Either way it is composer-visible rather than deep in the Windows code: the local backend already selects its rung per platform and probes candidates functionally (sandbox-local/src/index.ts:1-20, :142), and the fail-closed error names the OS-level options it knows (SandboxUnavailableError, packages/sandbox/sandbox/src/index.ts:132-146) — a new backend would extend that list rather than route around it. One practical note for whoever takes it: the Windows reports in this tracker (the standing Low-integrity label, 0xC0000142 under restricted tokens) are all downstream of the windows-acl rung's grant model, so a replacement backend should be compared against those cases, not only against "does a command run at all".