[Bug]: Store uninstall leaves managed Gateways behind and reinstall does not refresh them #1712

Activity

1. github-project-automation

   added this to Windows Companion Appon Oct 12, 2026
2. github-project-automation

   moved this to Backlog in Windows Companion Appon Oct 12, 2026
3. joelagnel commented on Oct 12, 2026

   

   joelagnel

   on Oct 12, 2026

   Last edited by joelagnel

   CollaboratorAuthor

   More actions

   Reproduction screenshots from the Windows 11 ARM64 test machine:

   After Windows Settings uninstall, the production Companion is absent and the separately installed Store Gateway remains. The native Gateway was acquired directly through WinGet, so this image shows independent package retention.

   

   After reinstalling and launching Store Companion 2026.9.803.0, the pre-existing WSL Gateway still reports 2026.9.8.

   

   The WSL reinstall behavior is confirmed: Gateway stayed at 2026.9.8, although 2026.10.2 was available and ran from a separate temporary installation on the Windows 11 ARM64 test machine.

   This confirms that reinstalling and launching Companion does not automatically refresh the retained WSL Gateway. The test used the same current Store Companion version; a two-version Companion upgrade, the native Gateway update case, and full WSL setup remain unverified.
4. clawsweeper

   added

   P2Normal priority bug or improvement with limited blast radius.Normal priority bug or improvement with limited blast radius.

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.User-facing flow adds avoidable confusion or support burden without fully blocking progress.

   issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.Thin issue quality; more reproduction proof or environment detail is needed.

   on Oct 12, 2026
5. clawsweeper commented on Oct 12, 2026

   

   clawsweeperBot

   on Oct 12, 2026 – with ClawSweeper

   More actions

   Codex review: this still needs some work.

   Summary
   Keep open for a lifecycle decision: current main does not implement the requested behavior, but retention and skipping healthy-package upgrades are documented choices rather than a demonstrated compatibility defect.

   Reproducibility: The inspected screenshots and current source establish retention and deliberate native-package reuse; they do not establish a current-main compatibility failure or failure of full Gateway provisioning.

   Maintainer decision needed

   • Question: Should Companion preserve retained Gateways with explicit cleanup and compatibility recovery, or introduce automatic cleanup and refresh across its Store lifecycle?
   • Recommendation: Preserve state and add focused recovery: Keep Gateway state across Companion removal, define ownership-aware cleanup, and provide an in-product Diagnose/Fix path for confirmed incompatibility.
   • Why: The requested behavior changes documented retention and upgrade policies, and the supplied proof does not establish a compatibility failure or a safe uninstall mechanism.

   Next step
   Decide the retention and cleanup contract, then establish an incompatible retained-Gateway regression to scope a data-preserving Diagnose/Fix action.

   Review details

   Best possible solution:

   Provide a data-preserving Diagnose/Fix action for retained Gateways and explicit ownership-aware removal before attempting automatic cleanup.

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

   The inspected screenshots and current source establish retention and deliberate native-package reuse; they do not establish a current-main compatibility failure or failure of full Gateway provisioning.

   Is this the best way to solve the issue?

   Automatic deletion and upgrading are not yet justified; separate data-preserving compatibility recovery from ownership-aware removal and decide the lifecycle contract before implementation.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • Automatic cleanup must distinguish uninstall from application updates and prove ownership before deleting Gateway installations or user state.
   • The native screenshot concerns an independently installed package, so it cannot establish Companion-owned removal obligations.
   • No current-main incompatible retained-Gateway reproduction, full WSL reprovisioning result, or two-version Store upgrade result establishes the proposed repair boundary.

   Codex review notes: model internal, reasoning medium; reviewed against 16299381a4df.

   Label changes

   Label changes:

   • add P2: Retention and reinstall expectations create a concrete recovery concern, but this issue does not demonstrate blocked chat, data loss, or incompatible execution.
   • add impact:ux-friction: Removing and reinstalling Companion can leave users confused about retained Gateways, and native refresh guidance currently requires a terminal command.
   • add issue-rating: 🦪 silver shellfish: 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:

   • P2: Retention and reinstall expectations create a concrete recovery concern, but this issue does not demonstrate blocked chat, data loss, or incompatible execution.
   • impact:ux-friction: Removing and reinstalling Companion can leave users confused about retained Gateways, and native refresh guidance currently requires a terminal command.

   Evidence reviewed

   What I checked:

   • Current main verified: GitHub's default branch is main, and its SHA matches the clean review checkout. No builds, tests, or checkout mutations were performed. (16299381a4df)
   • Reporter proof inspected: joelagnel's screenshots show the production Companion absent while an independently acquired Gateway remains, then Companion 2026.9.803.0 alongside WSL Gateway 2026.9.8. The accompanying comment explicitly excludes full reprovisioning and an older-to-newer Store Gateway upgrade. These establish retention, not an incompatible reuse failure.
   • MSIX retention is documented: The repository documents the absence of an arbitrary MSIX uninstall hook and recommends Remove Local Gateway before uninstalling Companion. (docs/uninstall-msix.md:8, 16299381a4df)
   • Existing in-product WSL removal guidance: Settings warns that Windows Settings uninstall will leave the WSL Gateway and disk image, and exposes Remove Local Gateway. (src/OpenClaw.Tray.WinUI/Pages/SettingsPage.xaml:483, 16299381a4df)
   • Native acquisition intentionally reuses registration: EnsureAsync returns a resolved package before invoking installation; PresentPackage_DoesNotOpenInstallerOrReportWaiting protects that behavior. The installer also passes --no-upgrade. (src/OpenClaw.SetupEngine/NativeGatewayPackageAcquisition.cs:37, 16299381a4df)
   • Upgrade policy and recovery guidance: Native onboarding documentation explicitly avoids silently upgrading healthy installations and supplies an explicit WinGet refresh command. (docs/ONBOARDING_WIZARD.md:201, 16299381a4df)

   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; those execution lanes are retired.
   • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

   Reviewed October 12, 2026, 4:50 PM ET / 20:50 UTC.
6. joelagnel commented on Oct 15, 2026

   

   joelagnel

   on Oct 15, 2026

   CollaboratorAuthor

   More actions

   Fixed by merged PR #1715 (fix(setup): clean up owned Gateways after Companion uninstall), merge commit 62752f44cda2f92e44c9fc2dd42f6415a65c1884.

   The merged change adds ownership-aware cleanup after Windows Settings uninstall, selective connection/authentication reconciliation after reinstall, recovery when cleanup cannot safely proceed, and native Store Gateway update checks. Independently installed, replaced, uncertain, or shared Gateways are preserved under the documented ownership rules.

   Validation on Windows 11 ARM64 passed the full build and Shared/Tray/SetupEngine suites, controlled ownership regressions, and real signed-MSIX/WSL update/uninstall/reinstall checks. Published lifecycle/recovery proof and detailed validation limits are in the merged PR.

   Closing as completed. The separately reported native Local AI runtime failure remains tracked in #1713; merged PR #1716 (fix(setup): preserve sanitized Local AI verification errors) improves its diagnostics.
7. joelagnel

   closed this as completedon Oct 15, 2026
8. samanthamsong

   removed this from Windows Companion Appon Oct 16, 2026
9. github-actions

   locked as resolved and limited conversation to collaborators on Oct 18, 2026