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

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

No files, tests, or entry points are named. Start by mapping the Inno and MSIX migration boundaries, including protected intent/state, WSL gateway adoption, uninstall preservation, and recovery behavior. Done means the complete prepare, import, validation, UI, uninstall-guidance, and retry path is validated for supported x64-to-x64 and ARM64-to-ARM64 packages while disabled until rollout.