feat(mxc): add UI policy, credentials, relay lifecycle, and proxy auth

.agents/skills/build-openshell-mxc-windows/SKILL.md

@@ -17,6 +17,7 @@ Windows MSVC for the supported deliverables:
 
 - `openshell-gateway.exe`
 - `openshell.exe`
+- `openshell-supervisor-relay.exe` (Windows-only MXC workload relay)
 
 It intentionally does not make Windows a Docker, Kubernetes, Podman, or VM
 runtime host.
@@ -115,7 +116,7 @@ The lane targets a Windows host with Visual Studio Build Tools and rustup.
 | Visual C++ ARM64 tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Tools.ARM64 -property installationPath` | Required for native ARM64 check, build, and tests and for x64-to-ARM64 check/build. Tests always require a native runner. |
 | Visual C++ ARM64 Spectre-mitigated libraries | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Runtimes.ARM64.Spectre -property installationPath` | Required by `regorus` through `msvc_spectre_libs`; the build fails when the selected MSVC toolset lacks `lib\spectre\arm64`. |
 | Visual C++ Clang tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.Llvm.Clang -property installationPath` | Provides host-native `libclang.dll` for `bindgen` and `clang-cl.exe` for ARM64 crypto dependencies such as `aws-lc-sys`. On ARM64, the wrapper uses `VC\Tools\Llvm\Arm64\bin`. |
-| Visual C++ CMake tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.CMake.Project -property installationPath` | Provides CMake and Ninja for bundled Z3 and other native dependencies. The x64-to-ARM64 path adds Ninja to `PATH`; Z3 uses MSVC's Visual Studio generator. |
+| Visual C++ CMake tools | `vswhere -latest -products * -requires Microsoft.VisualStudio.Component.VC.CMake.Project -property installationPath` | Provides CMake and Ninja for native dependencies. The x64-to-ARM64 path adds Ninja to `PATH`; Z3 uses an architecture-specific prebuilt release. |
 | Windows SDK | `where.exe rc.exe` from a Developer PowerShell | Install an SDK containing target libraries and ARM64 tools. |
 | Rust via rustup | `rustc --version` | Add each target being validated: `x86_64-pc-windows-msvc` and/or `aarch64-pc-windows-msvc`. The wrapper also adds the selected target. |
 | mise | `mise --version` | Used as a task runner only. |
@@ -135,6 +136,8 @@ from this skill.
 | `CARGO_TARGET_DIR` | `target` under repo root | Override Cargo output location. Use a short absolute path when x64-to-ARM64 builds approach Windows path-length limits. |
 | `Z3_LIBRARY_PATH_OVERRIDE` | unset | Directory containing an x64 system `libz3.lib`; not valid for ARM64. |
 | `Z3_SYS_Z3_HEADER` | unset | Full `z3.h` path required with a system Z3 library. |
+| `Z3_SYS_Z3_VERSION` | `4.16.0` | Pinned official prebuilt Z3 release selected by the wrapper. |
+| `READ_ONLY_GITHUB_TOKEN` | unset | Optional token for the Z3 release lookup; GitHub Actions supplies `github.token`. |
 | `RUSTC_WRAPPER` | inherited | The wrapper resolves an available command to an absolute path. If it is unavailable, the wrapper warns and continues without compiler caching. |
 
 Legacy fork variables such as `OPENSHELL_UPSTREAM`,
@@ -155,6 +158,16 @@ mise run --skip-tools windows:test:x64
 mise run --skip-tools windows:test:unsupported:x64
 ```
 
+The two `windows:test:mxc-real:*` tasks are host-specific and mutually
+exclusive on a single host (each rejects the other architecture -- see the
+table below): run `windows:test:mxc-real:x64` on an x64 host, or
+`windows:test:mxc-real:arm64` on an ARM64 host, as part of validating this
+subsystem -- run the one matching your host architecture, not both, and not
+neither. Both are skip-safe (they print a SKIP reason and exit 0 when
+`wxc-exec` or the matching backend isn't available), so running the
+arch-appropriate task is always safe even without real MXC hardware. Neither
+is part of `windows:ci`'s ordered contract, so invoke it explicitly.
+
 For full validation, detect the Windows host architecture first and choose the
 native lane dynamically:
 
@@ -163,12 +176,14 @@ $arch = [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
 switch ($arch.ToString()) {
     "X64" {
         mise run --skip-tools windows:ci
+        mise run --skip-tools windows:test:mxc-real:x64
     }
     "Arm64" {
         mise run --skip-tools windows:check:arm64
         mise run --skip-tools windows:build:arm64
         mise run --skip-tools windows:test:arm64
         mise run --skip-tools windows:test:unsupported:arm64
+        mise run --skip-tools windows:test:mxc-real:arm64
         mise run --skip-tools windows:artifacts
     }
     default {
@@ -203,8 +218,7 @@ jobs in the current mirror push run, or push a new mirrored commit. The binaries
 The ARM64 check/build steps in this x64-host contract are cross-builds. The
 wrapper discovers and adds host-native LLVM and Ninja to `PATH`, requires the
 ARM64 compiler and Spectre-mitigated libraries, lets ARM64 crypto crates select
-`clang-cl`, and builds bundled Z3 with native MSVC `cl.exe` and the Visual
-Studio generator.
+`clang-cl`, and downloads the official prebuilt ARM64 Z3 static library.
 
 On ARM64 hosts, validate the native ARM64 check, build, and test path. The
 wrapper rejects test targets that do not match the host architecture, so x64
@@ -241,6 +255,8 @@ crypto dependency builds.
 | `windows:test:arm64` | Runs native ARM64 workspace tests with `--no-fail-fast` and the same package exclusions. Rejects non-ARM64 hosts. |
 | `windows:test:unsupported:x64` | Re-runs focused `openshell-gateway` tests for unsupported Windows driver behavior. |
 | `windows:test:unsupported:arm64` | Re-runs the same focused contracts natively on ARM64. Rejects non-ARM64 hosts. |
+| `windows:test:mxc-real:x64` | Runs the serial, ignored real-`wxc-exec` integration suite natively on x64 through the MSVC wrapper. Rejects non-x64 hosts. |
+| `windows:test:mxc-real:arm64` | Runs the same real-`wxc-exec` suite natively on ARM64. Rejects non-ARM64 hosts. |
 | `windows:artifacts` | Reports size and SHA256 for release artifacts that exist. |
 | `windows:ci` | Runs the full ordered x64-host Windows CI lane, plus ARM64 check/build when not skipped. |
 
@@ -310,13 +326,16 @@ Useful log files:
 | `test-aarch64-pc-windows-msvc.log` | Full native ARM64 workspace test output. |
 | `test-x86_64-pc-windows-msvc-unsupported-*.log` | Focused unsupported-driver contract output. |
 | `test-aarch64-pc-windows-msvc-unsupported-*.log` | Focused native ARM64 contract output. |
-
-The first check builds bundled Z3 from source through `z3-sys`. Cargo stores the
-native build output in its target tree, so the Windows target cache reuses it.
-The resulting release executables do not require `libz3.dll`. The artifact
-report computes SHA256 through .NET directly and does not rely on the
-`Get-FileHash` module being available inside the mise-launched Windows
-PowerShell process.
+| `test-x86_64-pc-windows-msvc-mxc-real.log` | Native x64 real-MXC integration output. |
+| `test-aarch64-pc-windows-msvc-mxc-real.log` | Native ARM64 real-MXC integration output. |
+
+The first check downloads the pinned official Z3 archive for the target
+architecture through `z3-sys`. GitHub Actions authenticates the lookup with its
+read-only workflow token; local users can set `READ_ONLY_GITHUB_TOKEN` if an
+unauthenticated lookup is rate-limited. Cargo stores the extracted library in
+its target tree, so the Windows target cache reuses it. The artifact report
+computes SHA256 through .NET directly and does not rely on the `Get-FileHash`
+module being available inside the mise-launched Windows PowerShell process.
 
 ## Common Fix Patterns
 

.agents/skills/build-openshell-mxc-windows/reference.md

@@ -68,11 +68,11 @@ file.
 For ARM64, verify the Visual Studio instance contains the ARM64 MSVC tools,
 ARM64 Spectre-mitigated libraries, Clang tools, CMake tools, and a Windows SDK.
 Clang supplies host-native `libclang.dll` for `bindgen` and `clang-cl.exe` for
-ARM64 crypto dependencies such as `aws-lc-sys`. Native builds use the normal
-bundled-Z3 CMake path. An x64-to-ARM64 check/build discovers and adds
-host-native Ninja to `PATH`, builds bundled Z3 with native MSVC `cl.exe` and
-the Visual Studio generator, and lets the crypto crates select `clang-cl`. Use
-a short `CARGO_TARGET_DIR` if Windows path-length limits are reached.
+ARM64 crypto dependencies such as `aws-lc-sys`. Native and x64-to-ARM64 builds
+use the official prebuilt Z3 4.16.0 static library for the target architecture.
+An x64-to-ARM64 check/build discovers and adds host-native Ninja to `PATH`,
+while the crypto crates select `clang-cl`. Use a short `CARGO_TARGET_DIR` if
+Windows path-length limits are reached.
 
 ## Unsupported Driver Rules
 

.github/workflows/windows-msvc.yml

@@ -56,6 +56,7 @@ jobs:
             rust_target: aarch64-pc-windows-msvc
     runs-on: ${{ matrix.runner }}
     env:
+      READ_ONLY_GITHUB_TOKEN: ${{ github.token }}
       SCCACHE_GHA_ENABLED: "true"
       SCCACHE_GHA_VERSION: windows-msvc-${{ matrix.arch }}
       SCCACHE_CLIENT_SIDE: "1"
@@ -121,6 +122,7 @@ jobs:
             rust_target: aarch64-pc-windows-msvc
     runs-on: ${{ matrix.runner }}
     env:
+      READ_ONLY_GITHUB_TOKEN: ${{ github.token }}
       SCCACHE_GHA_ENABLED: "true"
       SCCACHE_GHA_VERSION: windows-msvc-${{ matrix.arch }}
       SCCACHE_CLIENT_SIDE: "1"
@@ -178,6 +180,7 @@ jobs:
             rust_target: aarch64-pc-windows-msvc
     runs-on: ${{ matrix.runner }}
     env:
+      READ_ONLY_GITHUB_TOKEN: ${{ github.token }}
       SCCACHE_GHA_ENABLED: "true"
       SCCACHE_GHA_VERSION: windows-msvc-${{ matrix.arch }}
       SCCACHE_CLIENT_SIDE: "1"

AGENTS.md

@@ -59,6 +59,7 @@ These pipelines connect skills into end-to-end workflows. Individual skill files
 | `crates/openshell-driver-podman/` | Podman compute driver | In-process `ComputeDriver` backend for local Podman sandbox containers |
 | `crates/openshell-driver-vm/` | VM compute driver | Standalone libkrun-backed `ComputeDriver` subprocess (embeds its own rootfs + runtime) |
 | `crates/openshell-driver-mxc/` | Microsoft MXC compute driver | In-process Windows AppContainer and isolation-session compute backend |
+| `crates/openshell-supervisor-relay/` | MXC supervisor relay | **Windows-only** standalone binary the MXC driver spawns inside a ProcessContainer/isolation session in place of `agent_command`; launches the real target process, exposes a JSON control channel (launch/shutdown/forward) over its own inherited stdin/stdout, and bridges dynamic TCP forwards (`openshell forward service`) to it |
 | `crates/openshell-prover/` | Policy prover | Policy verification and proof generation |
 | `crates/openshell-server-macros/` | Server macros | Compile-time helpers for gateway RPC authorization |
 | `crates/openshell-supervisor-middleware/` | Middleware runtime | Generic middleware registry, remote service integration, and chain execution |

CONTRIBUTING.md

@@ -340,14 +340,19 @@ cargo build -p openshell-prover --features bundled-z3
 
 For x86-64 and ARM64 Windows MSVC builds, use one of these Z3 paths:
 
-- Bundled Z3 (the default for `windows:*` tasks): `z3-sys` builds Z3 from
-  source and links it into the OpenShell binaries. This keeps the release
-  executables independent of `libz3.dll` when they are copied to another host.
+- Prebuilt Z3 (the default for `windows:*` tasks): `z3-sys` downloads the
+  pinned Z3 4.16.0 GitHub release for the target architecture on the first
+  build. Cargo reuses the extracted archive from its target directory. Windows
+  CI authenticates the GitHub API request with `READ_ONLY_GITHUB_TOKEN` and
+  preserves the archive in the architecture-specific Cargo target cache. For
+  cold local builds, you may set `READ_ONLY_GITHUB_TOKEN` to avoid anonymous
+  GitHub API rate limits.
 - System Z3: point `Z3_LIBRARY_PATH_OVERRIDE` at the directory containing the
-  target-compatible MSVC Z3 library and `Z3_SYS_Z3_HEADER` at the full path to
-  `z3.h`. The `windows:*` tasks use this path automatically when
-  `Z3_LIBRARY_PATH_OVERRIDE` is set. Deploy the matching `libz3.dll` with any
-  binaries built against a dynamic system Z3.
+  target-compatible MSVC Z3 library and `Z3_SYS_Z3_HEADER` at the full path to `z3.h`.
+  The `windows:*` tasks use this path automatically when `Z3_LIBRARY_PATH_OVERRIDE`
+  is set.
+- Bundled Z3: for direct Cargo builds, pass `--features bundled-z3` so `z3-sys`
+  builds Z3 from source.
 
 `openshell-prover` itself has no `bindgen`/`libclang` dependency, so building
 just this crate does not require `LIBCLANG_PATH`:
@@ -360,17 +365,17 @@ cargo build -p openshell-prover --target x86_64-pc-windows-msvc --features bundl
 
 To build the full set of Windows binaries, including `openshell-gateway.exe`
 and `openshell.exe`, use the `windows:build:x64` mise task instead of a
-single-crate `cargo build`. It builds Z3 from source (bundled) by default. A full
-build also compiles crates that use `bindgen` (e.g. the MXC driver on Windows),
-so it requires `libclang.dll`; if LLVM is not on the default search path, set
-`LIBCLANG_PATH` to the directory containing `libclang.dll`:
+single-crate `cargo build`. It downloads the pinned prebuilt Z3 release by default. A
+full build also compiles crates that use `bindgen` (e.g. the MXC driver on
+Windows), so it requires `libclang.dll`; if LLVM is not on the default search
+path, set `LIBCLANG_PATH` to the directory containing `libclang.dll`:
 
 ```powershell
 $env:LIBCLANG_PATH='C:\Program Files\Microsoft Visual Studio\2022\<Edition>\VC\Tools\Llvm\x64\bin'
 mise run --skip-tools windows:build:x64
 ```
 
-To use a local x64 Z3 release instead of the bundled build, set
+To use a local x64 Z3 release instead of the prebuilt download, set
 `Z3_LIBRARY_PATH_OVERRIDE` and `Z3_SYS_Z3_HEADER` before running the task:
 
 ```powershell

architecture/compute-runtimes.md

@@ -32,8 +32,8 @@ launches and monitors the policy-constrained workload itself.
 
 `compute_driver.proto` is the supported gateway/driver extension boundary.
 At initialization the gateway snapshots the driver's identity, version,
-default image, gateway-lifecycle preference, and
-`driver_reports_runtime_readiness` from `GetCapabilities`. The gateway includes
+default image, gateway-lifecycle preference, runtime-readiness ownership, and
+complete UI-policy enforcement support from `GetCapabilities`. The gateway includes
 the canonical `SandboxPolicy` in `DriverSandboxSpec.policy` for validation and
 creation. Drivers that enforce policy outside the standard supervisor fetch
 later revisions through `GetSandboxConfig` and acknowledge them through
@@ -106,6 +106,18 @@ The capability RPC reports driver identity, version, and the default sandbox
 image used by the gateway. GPU availability stays driver-local and is validated
 when a sandbox create request asks for GPU resources.
 
+UI policy is capability-negotiated at the configured driver-instance boundary.
+`supports_ui_policy = true` means the driver completely enforces every field in
+the current portable `SandboxPolicy.ui` contract; partial implementations must
+report false. When `ui` is explicitly present, including as `{}`, the gateway
+rejects create before the driver validation RPC or provisioning unless this
+capability is true. An absent section bypasses this gate and preserves the
+runtime's existing behavior. The startup snapshot is also exposed through
+gateway info so clients can discover the selected runtime's support. UI cannot
+be supplied by a gateway-global policy because it is applied at startup. When a
+global dynamic policy is active, effective-policy reads retain the UI block from
+the sandbox's creation policy.
+
 The gateway records driver identity and version from the startup capability
 response. Elevated gateway info reports that initialized driver snapshot instead
 of re-querying drivers on each request.
@@ -156,6 +168,20 @@ in-tree driver cannot silently depend on a server-only API.
 
 ## Stop and Start Lifecycle
 
+On Windows, the MXC driver can wrap the workload in
+`openshell-supervisor-relay`. Its inherited stdin/stdout control channel carries
+the launch environment, shutdown requests, and multiplexed dynamic forwards.
+The gateway accepts driver-reported readiness only after the configured target
+port is reachable. Stop/delete interrupt readiness waits and await process
+termination; they must not publish success while owned processes remain.
+
+With governed egress enabled, MXC denies direct Internet access and allows
+host loopback. Proxy-aware workloads receive per-sandbox authenticated
+`HTTP_PROXY`/`HTTPS_PROXY` URLs and public CA trust material. The host CONNECT
+proxy enforces OpenShell network policy, but this configuration does not isolate
+unrelated host-loopback services. See the MXC driver README for compatibility
+settings and the remaining policy limitations.
+
 The gateway persists lifecycle intent before mutating compute:
 
 ```text

architecture/gateway.md

@@ -347,6 +347,12 @@ Public RPC contracts and durable protobuf formats have separate ownership. The `
 
 `ReportEndpointStatus` is a sandbox-authenticated public gateway RPC. Its request, response, and `EndpointObservation` messages belong only to the public closure. `EndpointStatus` and `EndpointResult` also belong to the durable closure because `Sandbox.status.endpoint_statuses` persists them. The repeated status field uses a new wire tag; stored sandboxes without it decode with an empty endpoint list and retain their lifecycle fields. A fixed payload encoded with the earlier sandbox schema verifies that no database rewrite is required.
 
+`DeleteSandboxRequest` adds optional identity and resource-version preconditions
+at tags 4 and 5; the workspace selector retains tag 3. Omitted preconditions
+preserve existing deletion behavior. Matching clients and servers are required
+when relying on these checks: an older server can ignore unknown fields. These
+request-only additions do not change any durable storage payload.
+
 The removed `NetworkBinary.harness` field remains reserved by number and name,
 so protobuf implementations cannot reuse its wire slot or source identifier.
 The durable-policy compatibility decoder reads the former boolean before Prost
@@ -622,9 +628,11 @@ leave an ambiguous final dynamic-token state or a deleted custom profile that is
 still referenced by a sandbox.
 
 Policy and runtime settings are delivered together through the effective sandbox
-config path. A gateway-global policy can override sandbox-scoped policy. The
-sandbox supervisor polls for config revisions and hot-reloads dynamic policy
-when the policy engine accepts the update.
+config path. A gateway-global policy can override sandbox-scoped dynamic policy.
+Startup-only UI remains anchored to each sandbox's creation policy, and global
+policy writes containing UI are rejected. The sandbox supervisor polls for
+config revisions and hot-reloads dynamic policy when the policy engine accepts
+the update.
 
 External supervisor middleware registration is operator-owned configuration
 under `[[openshell.supervisor.middleware]]`. At startup the gateway connects to