MSIX packaging (WinAppSDK framework + identity)

[samanthamsong]

Epic: «Ship & update the node with confidence» (#838)
Backlog Doc ID: #20 · Priority: P1 · Area: release

Description
Package the app as MSIX using the WinAppSDK framework + identity.

Definition of done
Signed MSIX with identity installs cleanly. Related decision: #246.

Part of the «Ship & update the node with confidence» tracking issue (#838).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 26, 2026, 2:35 PM ET / 18:35 UTC.

Summary
Keep open: current main has MSIX scaffolding, but MSIX release publishing is explicitly paused, the latest release shipped only installer and ZIP assets, and the open MSIX implementation candidate still needs maintainer release/security review.

Reproducibility: not applicable. This is a release packaging feature slice; the proof path is a signed MSIX/AppInstaller install and lifecycle run on Windows rather than a bug reproduction.

Root-cause cluster
Relationship: canonical
Canonical: #854
Summary: This issue is the focused MSIX packaging child; the umbrella, strategy issue, and draft PR are related but do not make the work complete on main.

Members:

• partial_overlap: 🦞 Tracking: Ship & update the node with confidence #838 - The tracking epic lists this issue as the MSIX packaging child for broader ship/update confidence.
• partial_overlap: Decide Windows packaging and auto-update strategy #246 - The packaging and auto-update strategy decision gates the final MSIX-first release path.
• fixed_by_candidate: Work in progress: msix installer #732 - The open draft PR is the current implementation candidate for the MSIX installer work, but it is not merged or proof-cleared.
• superseded: MSIX distribution hardening: AppInstaller updates and packaged setup launch #468 - A collaborator comment says the older MSIX/AppInstaller draft is being abandoned in favor of the newer open candidate.
• adjacent_distinct: Show an error when manual AppInstaller update check cannot fetch the feed #563 - That issue covers AppInstaller feed error UX, which is adjacent to the MSIX/AppInstaller path but narrower than packaging identity itself.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

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

Next step
Manual review is needed because an open draft implementation already carries the likely code path, while the remaining work requires release, upgrade, signing, and product-direction decisions.

Security
Needs attention: The request is security-sensitive because package identity, signing, full-trust MSIX capabilities, and update-feed trust are release boundaries.

Review details

Best possible solution:

Finish the MSIX-first path through a maintainer-approved implementation that enables signed MSIX/AppInstaller release artifacts with package identity, explicit migration/update/uninstall behavior, and real Windows lifecycle proof.

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

Not applicable. This is a release packaging feature slice; the proof path is a signed MSIX/AppInstaller install and lifecycle run on Windows rather than a bug reproduction.

Is this the best way to solve the issue?

No, current main is not yet the best completed solution because it only has disabled scaffolding. The maintainable path is to resolve the release strategy in #246 and land or replace #732 with production-safe proof.

AGENTS.md: found, but no applicable review policy affected this item.

Remaining risk / open question:

• MSIX/AppInstaller changes affect package identity, signing, update feeds, migration, and uninstall behavior, so unit tests alone will not settle upgrade safety.
• The current open candidate is a draft with prior merge-risk findings, so opening a separate automated fix PR would likely duplicate or conflict with active release-path work.

Codex review notes: model internal, reasoning high; reviewed against 1c377cb64b65.

Label changes

Label changes:

• add P2: This is significant Windows release packaging work, but it is not a current emergency or confirmed user-facing regression.
• add impact:security: The work depends on package identity, signing, full-trust MSIX capability, and update-feed trust boundaries.
• add impact:other: The issue also covers install/update release confidence, which is maintainer-visible but outside the more specific owned impact categories.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is significant Windows release packaging work, but it is not a current emergency or confirmed user-facing regression.
• impact:security: The work depends on package identity, signing, full-trust MSIX capability, and update-feed trust boundaries.
• impact:other: The issue also covers install/update release confidence, which is maintainer-visible but outside the more specific owned impact categories.

Evidence reviewed

Security concerns:

• [medium] Review package identity and feed trust — src/OpenClaw.Tray.WinUI/Package.appxmanifest:15
  Before enabling signed MSIX/AppInstaller distribution, maintainers should verify the manifest identity, signer, update feed endpoints, and full-trust capability behavior so installed clients cannot be moved onto an unintended update path.
  Confidence: 0.86

Acceptance criteria:

• ./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 Windows signed MSIX/Add-AppxPackage or AppInstaller install, update, uninstall, protocol activation, startup, and camera/microphone consent validation for x64 and ARM64

What I checked:

• Repository policy read: AGENTS.md was read fully; no code changes were made, so its post-change validation commands did not apply to this read-only review. (AGENTS.md:1, 1c377cb64b65)
• No VISION.md: No repository-level VISION.md exists, so vision fit cannot be anchored to an explicit project vision document.
• Partial MSIX scaffolding exists: The tray project supports a PackageMsix=true path with WindowsPackageType=MSIX, but package signing is disabled in the project and this is only build scaffolding. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:33, 1c377cb64b65)
• Package identity exists: Package.appxmanifest declares OpenClaw.Companion identity and capabilities, which supports part of the request but does not prove signed release install behavior. (src/OpenClaw.Tray.WinUI/Package.appxmanifest:15, 1c377cb64b65)
• MSIX release job is disabled: Current CI keeps build-msix behind if:false with an explicit alpha pause comment, so current main does not publish signed MSIX packages. (.github/workflows/ci.yml:480, 1c377cb64b65)
• Release assets omit MSIX: The release step uploads the signed Inno setup EXEs and portable ZIPs only; no .msix asset is included in the release file list. (.github/workflows/ci.yml:742, 1c377cb64b65)

Likely related people:

• shanselman: Git history shows commits preparing signed MSIX alpha releases, switching signing actions, then pausing MSIX alpha artifacts and documenting the alpha release playbook; the related strategy discussion also records the MSIX-first direction. (role: release packaging direction contributor; confidence: high; commits: e4dbd31e76a7, 69e907fc5544, d677bea22265; files: .github/workflows/ci.yml, docs/RELEASING.md, tests/OpenClaw.Tray.Tests/ReleaseSigningWorkflowTests.cs)
• kmahone: The open draft Work in progress: msix installer #732 is the current candidate for the MSIX installer work and touches the release workflow, manifest, AppInstaller feeds, and installer replacement surface. (role: current MSIX implementation candidate owner; confidence: high; commits: b05f56190d3c, f839cf5; files: .github/workflows/ci.yml, src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj, src/OpenClaw.Tray.WinUI/Package.appxmanifest)
• ranjeshj: Recent merged work touched setup, uninstall, and release-adjacent lifecycle behavior, and a collaborator comment explicitly routed the older MSIX draft toward the newer open candidate. (role: recent setup and installer lifecycle contributor; confidence: medium; commits: 8af4b70, 191f4d6, cefce39; files: installer.iss, src/OpenClaw.SetupEngine.UI/OpenClaw.SetupEngine.UI.csproj, src/OpenClaw.Tray.WinUI/App.xaml.cs)
• vincentkoc: History shows adjacent Azure Artifact Signing and runtime packaging work in the release workflow that the signed MSIX path would build on. (role: recent release signing contributor; confidence: medium; commits: 9e6f1ca, 7485ce2, ae61c99; files: .github/workflows/ci.yml, docs/RELEASING.md, tests/OpenClaw.Tray.Tests/ReleaseSigningWorkflowTests.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.