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