[Feature] Add MSIX packaging infrastructure to support upload to Microsoft Store

[natalie-aguinaldo]

OpenClaw Windows Node needs MSIX packaging infrastructure support to be able to be uploaded to the Microsoft Store

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 9, 2026, 3:19 PM ET / 19:19 UTC.

Summary
Store-ready packaging remains incomplete on main, and the same author’s open implementation PR already owns this request. Keep the issue open until that candidate is resolved.

Reproducibility: not applicable. this requests Store packaging infrastructure rather than reporting broken existing behavior; source confirms only partial packaging support.

Ways to help us reproduce this

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

Next step
Review and resolve #1328 before closing this issue; another implementation PR would duplicate active work.

Review details

Best possible solution:

Extend the existing MSBuild packaging path while preserving current installers and keeping distribution approval and coexistence work in their separate follow-ups.

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

Not applicable: this requests Store packaging infrastructure rather than reporting broken existing behavior; source confirms only partial packaging support.

Is this the best way to solve the issue?

Yes: extending the existing packaging path through the linked candidate is the narrowest approach, with rollout policy tracked separately.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 5e9aae95373c.

Label changes

Label justifications:

• P2: This is a concrete distribution-infrastructure improvement with an active candidate, without evidence of a broken existing installation path.

Evidence reviewed

What I checked:

• Existing support is only a partial foundation: Main enables PackageMsix builds but selects SideloadOnly. The manifest still uses OpenClaw.Companion and certificate-subject publisher guidance, while build.ps1 has no Dev/Store MSIX selector. README documents the existing direct MSBuild path. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:59, 5e9aae95373c)
• Distribution is deliberately paused: Release documentation requires packaged consent validation and release coverage before resuming MSIX distribution. ReleaseSigningWorkflowTests explicitly protects the disabled job and absence of MSIX release assets. (docs/RELEASING.md:154, 5e9aae95373c)
• Open implementation candidate: feat: add Microsoft Store MSIX packaging #1328 remains open and unmerged, explicitly links this issue for closure, and separates packaging tooling from distribution enablement. Its complete live body confirms the scope statement truncated in the supplied context.
• Useful proof already accompanies the candidate: The supplied candidate body records Windows packaging, WACK, coexistence, and startup-toggle observations. All four prepared images were inspected and show duplicate installation entries and corresponding startup toggle states; this is positive implementation context, not proof that the work has landed.
• Separate follow-up boundaries: Open Migrate from the Inno (.exe) app to the Store MSIX #1374 covers installation coexistence and migration; open Enable Microsoft Store distribution (lift the MSIX publish pause) #1375 explicitly excludes packaging tooling and owns distribution enablement and channel policy.
• Latest release boundary: The v2026.7.1-4 release lists x64/ARM64 Inno installers and portable ZIP downloads, not Store packaging delivery. (c7c6fb06be03)

Likely related people:

• Scott Hanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Vincent Koc: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.