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 July 29, 2026, 4:44 PM ET / 20:44 UTC.

Summary
Keep open. This is collaborator-authored, security-labeled release work, and the signed MSIX requirement remains dependent on an unresolved packaging and update strategy rather than a confirmed current-main implementation.

Reproducibility: not applicable. This is a release-packaging capability request, not a report of a reproducible current behavior failure.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should OpenClaw make identity-backed MSIX a supported primary distribution path, and if so how should it coexist with or replace the existing installer, portable ZIP, and in-app updater paths?	Keep MSIX secondary: Ship signed MSIX only for packaged capability scenarios while retaining the installer or portable updater as the documented default.

Why: This choice determines user upgrade compatibility, release signing obligations, and whether AppInstaller or the existing updater owns updates; code review cannot safely select that product and release contract.

Next step
A maintainer must first select the supported installation and update contract; the security and release implications make this unsuitable for an automated fix PR.

Security
Needs attention: MSIX signing, package identity, framework delivery, and updater selection are security-sensitive release boundaries that require explicit review before implementation.

Review details

Best possible solution:

Choose and document the supported packaging/update model in the strategy work, then land a narrow MSIX implementation with signed identity, framework dependency handling, and real clean-install plus upgrade validation for both architectures.

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

Not applicable. This is a release-packaging capability request, not a report of a reproducible current behavior failure.

Is this the best way to solve the issue?

Unclear. The MSIX implementation direction is technically plausible, but it is not the best final solution until maintainers choose how package identity and AppInstaller updates coexist with the existing installer and portable paths.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Choosing MSIX without first defining the supported installer and updater path could make existing installations cross packaging technologies or receive an incompatible update.
• Package identity, signing certificates, framework dependency delivery, and AppInstaller behavior need explicit security and release-owner review before distribution.
• Fresh-install success alone is insufficient: the chosen approach must prove updates from the currently supported installer and portable paths, including both x64 and ARM64.

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

Label changes

Label changes:

• remove clawsweeper:fix-shape-clear: Current issue advisory state no longer selects this label.

Label justifications:

• P1: The release-confidence epic treats a clean, trusted Windows distribution and update path as high-priority work affecting real installations.
• impact:security: The requested package identity and signing establish the trust boundary for Windows installation and update delivery.
• impact:other: The work materially affects release packaging, installation, and updater behavior outside the narrower owned impact taxonomy.

Evidence reviewed

Security concerns:

• [medium] Define package trust and update ownership
  The issue requests a signed identity-backed package but does not yet establish how certificates, framework dependencies, AppInstaller feeds, and existing update paths will coexist without weakening upgrade trust.
  Confidence: 0.95

What I checked:

• Requested outcome remains open work: The issue explicitly requires a signed, identity-backed MSIX that installs cleanly; its GitHub development section has no linked branch or pull request. (c04c5fb06238)
• Packaging direction is unresolved: The linked open strategy issue documents simultaneous installer, portable ZIP, and MSIX release paths and calls for a maintainer choice about the supported update model before changing distribution behavior. (c04c5fb06238)
• Maintainer handling is required: This issue is authored by a COLLABORATOR and carries security, maintainer-review, product-decision, and no-new-fix-PR labels; repository policy requires keeping collaborator-authored and protected-label items open for explicit maintainer judgment. (AGENTS.md:1, c04c5fb06238)
• Prior implementation candidate did not land: The related MSIX hardening pull request was closed unmerged, so it is not evidence that the requested signed MSIX release path is implemented on current main.

Likely related people:

• shanselman: Authored the still-open packaging and auto-update strategy issue that defines the installer, ZIP, MSIX, and updater decision this work depends on. (role: packaging-strategy author and recent release-area contributor; confidence: high; files: installer.iss, .github/workflows/ci.yml, src/OpenClaw.Tray.WinUI/App.xaml.cs)
• samanthamsong: Authored this task and the open release-confidence tracking epic that lists it as a child work item. (role: epic and work-item author; confidence: high)

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.