Skip to content

Inno "Installed apps" registration stays at the original version after in-app updates — the stale-metadata sequence behind #1592 #1676

Open
Open
Inno "Installed apps" registration stays at the original version after in-app updates — the stale-metadata sequence behind #1592#1676
Labels
P2Normal priority bug or improvement with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.no-staleExempts this issue from stale automation.

Description

@Speculorum9
Speculorum9
opened on Oct 8, 2026

Summary

The Windows uninstall registration for the Inno-installed Companion (HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\{M0LTB0T-TRAY-4PP1-D3N7}_is1) keeps the version and install date of the first install after the app is upgraded, both by the built-in updater and by running a newer OpenClawCompanion-Setup-x64.exe. Settings → Apps and anything that reads this key (support checks, inventory tools, and possibly the Store migration's previous-installation validation, see #1592) see a version that no longer exists. #1592 notes that "the earlier update sequence that produced the stale registration has not been established"; this report documents one such sequence.

Environment

  • Windows 11 Home, build 10.0.26300, x64; per-user Inno install in %LOCALAPPDATA%\OpenClawTray
  • Inno Setup version recorded in the key: 6.7.1

Sequence observed (one machine, all dates 2026)

Date Action Exe version afterwards Uninstall key afterwards
Oct 3 Fresh Setup install, v2026.9.5-alpha.93 2026.9.5-alpha.93 DisplayVersion 2026.9.5-alpha.93, InstallDate 20261003
Oct 5 ~19:59 Ran OpenClawCompanion-Setup-x64.exe for v2026.9.5-alpha.97 over the existing install (signature valid, SHA-256 matched the release asset) 2026.9.5-alpha.97 unchanged: still 2026.9.5-alpha.93 / 20261003, although unins000.exe/unins000.dat in the install folder were rewritten at 2026-10-05 19:59 (so Setup did run)
Oct 7 21:00 Built-in updater: "Update available: v2026.9.8-1" → Download → "Installing update and restarting..." 2026.9.8-1 (2026.9.8-1+2ba89f37…, signature Valid, OpenClaw Foundation) unchanged: still 2026.9.5-alpha.93 / 20261003
Oct 7 21:04 Windows reboot 2026.9.8-1 unchanged

Current key (non-sensitive fields): DisplayName = OpenClaw Companion version 2026.9.5-alpha.93, DisplayVersion = 2026.9.5-alpha.93, InstallDate = 20261003, MajorVersion = 2026, MinorVersion = 9, Publisher = OpenClaw Foundation, InstallLocation = %LOCALAPPDATA%\OpenClawTray\, Inno Setup: Setup Version = 6.7.1.

Likely causes (two paths)

  1. Built-in updater: App.xaml.cs configures Updatum with InstallUpdateSingleFileExecutableName = "OpenClaw.Tray.WinUI", so the in-app update replaces the program files directly rather than running the Inno installer, and nothing rewrites the Inno uninstall key. Every in-app update widens the gap between the registration and the real version.
  2. Setup reinstall: a newer Setup run over an existing install rewrote unins000.* but did not refresh DisplayVersion/DisplayName/InstallDate in the existing _is1 key. I haven't determined why (installer script settings vs. Inno behavior with this AppId).

Expected

After any successful upgrade path, the uninstall registration reflects the installed version (at least DisplayVersion/DisplayName), so Settings → Apps, support diagnostics and the Store migration's previous-installation checks see the truth.

Suggested direction (maintainers' call)

  • After an in-app update succeeds, refresh DisplayVersion/DisplayName (and optionally MinorVersion/InstallDate) in the Inno _is1 key, or have the updater run the signed Setup package instead of replacing files.
  • Check that the Setup script updates the existing uninstall key on reinstall.
  • For [Bug]: Store migration dead-ends on legacy Inno metadata and requires manual recovery #1592: if migration validation reads this key, validate against the executable's version (or both), since the key can be stale.

Screensnip of the previous version showing in Windows' "Settings"->"Apps"

Image

Activity

  1. github-project-automation
    added this to Windows Companion Appon Oct 8, 2026
  2. clawsweeper
    added
    P2Normal priority bug or improvement with limited blast radius.
    clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.
    clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.
    clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.
    impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.
    issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.
    no-staleExempts this issue from stale automation.
    on Oct 8, 2026

  3. clawsweeper commented on Oct 8, 2026

    @clawsweeper
    clawsweeperbot
    on Oct 8, 2026 – with ClawSweeper

    Codex review: this still needs some work.

    Summary
    The corrected report establishes an in-app update metadata defect that remains on current main. Setup reinstalls are no longer implicated, and no inspected open PR owns the registration refresh.

    Reproducibility: yes. current source establishes portable file replacement without registration refresh, corroborated by the reporter's corrected alpha.97-to-2026.9.8-1 observations. No current-main failing run was executed.

    Next step
    A focused worker can establish a failing regression and repair version consistency without new configuration; coordinate with the existing queued implementation.

    Review details

    Best possible solution:

    Use a focused installation-metadata owner to reconcile an existing matching Inno registration with the successfully running release while preserving portable, development, Store, and migration behavior.

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

    Yes: current source establishes portable file replacement without registration refresh, corroborated by the reporter's corrected alpha.97-to-2026.9.8-1 observations. No current-main failing run was executed.

    Is this the best way to solve the issue?

    Yes: narrowly reconciling matching installation metadata is preferable to changing update packaging or weakening migration checks; the withdrawn Setup-reinstall claim needs no repair.

    AGENTS.md: found and applied where relevant.

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

    Label changes

    Label changes:

    No label changes.

    Label justifications:

    • P2: The update succeeds, but installed-version inventory remains incorrect; this report establishes no blocked startup.
    • impact:ux-friction: Installed apps displays an outdated version and winget offers an upgrade to the version already running.
    Evidence reviewed

    Acceptance criteria:

    • ./build.ps1
    • dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
    • dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
    • dotnet test ./tests/OpenClaw.Connection.Tests/OpenClaw.Connection.Tests.csproj --no-restore
    • Establish a base-failing metadata regression and preservation coverage for missing, mismatched, portable, development, packaged, and failed-update cases.

    What I checked:

    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.

    Reviewed October 8, 2026, 6:43 PM ET / 22:43 UTC.

  4. clawsweeper commented on Oct 8, 2026

    @clawsweeper
    clawsweeperbot
    on Oct 8, 2026 – with ClawSweeper

    🦞⚠️
    Automatic implementation stopped before completion.
    Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
    Worker: https://github.com/openclaw/clawsweeper/actions/runs/37873534034

  5. Speculorum9 commented on Oct 8, 2026

    @Speculorum9
    Speculorum9
    on Oct 8, 2026
    Author

    Correction, and runtime evidence for the in-app path

    You're right about the Setup-reinstall claim. Please disregard it: Setup updated the registration correctly. My registry reads (showing alpha.93 / InstallDate 20261003) came from tooling launched inside a packaged (MSIX) desktop app, whose merged per-package registry view apparently shadowed the real key with a stale copy. Windows itself, via Settings → Apps (the screenshot) and winget, shows the real registration.

    Corrected sequence on this machine (Windows 11 Home 26300, per-user Inno install):

    Date Action Real registration (Settings / winget) Running executable
    Oct 3 Setup install 2026.9.5-alpha.93 2026.9.5-alpha.93
    Oct 5 Setup reinstall (OpenClawCompanion-Setup-x64.exe) 2026.9.5-alpha.97, dated 10/5 ✓ 2026.9.5-alpha.97
    Oct 7 21:00 In-app update ("Update available: v2026.9.8-1" → Download → "Installing update and restarting...") still 2026.9.5-alpha.97 ✗ 2026.9.8-1 (2026.9.8-1+2ba89f37…, signature valid)
    Oct 7 21:04 Windows reboot still 2026.9.5-alpha.97 2026.9.8-1

    This is a runtime confirmation of the in-app path you identified from source (registration vs. executable, as in your acceptance criteria).

    One more user-visible consequence: winget list --name OpenClaw reports

    Name                                         Id                         Version           Available
OpenClaw Companion version 2026.9.5-alpha.97 OpenClaw.OpenClawCompanion 2026.9.5-alpha.97 2026.9.8-1

    so winget offers an "upgrade" to the version that is already installed and running. A winget upgrade here would run the Setup package again; I haven't tried it.

    @clawsweeper re-review

  6. Speculorum9
    changed the title [-]Inno "Installed apps" registration stays at the original version after in-app updates (and after a Setup reinstall) — the stale-metadata sequence behind #1592[/-] [+]Inno "Installed apps" registration stays at the original version after in-app updates — the stale-metadata sequence behind #1592[/+] on Oct 8, 2026

  7. clawsweeper commented on Oct 8, 2026

    @clawsweeper
    clawsweeperbot
    on Oct 8, 2026 – with ClawSweeper

    🦞👀
    Exact review queued.

    Re-review progress:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal priority bug or improvement with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.no-staleExempts this issue from stale automation.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions