Local AI: "Retry setup or download" destroys WSL sandbox, then "Install & setup" stays greyed out

[larroy]

Summary

In Local AI settings, clicking "Retry setup or download" relaunches the setup wizard and re-creates the WSL sandbox, destroying the previously working one. After this, if you navigate away and select Local AI again, the "Install & setup" button is greyed out and cannot be clicked — the whole Local AI workflow is left in a broken, unrecoverable state.

Steps to reproduce

1. Open OpenClaw Windows Companion → Local AI.
2. With llama-server in an Error state (see screenshot 1), click "Retry setup or download".
3. The OpenClaw Setup wizard opens ("Set up OpenClaw" → "Install a local gateway (WSL)"), and proceeds to re-create the WSL sandbox instead of repairing/reusing the existing one.
4. Navigate back to Local AI in settings.
5. The "Install & setup" button is now greyed out / disabled and cannot be clicked.

Expected behavior

"Retry setup or download" should repair or resume the existing Local AI/WSL setup without destroying the previously created sandbox. If a full re-create is unavoidable, the Local AI page should still leave the user with a usable, clickable path to reinstall (e.g. "Install & setup" should not be permanently disabled).

Actual behavior

• The existing WSL sandbox is destroyed and replaced by the wizard.
• After the wizard runs, re-opening Local AI shows "Install & setup" greyed out with no way to proceed, leaving Local AI unusable until a manual/reinstall workaround is found.

Screenshots

Environment

• App: OpenClaw Windows Companion
• Component: Local AI (Sandbox / WSL setup wizard)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 8, 2026, 11:53 PM ET / September 9, 2026, 03:53 UTC.

Summary
Current main still routes Local AI retry into destructive-capable onboarding. The linked recovery PR remains open, so this issue is still necessary and already has an implementation candidate.

Reproducibility: yes. for the central routing defect: current source connects retry to general onboarding and destructive-capable provisioning. No runtime reproduction was performed, and permanent button disablement is not established.

Next step
Review and resolve #1357 before closing this issue; its explicit ownership rules out a duplicate repair PR.

Review details

Best possible solution:

Provide an owner-bound in-app Repair flow that preserves gateway data, refreshes eligibility, and explains recoverable hardware or networking blockers.

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

Yes for the central routing defect: current source connects retry to general onboarding and destructive-capable provisioning. No runtime reproduction was performed, and permanent button disablement is not established.

Is this the best way to solve the issue?

Yes, the linked PR's dedicated non-destructive recovery direction addresses the wrong workflow boundary; its real recovery outcome still needs validation before this issue can be resolved.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The permanent disabled-button claim remains unverified; the supplied screenshot also shows insufficient free GPU memory.
• The linked recovery PR explicitly reports that a full real existing-gateway recovery transaction and enabled recovery UI demonstration remain unverified.

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

Label changes

Label justifications:

• P0: A recovery action reaches distro-replacement setup and leaves the reported Local AI workflow without a usable recovery path.
• impact:data-loss: The retry route can reach unregister and deletion of the existing app-owned WSL distro.
• impact:ux-release-blocker: The report describes blocked in-product Local AI recovery requiring a manual or reinstall workaround.

Evidence reviewed

What I checked:

• Current retry route remains unchanged: RetrySetup invokes ShowOnboarding. WindowManager opens general setup, and the current missing-model test explicitly expects that onboarding call. (src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs:191, eef8dcd63d58)
• Provisioning can delete the managed distro: The default pipeline includes distro cleanup and recreation. Cleanup unregisters a registered distro after ownership validation; proving app ownership does not preserve its existing contents. The default configuration enables CleanBeforeRun. (src/OpenClaw.SetupEngine/CleanupStaleDistroStep.cs:83, eef8dcd63d58)
• Screenshots corroborate the blocked workflow: Both prepared images were inspected. They show general onboarding beside Local AI in Error, followed by a disabled Install & setup button. The second image reports only 1.9 GiB free against 30.3 GiB required. This supports an eligibility-related block, but does not independently establish permanent disablement or completed distro deletion.
• Install eligibility is explicitly gated: The install button requires an eligible Local AI selection and any necessary networking consent while Local AI is enabled. This explains why the screenshot alone cannot establish a stale-button defect. (src/OpenClaw.SetupEngine.UI/Pages/CapabilitiesPage.xaml.cs:782, eef8dcd63d58)
• Recovery work already has an open owner: Add non-destructive Local AI recovery #1357 explicitly targets this issue and supersedes the closed, unmerged Fix Local AI retry recovery #1342. REST verification confirms the replacement is open, draft, and unmerged at aec6435. Its supplied body records substantial automated coverage but explicitly leaves the full real existing-gateway recovery transaction and enabled WinUI recovery proof unverified. (aec6435525d7)
• Latest supplied release retains the same retry route: The v2026.7.1-4 source also routes RetrySetup to ShowOnboarding; no shipped resolution was established. (src/OpenClaw.Tray.WinUI/Presentation/LocalAiPageViewModel.cs:191, c7c6fb06be03)

Likely related people:

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