MXC .NET SDK support

[samanthamsong]

Epic: «Secure & contained node (MXC)» (#837)
Backlog Doc ID: #2 · Priority: P2 · Area: containment

Description
Replace our exec-based build script with a proper .NET SDK for MXC.

Definition of done
Node builds/integrates via the MXC .NET SDK instead of the exec shim.

Part of the «Secure & contained node (MXC)» tracking issue (#837).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 1:58 PM ET / 17:58 UTC.

Summary
Keep this collaborator-authored security-boundary feature open. Current main still obtains wxc-exec.exe from the Node MXC package and launches it from .NET, so the requested managed SDK replacement is not implemented. A maintainer must select the supported SDK and approve the containment, fallback, packaging, and validation contract before work can be safely scoped.

Likely related people: Scott Hanselman is the strongest source-history routing candidate, with Barbara Kudiess a recent contributor to the adjacent exec-approval path.

Reproducibility: not applicable. as a failure reproduction: this is an implementation-direction request. Current source does provide high-confidence confirmation that the active path still uses the executable bridge rather than a managed .NET SDK.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should OpenClaw replace the currently packaged wxc-exec.exe bridge with a specific supported managed .NET MXC SDK, and what containment and host-fallback compatibility contract must that migration preserve?	Sponsor a managed SDK migration: Select a supported .NET SDK and require a focused design and proof plan that preserves policy, fallback, packaging, diagnostics, and real MXC containment behavior.

Why: The requested work changes the implementation of the system.run sandbox boundary and cannot be reduced to a mechanical refactor without choosing an SDK support policy and acceptable upgrade behavior.

Next step
A maintainer must choose the managed SDK and the security and upgrade contract before a bounded implementation PR can be safely defined.

Security
Needs attention: This security-sensitive issue proposes replacing the system.run containment mechanism, so SDK parity and real containment proof require deliberate review before implementation.

Review details

Best possible solution:

Adopt a maintainer-selected managed MXC SDK behind the existing command-runner seam, preserving current containment policy, compatibility fallback behavior, tray diagnostics, package publishing, and real Gateway positive and denied-write proof.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a failure reproduction: this is an implementation-direction request. Current source does provide high-confidence confirmation that the active path still uses the executable bridge rather than a managed .NET SDK.

Is this the best way to solve the issue?

Unclear until maintainers select a supported SDK and compatibility contract. Current main does not meet the requested managed-integration direction, but an unplanned replacement would be unsafe at the command-containment boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A managed SDK migration can weaken or alter AppContainer containment if its policy serialization, command-line/argv behavior, output caps, or denied-write semantics diverge from the current helper.
• Replacing the packaged executable also changes restore and publishing behavior; compatibility fallback and the required real Gateway MXC proof must remain explicit before merge.

Codex review notes: model internal, reasoning high; reviewed against 8ac00c5f4977.

Label changes

Label justifications:

• P2: This is a meaningful containment-platform improvement, but current evidence does not show an active security bypass, data loss, or unavailable core runtime.
• impact:security: The request replaces the execution mechanism that enforces AppContainer containment for Windows node commands.

Evidence reviewed

Security concerns:

• [high] Preserve containment semantics across SDK migration — src/OpenClaw.Shared/Mxc/MxcExecutor.cs:9
  The current helper owns AppContainer command execution, policy transport, and availability behavior; a managed replacement must prove equivalent containment and denied-write behavior through the real gateway path.
  Confidence: 0.92

What I checked:

• Current executable bridge: Current main explicitly defines the MXC executor as running commands through wxc-exec.exe, validates an executable path at construction, and starts that executable with ProcessStartInfo; this is not a managed SDK invocation. (src/OpenClaw.Shared/Mxc/MxcExecutor.cs:9, 8ac00c5f4977)
• Current packaging contract: The tray project restores @microsoft/mxc-sdk solely to extract wxc-exec.exe and copies that executable plus sibling DLLs into the application output, confirming the Node package remains the current integration boundary. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:110, 8ac00c5f4977)
• Current call site: The direct AppContainer executor requires a resolvable wxc-exec.exe path and constructs MxcExecutor with it before execution, so replacing the shim changes the active system.run containment path rather than an unused build dependency. (src/OpenClaw.Shared/Mxc/DirectAppContainerExecutor.cs:73, 8ac00c5f4977)
• Runtime proof boundary: The repository requires a real Gateway to Windows node MXC proof with successful contained execution and a denied-write check, which a managed SDK migration must preserve. (docs/WINDOWS_NODE_TESTING.md:181, 8ac00c5f4977)
• Feature-history routing: Retained path-scoped history identifies Barbara Kudiess's exec-approval V2 work and Scott Hanselman's current-source provenance around the MXC area. The local promisor checkout could not retrieve older missing objects, so this is conservative routing rather than a claim of sole ownership. (src/OpenClaw.Shared/Mxc/MxcExecutor.cs:1, 15ed439dc5a3)
• Maturity label unavailable: The required maturity helper found no qa/maturity-scores.yaml in this checkout, so no stable-surface maturity label can be supported.

Likely related people:

• Scott Hanselman: git blame attributes the inspected MXC executor source to Scott's retained commit, making him the strongest available routing candidate for the present executable bridge. (role: current code provenance; confidence: medium; commits: 15ed439dc5a3; files: src/OpenClaw.Shared/Mxc/MxcExecutor.cs)
• Barbara Kudiess: Path-scoped retained history includes Barbara's recent exec-approval V2 work, which is adjacent to the system.run route that selects MXC containment. (role: recent area contributor; confidence: medium; commits: 4806eaac7c24; files: src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs, tests/OpenClaw.Shared.Tests/Mxc/MxcCommandRunnerTests.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.