Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`OPENCLAW_UPDATE_CHANNEL=alpha` is shown in Settings but ignored by the updater; alpha installs can never discover newer alphas

Open
  • Is something wrong?
#1,642 5 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, github
Domain
desktop, devtools

Research direction

Start with src/OpenClaw.Tray.WinUI/App.xaml.cs and src/OpenClaw.Tray.WinUI/Services/UpdateCheckPipeline.cs, then trace how the channel label in SettingsPage.xaml.cs relates to the Updatum configuration. Review the existing update-check tests and add coverage for alpha and stable channels. Done when alpha installs can discover newer alphas, or the UI clearly explains that they do not self-update.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P2

Summary

On an alpha install, Check for updates always reports "No updates available", even when a newer alpha has been published. The updater only asks GitHub for the repository's latest release, and GitHub's latest-release endpoint never returns pre-releases. So an alpha user stays on their alpha until a newer stable release ships, and "up to date" is misleading in the meantime.

Environment

  • OpenClaw Companion 2026.9.5-alpha.93 (installed with the Setup installer, not the Store/MSIX; the update check runs, see the log below)
  • Windows 11 Home 10.0.26200
  • Newest published pre-release: v2026.9.5-alpha.97 (2026-10-03T18:55:21Z, prerelease: true, not a draft, includes OpenClawCompanion-Setup-x64.exe and OpenClawTray-2026.9.5-alpha.97-win-x64.zip)
  • Repository "latest" release (GET /repos/openclaw/openclaw-windows-node/releases/latest): v2026.9.4 (2026-09-15)

Steps to reproduce

  1. Install any alpha, e.g. v2026.9.5-alpha.93.
  2. Wait for a newer alpha to be published (e.g. alpha.97).
  3. Click Check for updates.

Actual: "No updates available" / status Current.
Expected: Either the newer alpha is offered, or the UI states that alpha builds don't self-update and points to the Releases page.

Log evidence (%LOCALAPPDATA%\OpenClawTray\openclaw-tray.log)

[2026-10-05 08:23:52.470] [INFO] Manual update check requested
[2026-10-05 08:23:52.470] [INFO] Checking for updates...
[2026-10-05 08:23:52.770] [INFO] No updates available

settings.json has no update-channel or pre-release setting (checked all 70 keys), so this isn't configuration drift.

The alpha channel is set and displayed, but the updater ignores it

  • The Windows user environment variable OPENCLAW_UPDATE_CHANNEL=alpha is set on this machine.
  • Settings → About → App info shows Version v2026.9.5-alpha.93 and Update channel: alpha, right next to the Check for updates button that then reports no update (screenshot in the comment below). The label is read from that variable:
    SettingsPage.xaml.cs L206-L207 @ 7127c16
  • The developer launcher documents it as the prerelease switch, in run-app-local.ps1 L44-L45: "Set OPENCLAW_UPDATE_CHANNEL for this launch. Use alpha for prerelease update testing…"
  • But nothing in the update path reads OPENCLAW_UPDATE_CHANNEL. Across the repo at 7127c16 it's referenced only by the Settings label and run-app-local.ps1. So the UI tells the user they're on the alpha channel while the updater stays on stable.

Root cause

  1. The app pins Updatum to the latest release only, and leaves AllowPreReleases at its default (false):
    App.xaml.cs L46-L50 @ 7127c16 
    internal static readonly UpdatumManager AppUpdater = new("openclaw", "openclaw-windows-node")
{
    FetchOnlyLatestRelease = true,
    InstallUpdateSingleFileExecutableName = "OpenClaw.Tray.WinUI",
};
  2. In Updatum 1.3.4 (the version referenced in OpenClaw.Tray.WinUI.csproj L119), FetchOnlyLatestRelease calls Release.GetLatest(...), and pre-releases are skipped unless AllowPreReleases is set:
    UpdatumManager.cs L629 and L644 
    var release = await GithubClient.Repository.Release.GetLatest(Owner, Repository)...
...
|| (!AllowPreReleases && release.Prerelease)) // Skip pre-releases if not allowed
    GitHub's latest-release endpoint returns the most recent non-pre-release, non-draft release (currently v2026.9.4). Because v2026.9.4 is older than 2026.9.5-alpha.93, Updatum reports no update.
  3. The app's fallback path also excludes pre-releases by design (stable-correction ordering):
    UpdateCheckPipeline.cs L164-L166 @ 7127c16

So there's currently no code path by which an alpha install can be offered a newer alpha.

Suggested direction (maintainers' call)

  • Option 0, wire up the existing knob: when OPENCLAW_UPDATE_CHANNEL is alpha, configure Updatum with FetchOnlyLatestRelease = false and AllowPreReleases = true (and let the fallback pipeline accept pre-releases on that channel). The Settings label would then match the real behavior.
  • Option A, alpha channel follows the build: when AppVersionInfo.Version has a pre-release label, set FetchOnlyLatestRelease = false and AllowPreReleases = true, so alpha installs track alphas and stable installs stay on stable.
  • Option B, explicit opt-in: an "Update channel: Stable / Alpha" setting that switches the same two Updatum properties.
  • Option C, minimum: if alpha self-update isn't intended, have alpha builds show "Alpha builds don't auto-update; see Releases" instead of "up to date".

Side note: the same panel shows Install type: Unpackaged (developer) for a normal Setup-installer install. SettingsAppInfoProjection.InstallKind maps every non-MSIX install to that label, even though this install runs the regular release update check. A plain "Unpackaged" or "Installer" label would avoid suggesting it's a dev build.

Related context: docs/VERSIONING.md notes that alpha release objects older than 30 days are deleted, which makes it more likely that alpha users end up on stale, unpublished builds without being told.

Reported by @Speculorum9. Investigation done with Claude Code (read-only: local settings and log files, GitHub API, source review).

Dominant language
C#
Stars
2.1k
Forks
315
Avg merge
2d 1h
Merged PRs (30d)
127

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.