Decide Windows packaging and auto-update strategy

[shanselman]

Problem

The Windows tray currently appears to ship through three different distribution/update paths:

1. Inno Setup installer via installer.iss

   • Release workflow builds OpenClawTray-Setup-x64.exe and OpenClawTray-Setup-arm64.exe.
   • This looks like the friendly/default install path.

2. Portable ZIP artifacts

   • Release workflow builds OpenClawTray-<version>-win-x64.zip and OpenClawTray-<version>-win-arm64.zip.
   • Workflow comments say these ZIPs are for Updatum auto-update.
   • App code configures Updatum like a portable/single-file update flow, not like installer/MSIX update flow.

3. MSIX packages

   • CI/release builds OpenClawTray-<version>-win-x64.msix and OpenClawTray-<version>-win-arm64.msix.
   • Release notes describe MSIX as useful for packaged Windows consent surfaces such as camera/microphone permissions.

That means install/update behavior is ambiguous: a user may install with the .exe, but the in-app updater may consume ZIP assets; MSIX has its own install/update semantics but is not wired into the in-app updater.

Why this matters

We should make a deliberate packaging decision before the Windows tray gets broader distribution:

• avoid users accidentally crossing install technologies during update
• avoid duplicated signing/release complexity if we do not need all formats
• define which package is the supported/default path
• define how camera/microphone/screen permissions should behave for unpackaged vs packaged installs
• make Updatum asset selection explicit and tested

Current evidence

• installer.iss is active in the tag release workflow and builds signed installer .exe assets.
• .github/workflows/ci.yml builds portable ZIPs and comments that they are for Updatum auto-update.
• .github/workflows/ci.yml also builds MSIX packages.
• App.xaml.cs configures UpdatumManager with InstallUpdateSingleFileExecutableName = "OpenClaw.Tray.WinUI" and does not explicitly target installer or MSIX assets.

Decision needed

Pick one of these strategies:

1. Installer-first: EXE installer is the blessed install/update path; configure updater to download/run the installer, and demote ZIP/MSIX as secondary/manual assets.
2. Portable-first: ZIP is the blessed install/update path; keep Inno only for convenience install and document that it transitions to ZIP-based self-update.
3. MSIX-first: MSIX is the blessed install/update path; use MSIX/App Installer update semantics and remove or demote the custom updater/installer.
4. Hybrid, explicitly supported: keep multiple paths, but document and test which updater applies to each installed form.

Proposed acceptance criteria

• Document the supported/default install path in README/release notes.
• Document whether .exe, .zip, and .msix are primary, secondary, or deprecated.
• Make Updatum asset selection explicit, including architecture matching.
• Add/update tests or a release checklist proving the updater downloads the intended asset type.
• Ensure the updater does not accidentally update an MSIX install with ZIP files or an installer install with an incompatible portable layout.
• If multiple install paths remain, document how each one updates.

[github-actions]

🤖 This is an automated response from Repo Assist.

Good write-up of a genuinely tricky problem. I looked at the current code to map out the exact gaps.

What the code shows today

App.xaml.cs — Updatum config (lines 30–34):

internal static readonly UpdatumManager AppUpdater = new("shanselman", "openclaw-windows-hub")
{
    FetchOnlyLatestRelease = true,
    InstallUpdateSingleFileExecutableName = "OpenClaw.Tray.WinUI",
};

There is no architecture-aware asset filter. DownloadUpdateAsync() is called with no selector. On an arm64 machine, if Updatum picks alphabetically or by position, it may choose OpenClawTray-x.y.z-win-x64.zip rather than win-arm64.zip — which would install the wrong binary silently.

ci.yml comment (line ~449):

# Create ZIP files for Updatum auto-update (needs "win-x64" in filename)

This comment reads like a convention hint to Updatum, not a confirmed capability. It is unclear whether the Updatum library auto-detects the current process architecture from the asset filename. This needs verification against the Updatum 1.3.4 docs/changelog.

MSIX path: Fully disconnected from UpdatumManager. MSIX uses its own store/installer update semantics. No wiring needed there, but users who installed via MSIX will not receive updates through DownloadAndInstallUpdateAsync.

Specific gaps to resolve

Gap	Impact	Suggested fix
No architecture-aware asset selector	arm64 installs may receive x64 update	Add AssetNameContains or equivalent filter using RuntimeInformation.ProcessArchitecture
"needs win-x64 in filename" assumption unverified	Silently broken on arm64 if assumption is wrong	Confirm Updatum 1.3.4 auto-detection behaviour; document if confirmed
Installer vs ZIP update path undefined	User could install via .exe, app self-updates via ZIP (incompatible layout)	Decide which asset type the updater targets; make it explicit
No test for Updatum asset selection	Regressions undetectable	Add a test or release checklist item verifying correct ZIP selected for each arch

Suggested direction

Option 1 (Portable-first, minimal change): Keep the ZIP path for Updatum. Add an architecture-aware asset name predicate. Document the EXE installer as a convenience entry point that transitions to ZIP-based self-update, and document this clearly in README.

Option 2 (Installer-first): Configure Updatum (if supported) to download and run the signed installer on update rather than a raw ZIP. Avoids the layout-mismatch risk at the cost of a heavier update flow.

The MSIX path can stay as-is regardless of which direction is chosen — it's naturally isolated.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[shanselman]

Decision update: we want to move toward MSIX-first packaging.

Near-term plan:

• Use Scott's existing signing key/service for MSIX signing and publishing while we prove the flow.
• Treat the current Inno installer and portable ZIP/Updatum path as transitional/secondary until the MSIX path is reliable.
• Ensure an MSIX install never self-updates with portable ZIP bits; packaged installs should use the MSIX/App Installer-style update path.
• Make architecture selection explicit for x64 vs ARM64.
• Document install/update behavior so users do not cross installer, ZIP, and MSIX technologies accidentally.

Longer-term plan:

• Move signing/update/distribution to the Windows-native path once available/ready, rather than carrying a custom signing/update service forever.

Suggested next implementation slice: update release docs/workflows so MSIX is the primary path, gate/disable Updatum for packaged installs, and add a release validation checklist for install, update, uninstall, protocol activation, startup behavior, and camera/mic permission prompts.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 29, 2026, 11:50 PM ET / July 30, 2026, 03:50 UTC.

Summary
Keep open. This is still the active maintainer decision that sets the install and update contract for the Windows node: the author selected an MSIX-first direction, but the current release program still has open implementation and rollout work under the ship-and-update epic and the MSIX packaging child issue. The issue is collaborator-authored and carries security and maintainer-review labels, so it requires explicit maintainer handling rather than automated closure.

Reproducibility: not applicable. This issue requests a release-product decision rather than reporting a failing runtime behavior; the decision and its resulting install/update validation are the evidence path.

Root-cause cluster
Relationship: partial_overlap
Canonical: #838
Summary: This issue supplies the packaging-and-update policy decision for the broader open ship-and-update epic; the MSIX child issue is a dependent implementation slice rather than a duplicate.

Members:

• canonical: 🦞 Tracking: Ship & update the node with confidence #838 - The open epic explicitly lists this issue as a child and owns the broader outcome of shipping and updating the node with confidence.
• partial_overlap: MSIX packaging (WinAppSDK framework + identity) #854 - The open MSIX packaging issue implements one consequence of this decision but does not replace the policy choice for legacy installer and portable paths.
• superseded: Work in progress: msix installer #732 - The draft MSIX installer pull request was closed unmerged and therefore is not a viable canonical implementation path.

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.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should the project formally make MSIX/App Installer the primary supported Windows distribution path, while defining the migration and support policy for existing Inno and portable installations?	Adopt MSIX-first: Approve MSIX/App Installer as the primary path and require the open MSIX work to specify a tested migration or retirement policy for installer and portable users.

Why: The requested outcome changes the supported release contract and upgrade behavior across persisted installations; source-level work cannot safely decide which legacy paths remain supported or how users migrate.

Next step
A maintainer must choose the supported distribution and legacy-migration contract before a focused implementation PR can be safely scoped.

Security
Needs attention: The issue is security-sensitive because a packaging decision controls signed update delivery and whether installations can cross update technologies.

Review details

Best possible solution:

Adopt MSIX/App Installer as the documented primary path, explicitly preserve or retire each legacy path with an upgrade policy, then deliver the work through the open MSIX packaging issue with signed x64 and ARM64 install, update, uninstall, protocol, startup, and permission validation.

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

Not applicable. This issue requests a release-product decision rather than reporting a failing runtime behavior; the decision and its resulting install/update validation are the evidence path.

Is this the best way to solve the issue?

Yes. Resolving the distribution contract before attempting more packaging changes is the narrowest maintainable path, because the open MSIX implementation work depends on a defined policy for legacy installations.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Selecting MSIX-first without an explicit supported transition contract can leave existing Inno or portable users on an incompatible updater path.
• The release and update mechanism is supply-chain sensitive: package identity, signing, architecture selection, and update-source validation need one owner-approved contract before broad distribution.
• The closed draft MSIX installer pull request is not a viable replacement implementation, so the open epic and child issue remain the active planning path.

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

Label changes

Label justifications:

• P2: This is a normal-priority release and packaging decision with broad upgrade implications, but no current evidence of an immediate user-facing outage.
• impact:security: The chosen update path governs signed package delivery and prevents packaged installs from receiving incompatible portable update bits.
• impact:other: The issue materially affects release distribution, installation, update, uninstall, and Windows permission behavior outside the more specific impact taxonomy.

Evidence reviewed

Security concerns:

• [medium] Define the trusted update boundary
  The final strategy needs explicit signed-package, update-source, architecture-selection, and installed-form isolation rules before broad rollout.
  Confidence: 0.88

What I checked:

• Maintainer direction: A collaborator comment on May 18, 2026 explicitly chose an MSIX-first direction, requested packaged installs be isolated from portable ZIP updates, and named docs, workflow, and validation work that remains to be completed.
• Active canonical rollout: The open ship-and-update epic treats this issue as a child and defines MSIX install identity, alpha-to-stable updates, retirement of the Inno installer, compatibility, and diagnostics as unfinished work.
• Open implementation slice: The open MSIX packaging child issue names signed MSIX installation with identity as its definition of done and explicitly identifies this issue as the related decision.
• Prior current-main assessment: The previous ClawSweeper review found the transitional Inno and portable ZIP release path, paused MSIX publishing, and an Updatum path without a packaged-install guard; no provided evidence establishes that the complete strategy has since shipped.

Likely related people:

• shanselman: Set the MSIX-first direction and outlined the required near-term packaging, update-isolation, architecture, and validation outcomes in the issue discussion. (role: product-direction author; confidence: high)
• samanthamsong: Created the open ship-and-update epic and its open MSIX packaging child issue, which currently organize the remaining delivery work. (role: release-work tracker; 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.