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

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
desktop, release

Research direction

Start with src/OpenClaw.Connection/Migration/InnoInstallationDetector.cs at the linked validation and version checks, then read the historical v0.6.12 installer.iss uninstall behavior. Trace the Store migration and gateway recovery entry points using the reported clawctl setup and gateway-service commands. Done means a supported, identity-preserving recovery flow with cancellation handling and upgrade coverage for stale Inno metadata and a missing gateway helper.

Written by the indexing model from the issue text.

Description

bug clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-release-blocker issue-rating: 🦞 diamond lobster P0

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.

Dominant language
C#
Stars
2.2k
Forks
336
Avg merge
3d 18h
Merged PRs (30d)
177

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.