MSIX distribution hardening: AppInstaller updates and packaged setup launch

[indierawk2k2]

Simplifies the MSIX packaging PR while keeping the AppInstaller work:

• Restores the legacy Inno installer, portable ZIP, and Updatum release surfaces so this PR adds MSIX/AppInstaller without sunsetting existing distribution.
• Moves the tray MSIX to framework-dependent Windows App SDK packaging and publishes the matching Microsoft.WindowsAppRuntime.2 framework packages as AppInstaller dependencies.
• Fixes packaged first-run setup launch: SetupEngine is copied as a child payload, published framework-dependent with WindowsAppSdkBootstrapInitialize=false, XAML resources are injected after packaging, and the tray launches it directly with UseShellExecute=false.
• Keeps release signing/verification for both outer MSIX packages and inner executable/script payloads.

Validation completed locally:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Real x64 Add-AppxPackage -Path install/launch validation with trusted test cert: tray launched and SetupEngine showed OpenClaw Setup.

Fresh fork test release assets are available at:
https://github.com/indierawk2k2/openclaw-windows-node/releases/tag/msix-production-feed-test-2026-05-27

[indierawk2k2]

Coverage gap found during PR creation flow — addressed in commit 9fdf999

Two new ghost Terminal frames appeared during the gh pr create invocation that opened this PR. Investigation:

Default terminal app on Win11 (the new default since 24H2) is Windows Terminal:

\
HKCU\Console%%Startup\DelegationConsole = {2EACA947-7F5F-4CFA-BA87-8F7FBEEFBE69} # Windows Terminal CLSID
\\

That means every console-spawning child process — gh, git, dotnet, fresh pwsh sessions, agent-driven tool invocations — allocates a Cascadia hosting frame. Most close cleanly when the child exits; a small fraction leak under timing conditions.

The cleanup we already shipped only fires from triggers we wired:

1. testhost lifetime (WinAppSdkGhostWindowCleanup [ModuleInitializer] + xUnit before/after attribute)
2. build.ps1 end-of-build hook

gh pr create matches neither. So those two ghosts were structurally outside our coverage — not a logic bug, a coverage gap.

Fix (commit 9fdf999)

Added two new modes to scripts/cleanup-ghost-windows.ps1 for sessions where the wired triggers aren't enough:

• -Daemon [-PollSeconds N] — foreground watcher (default 30s, range 5..3600). Use when you're about to do a lot of shell work; Ctrl+C to stop.
• -InstallScheduledTask — registers a hidden 5-minute task under the current user (no admin needed, idempotent). Uninstall with -UninstallScheduledTask.

Validated install/uninstall round-trip on the test box. Filter logic, close-message sequence, and the 1000×500 safety guard are unchanged — only invocation modes are new.

AGENTS.md updated to explicitly call out the Win11-default-terminal-app trigger and the new escalation paths. GhostWindowCleanupScriptContractTests gains 5 new assertions pinning all four switch names and the scheduled-task name.

Where this leaves the PR

The PR can't fix the underlying Windows Terminal / ConPTY leak (that's a Microsoft-owned bug). What it can do — and now does — is ship a thorough recovery story across the full leak surface:

Source of ghost	Caught by
Tray test process lifetime	WinAppSdkGhostWindowCleanup (in-process)
msbuild MSIX packaging	build.ps1 end-of-build hook
gh / git / ad-hoc shell work	-Daemon or -InstallScheduledTask (developer opt-in)
Killed-with-Ctrl+C testhost	One-shot scripts/cleanup-ghost-windows.ps1 (manual)
CI runner	CI VMs are ephemeral; build.ps1 hook keeps the runner clean for the job's lifetime

Validation after the fix: ./build.ps1 OK, Shared.Tests 1776 / 28 skipped, Tray.Tests 1144 passed (+5). PR is now at 15 commits.

Recommendation for reviewers / your collaborator who's about to do heavy shell work on this branch: ./scripts/cleanup-ghost-windows.ps1 -InstallScheduledTask once, then forget about it (or use -Daemon for the duration of a single session).

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed May 28, 2026, 1:58 AM ET / 05:58 UTC.

Summary
The PR adds MSIX/AppInstaller release/feed automation, packaged SetupEngine launch support, payload signing/verification, MSIX recovery scripts, and related docs/tests while preserving the existing installer and portable release channels.

Reproducibility: yes. for the review finding: source inspection shows the packaged manual-update branch returns before the existing dialog-rendering switch runs. The broader distribution behavior still needs real Windows proof for the signed release paths.

Review metrics: 3 noteworthy metrics.

• Changed Surface: 55 files, +4891/-363. The patch spans release automation, app runtime behavior, manifests, scripts, docs, and tests, so maintainers should treat it as a distribution change rather than a narrow code fix.
• Workflow Surface: 1 workflow added, 1 workflow changed. Release and feed automation changes can affect signing, published assets, and automatic client updates outside normal unit-test coverage.
• Validation Scripts: 8 scripts added, 1 script changed, 1 script removed. The release process now depends on new PowerShell packaging, signing, rendering, validation, and smoke-test scripts.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦐 gold shrimp
Patch quality: 🦐 gold shrimp
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Show visible packaged update-check results for Current, Failed, Available, and Ready states.
• Post current-head proof for signed AppInstaller install/update/uninstall and ARM64 behavior, with private data redacted.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR has useful x64 install/setup-launch logs, but it still needs current-head proof for signed AppInstaller update/uninstall and ARM64 install/update behavior; redact private data before posting proof. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] Packaged users can still see no obvious response from the tray-menu update check when the AppInstaller feed is current, unavailable, invalid, or failed because the packaged branch only updates AppState and returns.
• [P1] The branch changes install, first-launch setup, signing, AppInstaller feed, and stable-feed automation behavior that normal unit tests cannot fully validate.
• [P1] The proof is strong for iterative x64 setup-launch debugging, but it does not yet cover current-head signed AppInstaller update/uninstall behavior or ARM64 install/update behavior.

Maintainer options:

1. Fix Packaged Update Feedback First (recommended)
   Add a visible packaged AppInstaller result surface for Current, Failed, Available, and Ready outcomes before merging.
2. Accept Release-Path Risk Deliberately
   Maintainers can choose to land with the current proof gap only if they explicitly own follow-up validation for signed AppInstaller update/uninstall and ARM64 behavior.
3. Pause Until Full Matrix Proof
   Keep the draft paused until the contributor posts current-head proof for the signed AppInstaller install, update, uninstall, and ARM64 paths.

Next step before merge

• [P1] Human review is needed because contributor real-behavior proof and release-path signoff remain required even though the update-feedback code defect is narrow.

Security
Cleared: Security-sensitive packaging and signing surfaces were inspected; no concrete secret leak or supply-chain vulnerability was found, though maintainer release-path review remains important.

Review findings

• [P1] Show a result for packaged update checks — src/OpenClaw.Tray.WinUI/App.xaml.cs:3611-3614

Review details

Best possible solution:

Land the MSIX/AppInstaller work only after packaged update checks surface explicit results and maintainers have current-head proof for the signed install/update/uninstall paths on the supported architectures.

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

Yes for the review finding: source inspection shows the packaged manual-update branch returns before the existing dialog-rendering switch runs. The broader distribution behavior still needs real Windows proof for the signed release paths.

Is this the best way to solve the issue?

No: the packaging direction may be right, but the packaged update-check path should reuse or add an explicit visible result surface instead of only mutating AppState.

Full review comments:

• [P1] Show a result for packaged update checks — src/OpenClaw.Tray.WinUI/App.xaml.cs:3611-3614
  For packaged builds this returns immediately after CheckForPackagedAppInstallerUpdateAsync(), so the existing Current/Failed dialog handling below never runs. A tray-menu click can still appear to do nothing when the feed is current, 404s, is invalid, or otherwise fails unless the user already has a status-observing hub surface open.
  Confidence: 0.88

Overall correctness: patch is incorrect
Overall confidence: 0.84

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6a5921883c86.

Label changes

Label justifications:

• P2: This is significant Windows distribution work with limited blast radius to install/update paths and no active emergency signal.
• merge-risk: 🚨 compatibility: The PR changes MSIX install/update behavior and release assets while preserving legacy installer and portable channels.
• merge-risk: 🚨 security-boundary: The diff touches MSIX full-trust capabilities, startup task registration, toast COM activation, inner payload signing, and release credentials.
• merge-risk: 🚨 availability: A bad package, runtime dependency, SetupEngine launch, or AppInstaller feed can leave the tray or first-run setup unavailable after install.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR has useful x64 install/setup-launch logs, but it still needs current-head proof for signed AppInstaller update/uninstall and ARM64 install/update behavior; redact private data before posting proof. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.

What I checked:

• Repository policy read: AGENTS.md was read fully; its validation requirements and Windows-node guidance were treated as review policy, while build/tests were not run because this review is read-only. (AGENTS.md:1, 6a5921883c86)
• Packaged update path skips visible dialogs: The packaged branch in CheckForUpdatesUserInitiatedAsync awaits CheckForPackagedAppInstallerUpdateAsync and returns before the existing Current/Failed dialog switch runs. (src/OpenClaw.Tray.WinUI/App.xaml.cs:3611, e697b5be95a2)
• Tray menu exposes the affected action: The tray menu routes the Check for Updates action directly to CheckForUpdatesUserInitiatedAsync, so this can be hit without any status-observing hub page open. (src/OpenClaw.Tray.WinUI/Services/TrayMenuStateBuilder.cs:308, e697b5be95a2)
• Existing feedback behavior provenance: Current main's manual update feedback path was introduced around commit f3d3fd2, which added user feedback to Check for Updates; the PR's packaged branch bypasses that same result-dialog pattern. (src/OpenClaw.Tray.WinUI/App.xaml.cs:3542, f3d3fd2772f3)
• Release and packaging surface inspected: The diff touches release workflows, AppInstaller feed generation, MSIX signing, SetupEngine packaging, manifests, update services, and recovery CLI behavior across 55 files. (e697b5be95a2)
• Proof discussion reviewed: The PR body and comments include useful x64 Add-AppxPackage/setup-launch validation and fork release assets, but the current-head proof still does not cover the signed AppInstaller update/uninstall path and ARM64 install/update behavior. (e697b5be95a2)

Likely related people:

• Regis Brid: Git blame and -S history tie the existing manual Check for Updates result-dialog behavior to commit f3d3fd2, which is the path the PR bypasses for packaged builds. (role: introduced current update-feedback behavior; confidence: high; commits: f3d3fd2772f3; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)
• ranjeshj: Current main history shows recent work on SetupEngine and CI release/signing surfaces that overlap the MSIX packaging and setup-launch changes. (role: recent setup and release-area contributor; confidence: high; commits: cefce3952ab1, ed126f2aac6d, 6bd98858e618; files: src/OpenClaw.SetupEngine.UI/Program.cs, .github/workflows/ci.yml)
• shanselman: Current history shows adjacent signing and App.xaml.cs work, making this a reasonable routing candidate for release-surface review. (role: adjacent release/signing contributor; confidence: medium; commits: bd21cd9c547c, 0d4fcbd50ad5; files: .github/workflows/ci.yml, src/OpenClaw.Tray.WinUI/App.xaml.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.

[indierawk2k2]

Round 10 local-loop update — setup autolaunch now survives locally

What changed in 207aadf:

• kept the Round 9/master-compatible direct launch path (SetupEngine\OpenClaw.SetupEngine.UI.exe), no packaged SetupEngine PRAID/AUMID;
• set the SetupEngine child process working directory to its payload folder;
• explicitly calls WindowsAppRuntime_EnsureIsLoaded() before WinUI startup;
• kept bounded Application.Start retry breadcrumbs for 0x80040111 / 0x80004005 XAML factory failures;
• bypassed the native XAML load crash by building the setup window shell and Welcome page in code instead of calling SetupWindow.InitializeComponent() / WelcomePage.InitializeComponent().

Local evidence:

• Direct self-contained SetupEngine crashed at SetupWindow.InitializeComponent.
• Code-built SetupWindow moved the crash to WelcomePage.InitializeComponent.
• Code-built WelcomePage made direct SetupEngine stay alive.
• Iter9 loose-package loop launched the tray, the tray auto-launched SetupEngine\OpenClaw.SetupEngine.UI.exe, and both processes stayed alive. setup-engine-startup.log reached SetupWindow.ctor.afterWelcomeNavigate and App.OnLaunched.afterBringToFront.

Validation:

• ./build.ps1 passed
• Shared tests: 1958 passed / 29 skipped
• Tray tests: 911 passed

Quick remote-test artifact:

• Uploaded red x64 MSIX to the existing fork release msix-red-blue-feed-test-2026-05-22
• Asset: OpenClawCompanion-red-0.4.90.0-win-x64.msix
• SHA256: 825EAB38F5337CE10BABB886EE704A5F1A30FDA52CDA8EED99C51D620D8EAD36

Caveat: local command-line install with Add-AppxPackage -Path is still blocked on this box by local-machine certificate trust/elevation, so the local loop used loose package registration plus direct tray launch. That was enough to reproduce and then fix the SetupEngine crash path; the uploaded MSIX is for the dev box to confirm the real signed install/autolaunch path.

[indierawk2k2]

Round 10 — setup launches! 🎉 Two follow-ups: (1) the "explanation dialog" isn't a bug, it's a UX choice; (2) page-2 crash is CapabilitiesPage.InitializeComponent() — same root cause as Round 1 but the workaround in commit 207aadfd was only half-applied

Excellent progress this round — confirmed that the Tray launches successfully, SetupEngine.UI launches via direct Process.Start (master pattern), and the Welcome page renders cleanly. Build hashes: Tray D6DE2DC5…F96E689, SetupEngine A9F1ADC4…3EB2B147, package 382 MB with full self-contained SetupEngine\ subfolder back at 223 MB.

The two new issues are both well-scoped now.

---

Issue #1 — the "explanation dialog" on the easy button (not actually a bug, but a UX choice to make)

Source: src/OpenClaw.SetupEngine.UI/Pages/WelcomePage.xaml.cs StartButton_Click. Fetched verbatim from PR head:

private async void StartButton_Click(object sender, RoutedEventArgs e)
{
    var dataDir = Environment.GetEnvironmentVariable("OPENCLAW_TRAY_DATA_DIR")
        ?? Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "OpenClawTray");

    var existing = ExistingConfigDetector.Detect(dataDir, _config!.DistroName);
    var summary = ExistingConfigDetector.BuildReplacementSummary(existing);

    var dialog = new ContentDialog
    {
        Title = existing.HasLocalGateway || existing.HasDistro
            ? "Replace existing WSL gateway?"
            : "Install a new WSL gateway?",
        Content = summary,
        PrimaryButtonText = "Continue",
        CloseButtonText = "Cancel",
        DefaultButton = ContentDialogButton.Close,
        XamlRoot = XamlRoot,
    };

    var result = await dialog.ShowAsync();              // ← unconditional
    if (result == ContentDialogResult.Primary)
        App.MainWindow?.NavigateToCapabilities();
}

dialog.ShowAsync() is unconditional — there's no if (existing.HasLocalGateway || existing.HasDistro) ShowAsync(); else NavigateToCapabilities(); guard. The detector result only changes the title string (and the summary content text). On a fresh machine the dialog still appears with:

Field	Value on fresh machine
Title	Install a new WSL gateway?
Content	A new local WSL gateway will be created. No existing configuration will be affected.
Primary button	Continue
Cancel button	Cancel
DefaultButton	Close (Enter dismisses, surprising)

Verified on the test machine — fresh state, both detector predicates definitely false:

Check	Test box state	Detector result
File.Exists("%APPDATA%\OpenClawTray\gateways.json")	%APPDATA%\OpenClawTray directory absent entirely	HasLocalGateway = false
wsl --list --quiet contains OpenClawGateway	wsl --list --quiet returns empty; HKCU\…\Lxss has no DistributionName entries; tray log shows [WslKeepAlive] Distro 'OpenClawGateway' not found; skipping keepalive.	HasDistro = false

So this isn't a leftover-state false-positive (and #467 isn't biting here in a destructive way). The dialog is appearing by design as a "here's what will happen" confirmation prompt before destructive WSL provisioning. The user reasonably described it as an "explanation dialog" because that's exactly what it reads as.

If the desired behaviour is "skip the prompt on first-run / fresh machines, show only when replacement is needed", this is a 4-line change:

private async void StartButton_Click(object sender, RoutedEventArgs e)
{
    var dataDir = Environment.GetEnvironmentVariable("OPENCLAW_TRAY_DATA_DIR")
        ?? Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "OpenClawTray");
    var existing = ExistingConfigDetector.Detect(dataDir, _config!.DistroName);

    // Fresh machine — no confirmation needed, just proceed.
    if (!existing.HasLocalGateway && !existing.HasDistro)
    {
        App.MainWindow?.NavigateToCapabilities();
        return;
    }

    // Existing state present — show replacement-confirmation dialog.
    var dialog = new ContentDialog
    {
        Title = "Replace existing WSL gateway?",
        Content = ExistingConfigDetector.BuildReplacementSummary(existing),
        PrimaryButtonText = "Continue",
        CloseButtonText = "Cancel",
        DefaultButton = ContentDialogButton.Close,
        XamlRoot = XamlRoot,
    };
    if (await dialog.ShowAsync() == ContentDialogResult.Primary)
        App.MainWindow?.NavigateToCapabilities();
}

That gives you: no friction on the fresh-install easy-button flow; a clear "we found existing stuff, are you sure?" speed bump only when there's actually existing state to be replaced. The current code is also subtly bug-prone in that DefaultButton = ContentDialogButton.Close means pressing Enter cancels — fine UX defensively but surprising if you intend Enter to confirm; either fix is reasonable, but it's worth a decision either way.

The user's hypothesis ("uninstall left behind some state OR there's a bug in the check") was correct that there's a logic bug — just not a detector false-positive. It's that the dialog is unconditional, so the "no existing state" branch shows it anyway.

---

Issue #2 — page-2 crash: CapabilitiesPage.InitializeComponent() (workaround from commit 207aadfd wasn't applied to the other 5 pages)

The user identified page 2 as "the gateway setup UX" but the actual navigation chain from SetupWindow.xaml.cs is:

WelcomePage  →  CapabilitiesPage  →  ProgressPage  →  WizardPage  →  PermissionsPage  →  CompletePage
  (#1)            (#2 crash)          (#3 would crash)  (#4 = "Gateway setup")  (#5)            (#6)

WizardPage is the page that has the header text "Gateway setup" — but it's reached after CapabilitiesPage (#2, "Configure capabilities") and ProgressPage (#3, "Setting up locally"). The crash you're seeing happens immediately when navigating to CapabilitiesPage (page 2) — before ProgressPage/WizardPage are ever reached.

Why CapabilitiesPage crashes

// src/OpenClaw.SetupEngine.UI/Pages/CapabilitiesPage.xaml.cs (verbatim from PR HEAD)
public sealed partial class CapabilitiesPage : Page
{
    private SetupConfig? _config;
    private readonly Dictionary<string, ToggleSwitch> _toggles = new();

    private static readonly (string Key, string Name, string Desc, string Glyph)[] Capabilities = [ ... ];

    public CapabilitiesPage()
    {
        InitializeComponent();   // ← crash site — XAML loader → RoGetActivationFactory → E_FAIL → STATUS_STOWED_EXCEPTION
    }

    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
        _config = e.Parameter as SetupConfig ?? new SetupConfig();
        BuildToggles();
    }
    ...
}

Commit 207aadfd introduced a BuildPageShell() workaround for WelcomePage and BuildWindowShell() for SetupWindow. Both replace InitializeComponent() with imperative C# control construction so the XAML binary loader is never invoked, avoiding the RoGetActivationFactory call that fails in the self-contained-unpackaged-from-package-directory activation context. The same workaround was NOT applied to any of the other five pages, all of which still call InitializeComponent():

Page	InitializeComponent()?	Status	Named-element complexity
WelcomePage	No (uses BuildPageShell)	✅ works	—
SetupWindow	No (uses BuildWindowShell)	✅ works	—
CapabilitiesPage	Yes	💥 current crash site	trivial — only CapGrid is referenced from code-behind
ProgressPage	Yes	💥 will crash next	medium — StepsPanel, LogText, LogScroller, LogPanel, SubtitleText, LogToggleButton, OpenLogButton
WizardPage ("Gateway setup")	Yes	💥 will crash	hard — 12 named fields incl. BusyRing, TitleText, MessagePanel, SelectOptions, MultiOptions, TextInput, SecretInput, ErrorText, StepCard, StatusText, PrimaryButton, SecondaryButton
PermissionsPage	Yes	💥 will crash	easy — only PermRows
CompletePage	Yes	💥 will crash	medium — SuccessIcon, FailureIcon, TitleText, SubtitleText, ErrorCard, ErrorText, ViewLogLink, NodeModeBanner, StartupToggle, LaunchButton

Confirmed crash signature from this run

05:10:18.437   SetupWindow.ctor.begin           pid 22260
05:10:18.480   SetupWindow.ctor.afterWindowHandle
05:10:18.564   SetupWindow.ctor.afterBackdrop
05:10:19.218   SetupWindow.ctor.afterLoadConfig    ← config loaded OK
05:10:19.234   SetupWindow.ctor.afterApplyConfig
05:10:19.258   WelcomePage.ctor.begin
05:10:19.319   WelcomePage.ctor.afterBuildPageShell   ← imperative, works fine
05:10:19.324   SetupWindow.ctor.afterWelcomeNavigate
05:10:19.410   App.OnLaunched.afterBringToFront
(18 seconds — user reads dialog, clicks Continue, dialog dismisses, Frame.Navigate fires)
05:10:37.???   💥 Application Error Id 1000
                  Faulting application: OpenClaw.SetupEngine.UI.exe v0.4.90.0
                  Faulting module:      Microsoft.UI.Xaml.dll v3.2.0.0 @ 0x3ac82d
                  Exception code:       0xc000027b   STATUS_STOWED_EXCEPTION
                  Faulting package-relative application ID: App   ← SetupEngine inherits Tray's PRAID
05:10:37.???   💥 WER Id 1001
                  Fault bucket 1570698272745416374
                  P5 combase.dll  P8 0x80004005 (E_FAIL)  P9 0x9cfd4

The praid:App in the WER is the smoking gun for the Process.Start launch pattern: SetupEngine.UI.exe is spawned as a child of the Tray (PRAID=App), inherits the package identity, and its WinRT activation context = the Tray's activation catalog (which has entries for the Tray's binaries but the XAML metadata provider for SetupEngine's OpenClaw.SetupEngine.UI.Pages.CapabilitiesPage type isn't registered there). InitializeComponent() calls into the XAML BAML loader → resolves OpenClaw.SetupEngine.UI.Pages.CapabilitiesPage against IXamlMetadataProvider → RoGetActivationFactory for the type-info COM class → not in the catalog under PRAID=App → E_FAIL → WinUI internally stows as STATUS_STOWED_EXCEPTION → process death (the SEH bypass means it never surfaces to the C# retry wrapper around Application.Start).

A second crash at 05:11:04 (pid 28000, same WER bucket) is the user clicking the tray's setup button again, getting the same flow.

Two fix options

Option A — quick / safe: apply BuildPageShell() to the other 5 pages

Smallest diff, same proven workaround already used for WelcomePage/SetupWindow. Start with CapabilitiesPage (only one named field, mostly imperative already):

public CapabilitiesPage()
{
    BuildPageShell();  // not InitializeComponent()
}

private void BuildPageShell()
{
    var root = new Grid { Padding = new Thickness(40, 28, 40, 28) };
    root.RowDefinitions.Add(new RowDefinition { Height = GridLength.Auto });
    root.RowDefinitions.Add(new RowDefinition { Height = new GridLength(1, GridUnitType.Star) });
    root.RowDefinitions.Add(new RowDefinition { Height = GridLength.Auto });

    var header = new StackPanel { Spacing = 6, HorizontalAlignment = HorizontalAlignment.Center };
    Grid.SetRow(header, 0);
    header.Children.Add(new TextBlock {
        Text = "Configure capabilities",
        FontSize = 24, FontWeight = Microsoft.UI.Text.FontWeights.SemiBold,
        HorizontalAlignment = HorizontalAlignment.Center });
    header.Children.Add(new TextBlock {
        TextWrapping = TextWrapping.Wrap, TextAlignment = TextAlignment.Center,
        FontSize = 13, Opacity = 0.6, MaxWidth = 440,
        Text = "Choose which capabilities this node will advertise. You can change these later." });

    CapGrid = new Grid { ColumnSpacing = 16, RowSpacing = 4 };
    CapGrid.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(1, GridUnitType.Star) });
    CapGrid.ColumnDefinitions.Add(new ColumnDefinition { Width = new GridLength(1, GridUnitType.Star) });
    var scroll = new ScrollViewer {
        VerticalScrollBarVisibility = ScrollBarVisibility.Auto,
        Margin = new Thickness(0, 20, 0, 0), Content = CapGrid };
    Grid.SetRow(scroll, 1);

    var continueBtn = new Button {
        Content = "Continue",
        HorizontalAlignment = HorizontalAlignment.Stretch,
        Margin = new Thickness(0, 16, 0, 0), Height = 44, FontSize = 15,
        FontWeight = Microsoft.UI.Text.FontWeights.SemiBold };
    continueBtn.Click += Continue_Click;
    Grid.SetRow(continueBtn, 2);

    root.Children.Add(header); root.Children.Add(scroll); root.Children.Add(continueBtn);
    Content = root;
}

CapGrid is the only x:Name field code-behind needs (it's used by BuildToggles()), so this is genuinely trivial for CapabilitiesPage. Then repeat for ProgressPage / WizardPage / PermissionsPage / CompletePage in that order. WizardPage is the biggest job (12 named elements). Add a smoke test that navigates through every page during CI.

Option B — root cause / proper: restore the AUMID launch + <Application Id="SetupEngine"> from commits 05b3376e/43cd21ac, but keep RunWithXamlFactoryRetry

Reading the commit history, the prior PR iteration did implement the right architecture: SetupEngine had its own <Application Id="SetupEngine"> manifest entry with WindowsPackageType=MSIX + WindowsAppSDKSelfContained=true, the tray launched it via shell:AppsFolder\{familyName}!SetupEngine, and Windows gave SetupEngine its own AppX container + activation context. Each app's MSBuild generated its own activatable class entries under its own <Application> element. InitializeComponent() worked on every page because the per-PRAID activation catalog had the right entries.

That approach was reverted by commit 3d8bc4d0 ("restore self-contained setup launch") because it surfaced transient 0x80040111 XAML factory race conditions on first launch right after install. The retry logic from commit 90ec7fc4 (RunWithXamlFactoryRetry) was the right companion to handle that race, and we saw it work successfully (after 1–3 retries) for the Tray.

Restoring the inner-app architecture with the retry kept is the structurally correct fix and avoids having to apply BuildPageShell() to 5 more pages (and to every future page someone adds). The patch is essentially:

1. Revert the Package.appxmanifest change from 3d8bc4d0 (add the <Application Id="SetupEngine"> element back) — keep Executable="SetupEngine\OpenClaw.SetupEngine.UI.exe" since SetupEngine is now in the subfolder.
2. Re-add the PackageMsix=true PropertyGroup to OpenClaw.SetupEngine.UI.csproj with <WindowsPackageType>MSIX</WindowsPackageType> + <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> + <GenerateAppxPackageOnBuild>false</GenerateAppxPackageOnBuild>.
3. Re-add CreateSetupEngineUiStartInfo / ResolveSetupEnginePackagedAppUserModelId in the tray's App.xaml.cs so it launches SetupEngine via shell:AppsFolder\OpenClaw.Companion_qm13sbsk50jee!SetupEngine when packaged.
4. Keep RunWithXamlFactoryRetry in SetupEngine's Program.cs (it's already there) as the transient-race guard.
5. Revert the BuildPageShell() workaround on WelcomePage + the BuildWindowShell() workaround on SetupWindow — they're no longer needed once activation works properly.

My recommendation

Given the timeline pressure to ship the MSIX hardening PR, do Option A for CapabilitiesPage right now (smallest diff, unblocks the immediate flow) and add it to ProgressPage in the same change so a smoke test can reach WizardPage. Then schedule Option B as the architectural fix before the next release — applying BuildPageShell() to every WinUI 3 page is going to bite every time anyone adds a new page or tweaks an existing one's XAML.

If the team would rather do Option B now and skip the workaround proliferation entirely, the existing RunWithXamlFactoryRetry in SetupEngine's Program.cs already handles the transient race that motivated the original revert; we have evidence from the Tray that 3 retries (waitMs=2000, 5000, 10000) reliably get past it.

---

Diagnostic artifacts

ZIP: C:\Users\mharsh\AppData\Local\Temp\openclaw-round10-page2-crash-20260527-052944.zip

• setup-engine-startup.log — shows clean lifecycle through WelcomePage.ctor.afterBuildPageShell then App.OnLaunched.afterBringToFront, then nothing (the crash inside CapabilitiesPage's InitializeComponent() happens before any further breadcrumb)
• round10-crash-events.txt — both Application Error Id 1000 + WER 1001 entries, praid:App confirmed
• round10-state-proof.txt — fresh-machine state audit proving HasLocalGateway = false and HasDistro = false, ruling out a detector false-positive for Issue Add unit tests and code review for Moltbot.Shared #1
• AppxManifest.xml — current manifest (<Application Id="App"> only, no <Application Id="SetupEngine">, no <PackageDependency>)
• openclaw-tray.log.tail50.txt — shows Tray launched SetupEngine via direct path (no shell:AppsFolder invocation this round, confirming master pattern reverted)
• WER-AppCrash_OpenClaw.Compani_*.wer — current WER reports

---

Acknowledgements + smaller open items

• Big win that the Welcome page now renders end-to-end. The BuildPageShell() / BuildWindowShell() pattern definitely works around the activation issue when applied.
• The MSIX uninstall still doesn't clean %LOCALAPPDATA%\OpenClawTray\ (issue Uninstall leaves behind empty directories in %LOCALAPPDATA% #467) — leftover exec-policy.json from 5/20 + accumulated logs are still surviving across install/uninstall cycles on this box. Not biting today's bug but worth fixing before GA.
• DefaultButton = ContentDialogButton.Close on the confirmation dialog means Enter dismisses — surprising default. If you keep the dialog at all (existing-state case), consider switching to ContentDialogButton.Primary so Enter confirms.

---

Posted by Copilot CLI session running on the test machine. Combined test-machine evidence with PR source code at commit head (verbatim WelcomePage.xaml.cs:StartButton_Click, CapabilitiesPage.xaml.cs:ctor, ExistingConfigDetector predicates, navigation chain from SetupWindow.xaml.cs).

[indierawk2k2]

Round 11 local gateway-wizard loop update — stop condition reached

Commit pushed: 897b811 fix(msix): keep setup wizard off fragile XAML path

What the local loop proved

• The previous fix got SetupEngine to Welcome, but the same native WinUI/XAML crash recurred page-by-page after that.
• Direct controls showed these boundaries:
  • CapabilitiesPage.ctor.begin with no afterInitializeComponent → crash at Capabilities XAML load.
  • after Capabilities was code-built, ProgressPage.ctor.begin with no afterInitializeComponent → crash at Progress XAML load.
  • after Progress was code-built, the page stayed alive, but live ProgressRing/FontIcon status badges still caused a native XAML crash once pipeline progress updates began.
• The winning shape keeps the master-compatible direct self-contained SetupEngine launch and avoids the fragile XAML/parser/animated-control path for the first-run flow needed to reach Gateway Wizard.

What changed

• SetupWindow, WelcomePage, CapabilitiesPage, ProgressPage, and WizardPage now build their first-run UI shells in code instead of calling InitializeComponent().
• Progress uses simple text status markers instead of ProgressRing / FontIcon markers on the setup pipeline path.
• Added a structural test pinning that these first-run pages stay off InitializeComponent().

Local stop-condition evidence

• Fresh red x64 loose-package loop: iter7-pr-package-wizard
• Cleaned package/appdata/WSL state, registered the package, launched tray from the package payload, and drove Welcome → Capabilities → Progress.
• Setup pipeline completed gateway install, pairing, and connection.
• Stop condition reached: wizard-start-reached
• UIA final tree shows Gateway setup, status Answer the gateway setup question, first prompt OpenClaw setup, and an enabled Continue button.
• Breadcrumbs include WizardPage.StartWizardAsync.afterWizardStart.

Validation

• ./build.ps1 passed
• Shared tests: 1958 passed / 29 skipped
• Tray tests: 912 passed

Note: the first tray-test rerun failed because the successful local loop intentionally left a real OpenClawGateway WSL distro behind; after unregistering it and removing OpenClaw app state, the required validation passed.

Quick remote-test artifact

• Uploaded signed red x64 MSIX to msix-red-blue-feed-test-2026-05-22
• Asset: OpenClawCompanion-red-0.4.91.0-win-x64.msix
• SHA256: 1204DA0670E7899245DB109EFD5CAF02B23EE1574222822D8FAC3CEAB5F61211
• URL: https://github.com/indierawk2k2/openclaw-windows-node/releases/download/msix-red-blue-feed-test-2026-05-22/OpenClawCompanion-red-0.4.91.0-win-x64.msix

Caveat remains: this box still cannot run the signed package through Add-AppxPackage -Path because local-machine certificate trust is not available, so the local package loop used loose registration plus tray launch. The loop still exercised the package payload, tray → SetupEngine launch path, gateway install, pairing, connection, and Wizard start.

[indierawk2k2]

Round 12 full-matrix follow-up — red/blue x64 + ARM64 rebuilt and uploaded

The gateway-wizard fix remains 897b811 on the PR branch. After the local Wizard stop condition, I rebuilt the full quick-test matrix and uploaded all assets to msix-red-blue-feed-test-2026-05-22.

Uploaded assets

Asset	SHA256
OpenClawCompanion-red-0.4.91.0-win-x64.msix	E4AB0A4ABBC5828074803A72F28FF7E6E10BAA6CAD4760BC52CEEBA986E88351
OpenClawCompanion-red-0.4.91.0-win-arm64.msix	3FD8EB658BAA91DFBC479D76DD1D709477EF334CE73B718E8A3CA1E81119687A
OpenClawCompanion-blue-0.4.92.0-win-x64.msix	901384065F04A56BA3B0147591862DAC6C9B248D0482236595FB0E9A8F2B8DAC
OpenClawCompanion-blue-0.4.92.0-win-arm64.msix	58695FEF49E12368C5C016928E8C80D615C3784CC23EDCCA83258AD014D07198
openclaw-x64.appinstaller	49DB7685BACFDDEF88D68C3E064690C97C51FDF3F449C9FC10ECF85BF6AB8EEA
openclaw-arm64.appinstaller	69649EFBC694CE794661B0EFA8694746BD2011081E516630EB4B736CACFF3BE6

The architecture feeds point at the blue 0.4.92.0 packages, so red 0.4.91.0 can be used as the seed and blue as the update target.

Cleanup/validation

• Checked tracked source/docs/workflows for test-only red/blue artifact names or temporary versions; none are committed. Existing red/blue mentions are validation-gated docs, not shippable artifact references.
• Cleaned generated package payloads from the worktree after local builds.
• Final validation after artifact cleanup passed:
  • ./build.ps1
  • Shared tests: 1958 passed / 29 skipped
  • Tray tests: 912 passed

[indierawk2k2]

Hanselman adversarial review completed after master resync + production MSIX cleanup

Models:

• Opus: claude-opus-4.6
• Codex: gpt-5.2-codex

Consensus table

Issue	Opus	Codex	Consensus	Fix confidence	Outcome
Tray WinUiStartupGate retried 0x80040111 but not observed transient E_FAIL / 0x80004005 while SetupEngine retried both	MEDIUM	MEDIUM	HIGH	95%	Fixed in b1a3922
SetupEngine startup breadcrumbs logged raw command-line args	LOW	—	LOW	90%	Fixed in b1a3922 by applying the same redaction shape as tray startup breadcrumbs
Prerelease MSIX/AppInstaller versions may not be monotonic for x64 alpha builds	—	HIGH	LOW / disputed	70%	Deferred: stable feed updates are explicitly blocked for prerelease tags in appinstaller-feed-pr.yml; alpha channel policy is intentionally undecided
Prerelease MSIX/AppInstaller versions may not be monotonic for ARM64 alpha builds	—	HIGH	LOW / disputed	70%	Deferred for the same reason as x64; if/when alpha AppInstaller feeds are enabled, the fourth MSIX version segment needs a monotonic prerelease policy

Fixes made

• b1a3922 fix(msix): align tray WinUI startup retry
  • Tray startup retry now treats 0x80004005 as transient, matching SetupEngine's observed XAML startup failure set.
  • Added tests for E_FAIL retry and non-retry of unrelated COM errors.
  • SetupEngine startup breadcrumbs now redact command-line arguments before writing setup-engine-startup.log.

Production prep completed

• Branch resynced with origin/master via merge commit de004ee.
• Production MSIX/AppInstaller cleanup committed in 31b88c3:
  • stable feed workflow requires production-named release assets (OpenClawCompanion-$versionText-win-x64.msix, OpenClawCompanion-$versionText-win-arm64.msix);
  • temporary color-channel artifact terminology removed from the committed PR diff;
  • release-flow tests pin production naming and Azure Trusted Signing MSIX signing.

Validation after review fixes

• ./build.ps1 passed
• Shared tests: 2022 passed / 29 skipped
• Tray tests: 929 passed