OpenShell: Skill for Claude Code

Build OpenShell-MXC for Windows

This skill maintains the existing native Windows MSVC build lane in the OpenShell repository's windows branch. That branch owns native Windows implementation and releases. Shared docs may also appear on main; always direct Windows work to windows and use explicit Windows branch links for implementation details. See Native Windows support.

Before running the tasks below, use a windows-based checkout and read the skill from that branch. The task and runtime descriptions refer to that checkout, not to any older Windows source snapshot retained on main.

The lane validates that OpenShell can compile and test on Windows MSVC for the supported deliverables:

• openshell-gateway.exe
• openshell.exe
• openshell-supervisor.exe (host RFC 0012 isolation backend)
• openshell-windows-sandbox.exe (MXC ProcessContainer boundary)

It intentionally does not make Windows a Docker, Kubernetes, Podman, or VM runtime host.

The supervisor and supervisor-process libraries participate in native Windows checks and tests. Their gateway session, boundary attachment, and TCP readiness are portable; only the optional Unix SSH/readiness socket adapters are gated. This is compile and control-plane coverage, not Windows isolation qualification. Preserve readiness gating on authenticated gateway acceptance and reconnection. The supervisor process-access multiplexer consumes boundary-provided streams; do not restore local PID, PTY, or process-group operations there. Native process mechanics belong to the sandbox or isolation backend. Keep the optional Unix SSH access adapter separate from portable session orchestration. Shared Sandbox Protocol audit validation defaults to strict Linux evidence; concrete platform validators must be selected by the implementing backend.

MXC control connects outward from the boundary to a generation-scoped host loopback listener, matching the Windows relay's connection direction. Keep the reverse connector in the MXC isolation backend and share it across policy discovery and attachment. Shared transport hooks must retain pinned TLS peer verification and supervisor JWT authentication; do not change host firewall rules to repair host-to-AppContainer control connectivity.

The dedicated Windows sandbox binary links the Windows-only openshell-mxc-boundary library for process operations, containment confirmation, and loopback forwarding. The generic sandbox does not link this library and remains a Linux runtime. Do not reintroduce a dedicated supervisor-relay executable or link the compute driver into the sandbox. The supervisor remains a separate host process. Include boundary-library regression tests in native workspace tests; their real process/socket checks are not qualification of MXC enforcement.

Keep MXC audit schemas and their validators in the Windows boundary library. Register its MxcRuntimeBackend under openshell-mxc at supervisor composition. Use the private BackendSetup / PreparedBackend extension for launch decoding, policy discovery, and client construction. Shared startup must not decode the MXC descriptor or allocate its connector. Retain the same reverse-TCP connector in prepared launch state through discovery, attachment, and reconnects. It reuses the shared authenticated Sandbox Protocol, whose default Linux backend remains separate. Shared protocol code must not interpret MXC evidence.

Keep proxy provisioning in MXC-owned host-launch and one-use bootstrap envelopes. Private Windows backend setup supplies concrete listener options to shared supervisor networking. Do not add proxy hooks to BoundBoundary, proxy fields to shared Sandbox Protocol descriptors, or placeholders to other drivers. Proxy startup remains after authenticated attachment and boundary confirmation.