PoC: add named MXC execution targets

[Nikola Metulev (nmetulev)]

Description

Minimal experimental MXC provider built on the execution-target infrastructure shipped in #779. It lets multiple workers run apps in separate Windows user sessions while reusing the existing deployment, guest-agent, UI routing, and artifact-transfer code.

• --on mxc:<name> creates/reuses a named isolation session for run; target exec/push/pull use the same target. Bare mxc selects default.
• UI commands attach to an existing session and never create an empty one. A recorded but unreachable session is not silently replaced.
• target delete mxc:<name> explicitly removes that named session. It attempts to unregister development packages under its managed workspace before deleting the user.
• Separate names have separate state, workspaces, agents, and locks. Closing a CLI invocation leaves the session running.

This is a draft testing vehicle, not a production-ready provider. No documentation, generated schema, or test files are added or changed in this PR.

Usage Example

Prerequisites

Use Windows with the MXC isolation-session feature available. The native MXC executor must support schema 0.9.0-alpha. The published MXC 0.8.0 executor used in the earlier investigation does not support this request shape; the current source build still reports version 0.8.0, so identify it by commit rather than that version alone.

Validated with microsoft/mxc commit 195193f6b574d343ec435962b574dbf2e70a9fb1. Build the MXC executor from that checkout's src directory:

cargo build --locked --release -p wxc --features isolation_session --target x86_64-pc-windows-msvc

Then, from this winapp checkout:

.\scripts\build-cli.ps1 -SkipAll
$winapp = Resolve-Path .\artifacts\cli\win-x64\winapp.exe
$env:WINAPP_MXC_PATH = 'C:\src\mxc\src\target\x86_64-pc-windows-msvc\release\wxc-exec.exe'

# First use creates the named session. Later invocations reuse it.
& $winapp target exec mxc:todo -- cmd.exe /c whoami
& $winapp run .\TodoApp --on mxc:todo --detach --json
& $winapp ui inspect --on mxc:todo --app MxcTodo --json
& $winapp ui screenshot --on mxc:todo --app MxcTodo -o .\todo.png

# A second name is an independent Windows user/session.
& $winapp target exec mxc:notes -- cmd.exe /c whoami
& $winapp target snapshot mxc:notes --json

# Explicit cleanup; deleting one does not delete the other.
& $winapp target delete mxc:todo
& $winapp target delete mxc:notes

Names are normalized lowercase and accept 1–64 ASCII letters, digits, or hyphens. They are scoped to the calling Windows account on the host, not to the project directory. Use a published winapp executable rather than dotnet run, because the same self-contained executable is staged into the guest.

Packaged WinUI prerequisite on the tested build: the MXC team's traditional/full-session configuration (HKLM\SYSTEM\CurrentControlSet\Services\IsoEnvBroker\SessionConfigIdOverride, DWORD 3) was selected before starting fresh sessions. This is an administrator-controlled, machine-wide experimental setting: coordinate with the MXC team, use a test machine, and restore the original value afterward. This PR does not change that setting, deployment policies, certificates, Windows features, or feature flags automatically.

Related Issue

Related to #779 (merged execution-target foundation).

Type of Change

• ✨ New feature — experimental proof of concept

Checklist

• Tested locally on Windows
• New regression tests — intentionally deferred for this draft PoC
• User documentation/generated schema — intentionally deferred for this draft PoC

Screenshots / Demo

Live CLI/OS checks completed with the locally built PoC:

• Two named targets were alive simultaneously with distinct Windows users/session IDs. Repeated commands reused the selected session; deleting one left the other usable.
• A real self-contained packaged WinUI 3 todo app launched through run --on mxc:todo; routed UI inspection, text setting, add/complete actions, and screenshot retrieval succeeded.
• The same signed MSIX was installed using native Add-AppxPackage -Path through target exec for both concurrent users; both registrations reported IsDevelopmentMode=false.
• Unknown-target UI commands failed without provisioning a session.
• Temporary users, packages, registry configuration, and test-certificate trust were cleaned up afterward.

Validation: x64 and ARM64 NativeAOT publication via scripts\build-cli.ps1 -SkipAll; 297 existing focused target/process/sandbox-run tests passed, with no failures or skips. npm's local binaries were refreshed from those publish outputs. Independent focused code review found no significant issues. CI is separate and has not yet been established by these local results.

Additional Notes

• MXC isolation sessions share the host OS and have unrestricted networking. This is not VM isolation and is not presented as a security boundary.
• Current-host platform limitations remain visible: native default-session development registration still returns 0x80073D23; packaged activation-manager creation still returns 0x80040154. Full-session real keyboard input still encounters foreground_not_target; the input safety check is not disabled and no shell-termination workaround is included.
• Loose developer-mode package families are restricted to one user on a machine. Named sessions do not remove that Windows restriction. The successful signed-MSIX comparison does not establish support for simultaneous different versions/builds sharing one identity.
• The PoC does not download MXC or upgrade a running agent. After changing the winapp binary, explicitly delete/recreate the named target. Interrupted bootstrap state is retained for targeted cleanup rather than silently creating another user.
• target delete tears down the whole selected environment, including its running apps. Arbitrary packages installed with target exec are not tracked by winapp; explicitly remove those packages before deleting the session when testing package-cleanup behavior.
• No production session pool, automatic eviction, global current-target selection, or GUI viewer is included.

[github-actions]

Build Metrics Report

Validation did not pass. Artifacts were uploaded before validation finished; check the workflow run before using them.

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	57.29 MB	57.39 MB	📈 +104.5 KB (+0.18%)
CLI (x64)	57.33 MB	57.43 MB	📈 +103.0 KB (+0.18%)
MSIX (ARM64)	23.79 MB	23.84 MB	📈 +52.7 KB (+0.22%)
MSIX (x64)	25.26 MB	25.31 MB	📈 +44.2 KB (+0.17%)
NPM Package	49.63 MB	49.71 MB	📈 +76.5 KB (+0.15%)
NuGet Package	49.74 MB	49.82 MB	📈 +80.2 KB (+0.16%)

.NET Test Results (TRX reports)

Other suites are reflected in the overall validation status above.

✅ 7879 passed, 37 skipped out of 7916 tests in 1344.1s (+263.1s vs. baseline)

Test Coverage

✅ 85.8% line coverage, 80.5% branch coverage · ⚠️ -0.5% vs. baseline

CLI Startup Time

59ms median (x64, winapp --version) · ✅ -9ms vs. baseline

Try This Build

Installs the MSIX for your architecture, replacing any previously installed build. Needs the GitHub CLI — the command offers to install it and sign you in if it is missing.

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) 937

Switching between builds often?

Put the tool on your PATH once:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/microsoft/winappCli/main/scripts/winapp-pr.ps1))) -AddToPath

Then this build is just:

winapp-pr 937

Run winapp-pr with no arguments to pick from a list of open PRs.

---

Updated 2026-09-25 03:06:33 UTC · commit 439ccf3 · workflow run

[Howard Kapustein (DrusTheAxe)]

--on mxc:

--on is a new parameter, but it's rather confusing.

RECOMMEND: Drop the --on prefix and make it --mxc:<name> (or --mxc <name>, whatever the typical syntax)