Migrate from the Inno (.exe) app to the Store MSIX

[natalie-aguinaldo]

Inno-to-Store MSIX migration

Problem

Users may install the Store MSIX while the Inno version of OpenClaw Companion is still installed. The packages share settings, credentials, identity, ports, and the managed WSL gateway, so they cannot safely run as separate production copies.

In this issue, Inno means the current .exe-installed, non-MSIX version of OpenClaw Companion.

The current Inno uninstall path may also remove the managed WSL gateway and its contained Node.js runtime.

What migration preserves

Migration preserves everything needed for the current Windows user to continue using OpenClaw in MSIX:

• Application settings and Local AI configuration
• Credentials, identity, and approvals
• Startup preference
• Saved gateway connection and management information
• The existing managed WSL gateway and its contained Node.js runtime

The WSL gateway remains in place and is adopted by MSIX rather than copied or recreated. Application binaries and Windows-installed Node.js are not migrated or removed.

Proposed direction

Use a user-directed handoff with an automatic migration after confirmation:

1. Inno shows an Install Store version and migrate action that explains that opening the Store version will migrate the user's OpenClaw setup.
2. When selected, Inno creates a same-user-protected migration-intent record before opening the Store listing.
3. On launch, MSIX validates the intent and starts migration automatically. If no valid intent exists, MSIX asks the user to Migrate or choose Not now.
4. After valid intent or confirmation, MSIX requests Inno to exit, verifies that it stopped, and automatically imports and validates the protected migration state.
5. MSIX adopts the existing WSL gateway rather than replacing it.
6. After migration succeeds, both apps keep normal production features inactive and direct the user to uninstall Inno through Windows Settings.
7. The Inno uninstaller preserves the migrated state and gateway.
8. MSIX verifies that Inno is gone, applies the migrated startup preference, and starts normally.

The migration-intent record remains available for safe retries and is cleaned up after migration finalization. If migration fails, Inno remains installed and the user can retry without losing recoverable state. Only one production Companion may be active during the handoff.

Implementation plan

Incomplete migration behavior must remain disabled until the full prepare, import, validation, uninstall guidance, and recovery path has been validated.

Phase 1: Inno migration foundation

• Define and version the migration-state contract.
• Create a same-user-protected migration-intent record before Inno opens the Store listing.
• Implement the Inno-side operation required to expose or export the migration state.
• Protect sensitive data so only the same Windows user can use it.
• Define a completed-migration marker that is recorded only after MSIX successfully imports and validates the state.
• Store the state and marker outside paths removed by Inno uninstall.
• With a valid marker, prevent normal Inno operation and preserve the state and gateway during uninstall.
• Without a valid marker, keep the existing uninstall behavior.

Phase 2: MSIX migration path, disabled

• Detect a supported Inno installation and stop it gracefully before migration.
• Import and validate the protected state while Inno remains installed.
• Adopt the existing managed WSL gateway without creating a replacement.
• Preserve, but do not enable, the MSIX startup preference until Inno is removed.
• Retain recoverable state after failure and record the completion marker only after successful validation.
• Clean up temporary migration data without removing the marker needed by Inno uninstall.

Validate this complete path while it remains disabled for users.

Phase 3: Migration UI and rollout

• Add the Inno Store-install action and the MSIX migration experience.
• Start migration automatically after validating Inno-recorded intent; otherwise require confirmation in MSIX.
• Add Windows Settings uninstall guidance after successful migration.
• Handle normal launch, auto-start, and openclaw: activation consistently.
• Enable migration only for supported Inno versions and matching architectures.

Migration UI states

The MSIX UI must cover:

• Migration available: If no valid Inno-recorded intent exists, explain that Inno was detected and offer Migrate to Store version and Not now actions.
• Migration in progress: Show a spinner and status message. Do not show a progress bar unless the migration operation provides meaningful live progress.
• Migration failed: Explain that Inno remains available and offer a Retry action.
• Migration complete: Explain that the setup was migrated successfully and provide an Open Installed apps action so the user can uninstall Inno.
• Inno removed: Dismiss the migration UI and enable normal MSIX operation.

Suggested completion copy:

Your OpenClaw setup was migrated successfully

To finish switching to the Store version, uninstall the previous Inno app.

Open Installed apps

Open implementation questions

1. Can MSIX directly access the existing Inno settings and credentials, or must Inno export them to a protected migration file first?
2. How will existing users receive the minimum migration-capable Inno release?
3. How will MSIX adopt ownership of the existing WSL gateway without recreating it or losing the ability to manage and remove it?

Release validation

Validate signed x64 and ARM64 packages:

• Inno opens the correct Store listing and explains the migration.
• Valid Inno-recorded intent starts migration automatically in MSIX.
• Without valid intent, MSIX requires confirmation; Not now leaves Inno unchanged and MSIX inactive.
• MSIX migrates only after valid intent or confirmation and while Inno is not running.
• Migration preserves user state, the managed WSL gateway, and its contained Node.js.
• After migration succeeds, neither app returns to normal operation until Inno is removed.
• After Inno removal, MSIX applies the startup preference and starts with the migrated state.
• Failed, cancelled, or interrupted migration can be retried without losing recoverable state.
• Unsupported versions and architectures are blocked with clear guidance.
• Remote-gateway configurations do not require local WSL or Node.js.
• Auto-start and openclaw: activation work after migration.
• Windows Node.js remains untouched.

Support is limited to x64-to-x64 and ARM64-to-ARM64 migration.

Out of scope

• Running Inno and MSIX simultaneously
• MSIX-to-Inno migration
• Automatic Inno update or uninstall
• Backup, restore, or rollback
• Runtime-type migration
• Cross-user or cross-architecture migration
• Automatic removal of Windows Node.js

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 17, 2026, 5:20 PM ET / 21:20 UTC.

Summary
The migration remains necessary. Current main provides MSIX packaging and startup support, but explicitly leaves the validated handoff and migration-aware uninstall preservation unimplemented. The revised discussion meaningfully narrows preservation to successful migration rather than changing every uninstall.

Reproducibility: not applicable. as a new migration capability. Source confirms the existing destructive silent-uninstall path and missing handoff, but no Windows migration or destructive reproduction was executed.

Root-cause cluster
Relationship: canonical
Canonical: #1374
Summary: This issue owns migration; packaging and Store distribution are related dependencies with explicitly separate scope.

Members:

• adjacent_distinct: feat: add Microsoft Store MSIX packaging #1328 - Merged packaging and startup support explicitly leave migration unresolved.
• adjacent_distinct: chore(ci): build MSIX artifacts and publish Store alpha assets #1403 - Merged CI submission-asset work explicitly excludes migration.
• adjacent_distinct: Enable Microsoft Store distribution (lift the MSIX publish pause) #1375 - The open distribution decision excludes this migration lifecycle.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should the revised validate-before-uninstall handoff, with preservation authorized only by a completed migration marker, become the supported Inno-to-Store contract?	Approve the conditional handoff for staged implementation: Keep user-facing migration disabled until the protected state contract, uninstall coordination, and signed architecture-specific lifecycle validation are complete.

Why: This chooses permanent uninstall and recovery semantics across two packages; existing packaging approval does not resolve that product and security boundary.

Next step
Obtain product and security approval before splitting the cross-installer lifecycle into staged PRs; this broad, security-sensitive feature is outside automatic repair intake.

Security
Needs attention: Credential and approval migration requires an explicit protection and authorization design before implementation.

Review details

Best possible solution:

Provide a staged migration wizard with protected, validated state transfer, conditional uninstall preservation, retry recovery, and startup activation only after safe Inno removal.

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

Not applicable as a new migration capability. Source confirms the existing destructive silent-uninstall path and missing handoff, but no Windows migration or destructive reproduction was executed.

Is this the best way to solve the issue?

Unclear until the lifecycle contract is approved. Validating state before removal is a sound direction, but marker authorization, retry behavior, minimum versions, and mutex release must be specified.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The minimum migration-capable Inno version and its delivery path are unresolved; older silent uninstallers can still destroy the gateway.
• The protected intent, exported credentials, completion marker, and interrupted-retry semantics lack an approved security contract.
• An inactive Store migration screen could still hold the shared mutex and block Inno uninstall unless the handoff explicitly handles mutex ownership.
• Signed x64 and ARM64 migration, retained-state upgrade, and recovery behavior have not been established by the packaging evidence.

Codex review notes: model internal, reasoning medium; reviewed against 33839971e315.

Label changes

Label justifications:

• P0: The migration intersects a source-confirmed destructive uninstall path that can remove the existing managed gateway and its data.
• impact:data-loss: Preservation must prevent gateway unregister and generated-state deletion during the package transition.
• impact:security: The proposed handoff transfers credentials, device identities, and approvals through persistent migration records.

Evidence reviewed

Security concerns:

• [medium] Define authority for persistent migration records
  The proposed intent and completion records control credential import and destructive-uninstall preservation; their validation, tamper resistance, retry lifetime, and cleanup semantics remain design questions, not established implementation defects.
  Confidence: 0.94

What I checked:

• Current implementation explicitly leaves migration open: DEVELOPMENT.md documents shared identity/state, first-launch-wins activation, competing startup registrations, and missing legacy-install detection and consent-based migration. This is a distinct remaining capability, not completed packaging work. (DEVELOPMENT.md:383, 33839971e315)
• Destructive uninstall path remains: EnsureLocalGatewayCleanupChoice requests cleanup automatically for silent uninstall. The helper invokes WSL unregister and removes gateway artifacts; there is no completed-migration marker check in the inspected installer. Existing source-contract tests explicitly cover this cleanup behavior. (installer.iss:204, 33839971e315)
• Gateway deletion reaches the final operation: The uninstall helper terminates and unregisters the managed distro, then removes its directory and Windows-side artifacts. Preserving a migrated gateway therefore requires changing this lifecycle deliberately. (scripts/Uninstall-LocalGateway.ps1:676, 33839971e315)
• Existing startup arbitration is not a migration workflow: OnLaunchedAsync acquires the shared mutex and forwards activation to the existing process when it cannot own it. It does not validate migration intent or wait for Inno uninstall before normal operation. (src/OpenClaw.Tray.WinUI/App.xaml.cs:541, 33839971e315)
• Related merged work preserves this issue's boundary: feat: add Microsoft Store MSIX packaging #1328 (feat: add Microsoft Store MSIX packaging) explicitly excludes automatic migration and legacy-install detection. chore(ci): build MSIX artifacts and publish Store alpha assets #1403 (chore(ci): build MSIX artifacts and publish Store alpha assets) also leaves migration separate. The prepared screenshots show Dev package registration, packaged runtime, and consent UI, not an Inno-to-Store handoff.
• Latest release and current-main distinction: GitHub reports v2026.9.4 as the latest release. The inspected installer, launch, identity, and CLI-uninstall files have no delta between that tag and current HEAD. Current release documentation permits unsigned alpha submission assets while keeping Store distribution and official lifecycle acceptance gated. (docs/RELEASING.md:194, 33839971e315)

Likely related people:

• natalie-aguinaldo: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Ranjesh: 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.