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 June 29, 2026, 9:32 PM ET / 01:32 UTC.

Summary
Keep open: current main still documents and tests the transitional Inno/portable ZIP release path, MSIX publishing is explicitly paused, the Updatum flow still installs the downloaded asset without a packaged-install guard, and the related epic/PR show active product and release-security work rather than a completed strategy.

Reproducibility: not applicable. This is a release packaging and update-strategy decision, not a single reproducible runtime bug; the proof path is signed Windows install/update/uninstall validation across the chosen distribution modes.

Root-cause cluster
Relationship: canonical
Canonical: #246
Summary: This issue remains the focused packaging/update strategy decision; related items are broader tracking or implementation slices, not replacements for the decision.

Members:

• partial_overlap: 🦞 Tracking: Ship & update the node with confidence #838 - The epic lists this issue as a child under the broader ship/update confidence outcome, so it rolls up but does not replace this decision.
• partial_overlap: MSIX packaging (WinAppSDK framework + identity) #854 - The MSIX packaging issue names this issue as the related decision and covers only the MSIX implementation slice.
• fixed_by_candidate: Work in progress: msix installer #732 - The open draft PR is a candidate for the MSIX installer path, but it is not ready, not merged, and does not complete the full strategy decision.
• adjacent_distinct: [deep-review] C4: Updatum auto-update path has no visible Authenticode verification #344 - The closed Updatum Authenticode issue is adjacent security context for updater trust, but it does not decide installer versus ZIP versus MSIX strategy.

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.

Next step
Maintainers should resolve the product/release/security direction and review the active draft MSIX installer path rather than queue a separate autonomous fix PR.

Security
Needs attention: The issue is security-sensitive because installer choice, package identity, signing, and updater asset selection define the trust boundary for installed Windows clients.

Review details

Best possible solution:

Keep this issue as the focused packaging/update strategy tracker until maintainers land or close an MSIX-first or explicitly hybrid policy with docs, release workflow changes, Updatum gating/asset selection, and Windows install/update/uninstall proof.

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

Not applicable. This is a release packaging and update-strategy decision, not a single reproducible runtime bug; the proof path is signed Windows install/update/uninstall validation across the chosen distribution modes.

Is this the best way to solve the issue?

No completed solution is on current main. The MSIX-first direction in the discussion looks plausible, but it still needs maintainer approval, workflow/docs changes, Updatum gating, architecture selection, and real Windows lifecycle proof.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Packaging and update strategy crosses release signing, package identity, update-feed trust, architecture selection, and installed-layout migration, so it needs maintainer release/security review before implementation is treated as complete.
• An open draft MSIX installer PR exists, but its body says it is not ready for review and it does not close this issue, so opening a separate automated fix PR would likely duplicate active work.

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

Label changes

Label changes:

• add P2: This is important release packaging and update-path work with real user impact, but it is not a current emergency or confirmed broken live workflow.
• add impact:security: The issue directly affects update trust, release signing, package identity, and preventing installed clients from crossing unsafe update technologies.
• add impact:other: The issue also covers Windows 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: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 important release packaging and update-path work with real user impact, but it is not a current emergency or confirmed broken live workflow.
• impact:security: The issue directly affects update trust, release signing, package identity, and preventing installed clients from crossing unsafe update technologies.
• impact:other: The issue also covers Windows install/update release confidence, which is maintainer-visible but outside the more specific owned impact categories.

Evidence reviewed

Security concerns:

• [medium] Resolve update and signing trust before shipping — src/OpenClaw.Tray.WinUI/Services/UpdateCoordinator.cs:425
  A packaging strategy that leaves installer, ZIP, and MSIX paths ambiguous can move users across different trust and update mechanisms, so maintainers should require explicit asset selection, signing, and packaged-install behavior before broad distribution.
  Confidence: 0.88

What I checked:

• Repository policy read: AGENTS.md was read fully; this is a read-only review, so its required post-change validation commands were not run. (AGENTS.md:1, b4a8d49064a1)
• MSIX release publishing is paused: Current CI keeps the build-msix job behind if:false and the release step uploads only the signed setup EXEs and portable ZIPs, not MSIX assets. (.github/workflows/ci.yml:480, b4a8d49064a1)
• Updater still uses the portable Updatum install flow: UpdateCoordinator downloads an Updatum asset and immediately passes it to InstallUpdateAsync; no current-main guard was found that disables this for packaged installs or explicitly selects installer/MSIX assets. (src/OpenClaw.Tray.WinUI/Services/UpdateCoordinator.cs:425, b4a8d49064a1)
• Release docs pin the current transitional policy: docs/RELEASING.md says the current alpha flow ships Inno setup installers and portable ZIP payloads for Updatum, with MSIX intentionally paused. (docs/RELEASING.md:76, b4a8d49064a1)
• Tests protect the paused-MSIX state: ReleaseSigningWorkflowTests asserts that MSIX is paused and that the release step does not include .msix artifacts, so current main has not implemented the MSIX-first acceptance criteria. (tests/OpenClaw.Tray.Tests/ReleaseSigningWorkflowTests.cs:99, b4a8d49064a1)
• Related work keeps this as a live decision: GitHub search found the open release-confidence epic listing this issue as a child, the open MSIX packaging issue naming this as the related decision, and a draft MSIX installer PR whose body says it is not ready for review.

Likely related people:

• shanselman: Git history ties this person to the original auto-updating installer, MSIX dual-distribution packaging, the Inno-primary shift, and the paused-MSIX alpha policy; the issue discussion also records the MSIX-first direction update. (role: release packaging direction contributor; confidence: high; commits: bfa0e6c0f96f, 3fc96748d52e, 5a555abf9e4c; files: .github/workflows/ci.yml, installer.iss, docs/RELEASING.md)
• kmahone: Recent commits repointed the Updatum updater, fixed update-download runtime behavior, and restored ARM64 portable ZIP release support; the same account owns the open draft MSIX installer PR. (role: recent updater and release artifact contributor; confidence: high; commits: ec11986539f9, 53ff55aff974, f839cf53aa0c; files: src/OpenClaw.Tray.WinUI/App.xaml.cs, src/OpenClaw.Tray.WinUI/Services/UpdateCoordinator.cs, .github/workflows/ci.yml)
• indierawk2k2: GitHub PR search and history show prior MSIX/AppInstaller feed work and its revert on the same release/update path, which is adjacent to the current strategy decision. (role: adjacent MSIX/AppInstaller contributor; confidence: medium; commits: 4a606a6b7a12, 48989ebd813e; files: .github/workflows/msix-update-feed-pages.yml, docs/msix-feed/openclaw-x64.appinstaller)
• Regis Brid: History shows this person introduced the current consolidated update-check feedback flow and version display plumbing, which is part of the in-app updater surface affected by the strategy. (role: update-status contributor; confidence: medium; commits: f3d3fd2772f3; files: src/OpenClaw.Tray.WinUI/Services/UpdateCoordinator.cs, src/OpenClaw.Shared/AppVersionInfo.cs, docs/VERSIONING.md)

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.