Windows Gateway MSIX packaging, distribution, and update plumbing

[samanthamsong]

Summary

Finish the signed Gateway MSIX model, distribution/source strategy, release pinning, and prosumer update mechanism. Keep Companion App distribution separate from Gateway acquisition, while resolving CLI/bootstrapper and installation ownership.

Scope

• Signed Gateway MSIX package (WinAppSDK framework + identity)
• Distribution source strategy (separate from Companion App distribution)
• Release pinning mechanism
• Prosumer update mechanism
• Resolve CLI/bootstrapper installation ownership
• Gateway version alignment with Companion App releases

Related

• Decide Windows packaging and auto-update strategy #246 (Decide Windows packaging and auto-update strategy: Companion App side)
• Windows Hub v2026.7.1 is blocked by Smart App Control because OpenClaw.Chat.dll is unsigned #1153 (Smart App Control blocks unsigned DLL: signing prerequisite)
• Keep Windows Companion aligned with current OpenClaw stable and beta releases #1000 (Keep Windows Companion aligned with OpenClaw stable/beta)
• Enable Companion App to use session backed OpenClaw #1236 (session-backed OpenClaw: Gateway acquisition is part of setup flow)

[clawsweeper]

Codex review: this still needs some work. Reviewed September 22, 2026, 6:27 PM ET / 22:27 UTC.

Summary
Keep open: Gateway packaging has progressed in its dedicated repository, but Companion acquisition and automatic update integration remain incomplete. An open draft PR covers onboarding only, and this collaborator-sponsored issue still tracks distinct lifecycle decisions.

Reproducibility: not applicable. this is a packaging and update capability request, not a reported failure with reproduction steps.

Maintainer decision needed

Question	Recommendation
Should Companion own servicing of separately acquired Gateway MSIX packages, or should Gateway updates be delegated to a Windows-managed distribution channel?	Companion owns Gateway servicing: Confirm Companion as the lifecycle owner and define a trusted release-source contract with the packaging project.

Why: Earlier discussion favored Companion ownership, but left the update mechanism open; the packaging repository now supports both direct-release and Store submission modes without an automatic direct-release update feed.

Next step
Resolve the remaining servicing decision and coordinate the existing onboarding PR before splitting further implementation work; this cross-repository program is not a bounded automatic repair.

Review details

Best possible solution:

Keep package construction in the packaging repository and provide one Companion-managed acquisition, update, rollback, and removal experience that preserves Gateway state and existing version choices.

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

Not applicable: this is a packaging and update capability request, not a reported failure with reproduction steps.

Is this the best way to solve the issue?

Partly: separate Gateway packaging is already established, but the maintainable next step is a shared lifecycle contract and the existing onboarding PR, rather than another packaging implementation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The production Gateway acquisition channel and update owner remain unsettled across Companion and the packaging repository.
• The packaging repository now documents a package-identity transition that cannot preserve packaged LocalState in place; Companion integration needs an explicit compatible migration and recovery contract.

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

Label changes

Label changes:

• add P2: This is a concrete packaging and lifecycle feature program; the issue does not itself establish a currently blocked first-run path or emergency, despite repeated human P0 selections.
• remove P0: Current review triage priority is P2, so this older priority label is no longer current.

Label justifications:

• P2: This is a concrete packaging and lifecycle feature program; the issue does not itself establish a currently blocked first-run path or emergency, despite repeated human P0 selections.
• impact:other: The remaining work affects Gateway distribution, installation ownership, and servicing.

Evidence reviewed

What I checked:

• Current setup remains WSL-based: At the fetched main revision, InstallCliStep selects a WSL distribution and invokes the official CLI installer through RunInWslAsync. This does not implement Gateway MSIX acquisition. (src/OpenClaw.SetupEngine/InstallCliStep.cs:89, c7063081a2a5)
• Existing release-selection contract: The current ADR selects npm latest by default, preserves explicit versions, and verifies the installed version through a protocol-v4 handshake. GatewayInstallPolicyTests covers default selection, exact versions, channels, and legacy pins. This existing policy should inform the MSIX integration instead of introducing a competing version selector. (docs/adr/0001-gateway-release-policy.md:24, c7063081a2a5)
• Companion packaging is separate: Current release documentation describes Companion Store submission assets and explicitly separates Gateway version selection. The v2026.9.4 release includes feat: add Microsoft Store MSIX packaging #1328 (feat: add Microsoft Store MSIX packaging), which does not complete native Gateway acquisition or updates. (docs/RELEASING.md:155, c7063081a2a5)
• Prior discussion establishes the cross-repository boundary: Human comments on feat: add OpenClaw Gateway MSIX packaging #1186 (feat: add OpenClaw Gateway MSIX packaging) distinguish Companion distribution from Gateway acquisition, recommend Companion lifecycle ownership, and leave source and prosumer updates for follow-up. The PR was closed unmerged after packaging moved to a dedicated repository. Its prepared screenshots show genuine historical package installation and CLI execution, not completed Companion integration.
• Verified packaging repository and remaining update gap: GitHub resolves the former openclaw-msix-packaging repository to openclaw/openclaw-windows-packaging. Its pinned README documents immutable release selection, official signing and Store submission modes, but explicitly says it publishes no App Installer feed and GitHub Release installs do not receive automatic update checks. This is relevant because the issue requests distribution and servicing of that separate Gateway package. (README.md:621, 54e718d6d967)
• Gateway release assets now exist: The latest release endpoint reports v2026.9.4-msix.3, published September 19, with x64, ARM64, and bundle assets. Package publication is concrete progress, but does not establish Companion-driven updates.

Likely related people:

• samanthamsong: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• karkarl: 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.