Setup fails at wsl-create step: `Wsl/InstallDistro/0x800072f78` on Windows 26200 + WSL 2.7.3

[simonxk]

Title: Setup fails at wsl-create step: Wsl/InstallDistro/0x800072f78 on Windows 26200 + WSL 2.7.3

Describe the bug
OpenClawTray setup pipeline fails consistently at the "Create WSL instance" step. The installer attempts wsl --install --distribution Ubuntu-24.04 --name OpenClawGateway --location %LOCALAPPDATA%\OpenClawTray\wsl\OpenClawGateway --no-launch --web-download, which exits with code -1 after ~62 seconds. Error detail: Wsl/InstallDistro/0x800072f78.

A manual workaround (wsl --import OpenClawGateway ...) succeeds, but the installer's cleanup-distro step detects the manually-created distro as "stale" and unregisters it before re-attempting the same failing wsl --install command.

To Reproduce

1. Windows 10.0.26200.0 (64-bit), WSL version 2.7.3.0
2. Existing WSL distro: Ubuntu-24.04 (working normally)
3. Run OpenClawTray setup → pipeline fails at step 7/17 (wsl-create)

Expected behavior
Setup should either succeed at creating the WSL distro, or detect a manually-imported distro and skip the creation step.

Logs
Attached: setup-engine-20260724-154855.jsonl
Key lines:

• Line 16: Detects existing OpenClawGateway, decides to terminate and unregister it
• Line 35-37: Re-attempts wsl --install ... --location %LOCALAPPDATA%\... --web-download, fails after 62157ms with exit -1
• Line 40: Step marked Failed: Fresh WSL install failed ... Wsl/InstallDistro/0x800072f78

Additional context

• Port 18789 is available
• Existing Ubuntu-24.04 WSL distro works fine (wsl -d Ubuntu-24.04 succeeds)
• Manual wsl --import to the same target path works, but installer deletes it on next run
• WSL kernel: 6.6.114.1-1
• Log files at %APPDATA%\OpenClawTray\Logs\Setup\setup-engine-20260724-*.jsonl

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 24, 2026, 12:09 PM ET / 16:09 UTC.

Summary
Keep open. Current main still treats any registered OpenClawGateway distro as stale and unregisters it before retrying the same direct WSL install, so it does not preserve the reporter's manual recovery path or explain this specific WSL install failure.

Reproducibility: no. high-confidence live reproduction of the Windows-specific 0x800072f78 is available here. The destructive portion is source-reproducible: with CleanBeforeRun enabled, any registered distro named OpenClawGateway is terminated and unregistered before creation.

Ways to help us reproduce this

• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should setup support explicit adoption of a manually imported OpenClawGateway distro after direct WSL installation fails, or should it preserve that distro and direct the user to a separate supported recovery path?	Add verified recovery adoption: Require deterministic freshness and lockdown validation plus explicit user confirmation before setup continues with an imported distro.

Why: Current code cannot distinguish a trusted setup-created distro from a user-imported one based on name and location alone; accepting it changes the provisioning trust boundary, while deleting it removes the only reported recovery route.

Next step
A concrete repair is likely, but maintainers must first choose the supported trust and recovery policy for externally imported WSL distributions.

Review details

Best possible solution:

Preserve the app-owned WSL security model while adding a non-destructive recovery flow: diagnose known direct-install failures, retain a manually imported target until explicit validation and confirmation, and only delete distributions the setup engine can prove it owns.

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

No high-confidence live reproduction of the Windows-specific 0x800072f78 is available here. The destructive portion is source-reproducible: with CleanBeforeRun enabled, any registered distro named OpenClawGateway is terminated and unregistered before creation.

Is this the best way to solve the issue?

Unclear. Preserving or adopting a manually imported distro is only safe after maintainers define how setup proves ownership, freshness, and required lockdown settings; unconditional cleanup is not a sufficient recovery behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reported 0x800072f78 is emitted by Windows WSL installation and its host-specific root cause is not yet identified from current source.
• Automatically adopting an imported distro without a provenance and freshness policy could weaken the app-owned WSL isolation model or retain unknown state.

Codex review notes: model internal, reasoning high; reviewed against 76f4d52c3b5e.

Label changes

Label changes:

• add P0: A first-time user is blocked from completing setup, and the only reported recovery requires terminal work that the next setup run removes.
• add impact:data-loss: The current cleanup path unregisters the manually imported recovery distribution and deletes its VHD directory.
• add impact:ux-release-blocker: There is no in-product route past the failed WSL creation step, and recovery currently requires unsupported technical commands.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: 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:

• P0: A first-time user is blocked from completing setup, and the only reported recovery requires terminal work that the next setup run removes.
• impact:data-loss: The current cleanup path unregisters the manually imported recovery distribution and deletes its VHD directory.
• impact:ux-release-blocker: There is no in-product route past the failed WSL creation step, and recovery currently requires unsupported technical commands.

Evidence reviewed

What I checked:

• Current cleanup behavior: CleanupStaleDistroStep lists WSL distributions and, whenever the configured distro name is present, terminates and unregisters it without recording or checking whether that distribution was created by this setup run. This matches the reported deletion of a manually imported OpenClawGateway distribution. (src/OpenClaw.SetupEngine/SetupSteps.cs:2662, 76f4d52c3b5e)
• Current creation behavior: After cleanup, the create step refuses to proceed only if the target still exists, then invokes the direct named wsl --install --distribution ... --name ... --location ... --no-launch --web-download path. Current main therefore does not provide an alternate recovery route for the reported install error. (src/OpenClaw.SetupEngine/SetupSteps.cs:3452, 76f4d52c3b5e)
• Documented lifecycle contract: The current setup architecture documents cleanup as unregistering the leftover app-owned distro and removing its VHD directory before direct creation of a fresh app-owned distro. The report exposes that name-and-location-based ownership assumption as unsafe for a manual recovery distro. (docs/SETUP_ENGINE_REDESIGN.md:396, 76f4d52c3b5e)
• Related reports are not canonical duplicates: WSL Preflight Report #694 concerned localized WSL-version parsing before distro creation, while Error on "Preparing Gateway" #638 reached gateway configuration after successful distro creation. Neither owns the reported direct-install failure plus destructive manual-recovery cleanup.

Likely related people:

• shanselman: The repository identifies Scott Hanselman as a project co-author, and this report concerns the central first-run WSL gateway provisioning path. Exact line-level ownership could not be established from the available read-only history view. (role: project co-author and likely setup-area routing contact; confidence: low; files: src/OpenClaw.SetupEngine/SetupSteps.cs, docs/SETUP_ENGINE_REDESIGN.md)

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.