[Bug]: Store migration dead-ends on legacy Inno metadata and requires manual recovery

[fuller-stack-dev]

Summary

An existing Windows Companion installation was stranded when switching to the Microsoft Store app. The Store app refused migration with generic previous-installation validation guidance; recovering a working app required inspecting registry/binary versions, manually uninstalling the old Companion without removing gateway data, independently repairing the Store gateway, and relaunching the Companion.

This is an observed legacy-upgrade/recovery case related to #1374 (closed), not a request to weaken migration identity checks. I did not find an existing issue covering this exact failure state.

Environment

• Windows 11 Pro Insider Preview, build 26340.9577, x64.
• Store Companion: OpenClawFoundation.OpenClaw_2026.9.511.0_x64__rfcbke2p71se2.
• Store Gateway: OpenClawFoundation.OpenClawGateway_2026.9.406.0_x64__rfcbke2p71se2, launcher commit f2f4930d858fb2030a81a97e1c47518de2f533d6, OpenClaw payload 2026.9.4.
• Existing per-user Inno install under %LOCALAPPDATA%\OpenClawTray: uninstall registration still reported 0.6.12 / Scott Hanselman, while the installed Companion executable reported 2026.9.4.
• Existing saved connection targeted the local gateway at ws://localhost:18789.

Observed sequence / reproduction conditions

This describes the actual machine state, not a fresh-VM reproduction; the earlier update sequence that produced the stale registration has not been established.

1. Have the legacy Inno registration and newer executable described above, plus an existing native Store gateway/session.
2. Install/open the Store Companion while the Inno installation remains present.
3. The Store app blocks normal startup and cannot complete the migration. Its user-facing explanation refers to inability to validate the prior installation's path/user/architecture; the diagnostic rejection was the production publisher/application identity mismatch.
4. The user cannot get back to a connected Store Companion through a straightforward guided recovery path.

Confirmed migration trigger

The legacy publisher is legitimate historical metadata: v0.6.12 installer.iss used Scott Hanselman.

The current detector at 7fc3f605, lines 78–85 requires the exact current display-name format and publisher OpenClaw Foundation, otherwise returning:

The Inno registration does not identify the production publisher and application.

It also requires the executable and registered versions to match. These source links explain the rejection conditions; they are not a claim that current main is identical to the shipped package. The missing piece is a supported, clearly explained recovery path for this historical install state, not blindly accepting registry values.

Separate gateway failure found during recovery

Nothing was listening on the saved local port. clawctl status --json reported an existing running isolated session and configured sign-in recovery, but gateway readiness was unknown:

the isolated-session helper has not been staged for this package version. Run `clawctl setup` again

This was independently repaired with clawctl setup --json (without --fresh or --force), followed by clawctl gateway-service start --json. Setup reused the existing session and installed the bundled Node 24.21.0 runtime. The missing helper explains the immediate readiness failure; the precise package-update transition that left it missing is not yet proven. This may warrant a separately owned follow-up.

Recovery and verified outcome

• Used the existing interactive Inno uninstaller with /NORESTART, preserving the gateway/generated state. No registry identity spoofing, fabricated migration receipts, security-policy changes, reboot, or gateway reset.
• This preservation choice matters: the historical uninstaller asks whether to remove the local WSL gateway/generated state; silent uninstall instead opts into that cleanup. A generic “just uninstall it silently” workaround is not equivalent to safe migration.
• Verified the legacy executable/uninstaller and registration were gone, then launched the Store app. Startup admission became NotRequired.
• Verified fresh operator hello-ok, successful node registration, two established loopback connections, /healthz reporting live, and the native Companion UI showing Connected with existing chat history.
• The device-key file remained byte-identical, and the active gateway ID/endpoint were retained. Settings/registry files were rewritten during app startup/reconnect; the legacy install-local exec-policy.json was removed by uninstall. This is not a claim that every original file was preserved byte-for-byte.
• Packaged Companion startup was enabled. No new model-inference test was sent.

Expected behavior / acceptance criteria

• Explain the actual rejected condition (historical publisher, stale registered version, missing migration payload, etc.), rather than presenting only broad path/user/architecture guidance.
• Provide a supported repair/update-to-migratable-version path for legitimate older installations while retaining same-user, identity and architecture validation.
• Make the preserve-data uninstall handoff explicit, observe its actual completion/cancellation, and resume Store startup afterward.
• Preflight the saved local gateway and offer the existing non-destructive helper/setup repair when required; do not leave users debugging a second independent failure after migration.
• Add upgrade/recovery coverage for historical Inno metadata with newer app files, cancellation/retry, preserved identities/settings, and an existing Store gateway missing its current-version helper.

Assisted-recovery UX note (not an established Windows defect)

During remote assistance, uninstaller launches produced a consent.exe process, but the user repeatedly reported no visible administrator prompt. The assistant incorrectly treated process existence as proof that the prompt was visible and repeated the instruction. The cause of the visibility problem was not established; the user ultimately completed the uninstall. Recovery tooling should distinguish “elevation requested” from “prompt visible” and provide a concrete manual-launch fallback instead of an acknowledgment loop.

Only redacted diagnostic facts are included here; no credentials, device IDs, private session contents, or user-specific filesystem paths are attached.

[clawsweeper]

Codex review: this still needs some work. Reviewed October 1, 2026, 10:22 PM ET / October 2, 2026, 02:22 UTC.

Summary
Keep open: current main still routes legitimate historical publisher metadata to a blocking, generic unsupported-installation screen. The merged migration work does not resolve this recovery case, and this member-authored issue requires explicit maintainer handling.

Reproducibility: yes. for the admission and guidance defect: a present executable with historical publisher metadata reaches UnsupportedInstallation and the generic blocking screen. No current-main runtime reproduction was executed; the earlier update sequence and missing-helper transition remain unknown.

Maintainer decision needed

Question	Recommendation
Should historical publisher/version mismatches recover through a verified Inno update first, or may Companion offer a separately validated preserve-data uninstall handoff?	Prefer a verified Inno update: Guide legitimate legacy users to an installer that refreshes registration and provides the existing migration safeguards before permitting removal.

Why: The old uninstaller can remove Gateway state, and current identity checks intentionally reject this installation; source inspection cannot authorize a new recovery trust contract.

Next step
Select the safe historical-install recovery contract, then split focused diagnostic guidance from Gateway package investigation; member authorship and preservation-sensitive scope exclude automatic repair intake.

Review details

Best possible solution:

Add a guided Repair action that explains the rejection, leads to a verified migration-capable update or preserve-data handoff, observes cancellation and completion, and resumes startup without weakening validation.

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

Yes for the admission and guidance defect: a present executable with historical publisher metadata reaches UnsupportedInstallation and the generic blocking screen. No current-main runtime reproduction was executed; the earlier update sequence and missing-helper transition remain unknown.

Is this the best way to solve the issue?

Unclear until the preservation contract is selected. Reason-specific guidance and a verified update path are narrower and safer than accepting stale registry identity or recommending silent uninstall.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A legitimate legacy recovery path must establish safe update or preservation behavior without treating historical registry metadata as migration authorization.
• The missing Gateway helper's package-update trigger remains unverified and should be investigated separately from Companion admission.

Codex review notes: model internal, reasoning medium; reviewed against 7fc3f605e223.

Label changes

Label changes:

• add P0: Store startup was blocked and recovery required registry/binary inspection, manual uninstall, and separate Gateway commands.
• add impact:ux-release-blocker: The unsupported-installation screen provides no guided route through this legacy upgrade state.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: 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.

Label justifications:

• P0: Store startup was blocked and recovery required registry/binary inspection, manual uninstall, and separate Gateway commands.
• impact:ux-release-blocker: The unsupported-installation screen provides no guided route through this legacy upgrade state.

Evidence reviewed

What I checked:

• Current rejection mechanism: The detector requires the current display-name format and publisher OpenClaw Foundation. Publisher rejection returns Unsupported without RegisteredVersion, so the historical numeric version cannot select the update guidance. The later executable-version check independently rejects registration/binary disagreement. (src/OpenClaw.Connection/Migration/InnoInstallationDetector.cs:78, 7fc3f605e223)
• Admission preserves the startup block: Unsupported installations select UpdateInno only when the detector supplies an unsupported-version flag or a registered version below the minimum. Otherwise an installed source selects UnsupportedInstallation and blocks startup. (src/OpenClaw.Connection/Migration/StoreMigrationStartupCoordinator.cs:108, 7fc3f605e223)
• User-visible recovery gap: Unsupported guidance names location, user, and architecture rather than publisher or stale metadata. The Installed apps action is visible only during AwaitingRemoval or Recovery, not Unsupported; Retry simply re-inspects the unchanged installation. (src/OpenClaw.Tray.WinUI/Strings/en-us/Resources.resw:7709, 7fc3f605e223)
• Historical metadata and destructive-uninstall distinction: The v0.6.12 installer identifies Scott Hanselman as publisher. Its interactive uninstall offers preservation, while silent uninstall automatically requests gateway cleanup. Therefore recommending silent uninstall is not equivalent to the reported successful preserve-data recovery. Local retrieval of this historical blob failed; its contents were inspected through the GitHub contents API instead. (installer.iss:3, 4166e0fd63f8)
• Existing validation contracts: Tests explicitly require current production name/publisher metadata and matching executable/registered versions. The repair should improve legitimate legacy recovery without removing these checks. (tests/OpenClaw.Connection.Tests/InnoInstallationDetectorTests.cs:490, 7fc3f605e223)
• Merged migration provenance: Git history and GitHub identify Natalie Aguinaldo's merged feat(migration): ship the Inno-to-Store migration #1519 (feat(migration): ship the Inno-to-Store migration), merged September 29. Inspection of its detector blob confirms the same exact publisher rejection. This establishes related shipped work, not a fix for the historical recovery gap. Line-level blame could not complete because an older blob was unavailable; no introduction attribution is claimed. (src/OpenClaw.Connection/Migration/InnoInstallationDetector.cs:82, 244f684ef291)

Likely related people:

• natalie-aguinaldo: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

[Speculorum9]

Possibly related root cause: #1676 documents a sequence that leaves the Inno uninstall registration stale: in-app (Updatum) updates replace the program files without touching the _is1 key, so the registered version stays at the last Setup-installed version while the executable moves on. (A Setup reinstall does update the key correctly.) That may be how this machine ended up with "0.6.12" registered while the executable was 2026.9.4.

Edited: removed an incorrect claim about Setup reinstalls; see the correction in #1676.