Setup: 'preflight-wsl' failure message uses x86 firmware terminology on ARM64

[RBrid]

Setup: preflight-wsl failure message uses x86 firmware terminology on ARM64

What happened

On a Microsoft Cadmus ARM64 device, running OpenClaw Setup against the latest master produced this dialog:

Setup failed

Step 'preflight-wsl' failed: WSL2 requires hardware virtualization, but it is disabled in firmware. Enable VT-x/AMD-V (Intel VT or AMD SVM) in your computer's BIOS/UEFI settings, reboot, then retry setup.

Why this matters

The error text is x86-centric:

• "VT-x/AMD-V"
• "Intel VT or AMD SVM"
• "BIOS/UEFI settings, reboot"

None of those terms apply on an ARM64 device. ARM64 uses ARMv8 EL2 virtualization extensions; on Cadmus / Surface-class hardware, it's typically controlled by a generic "Virtualization Support" UEFI toggle or by an Intune / management policy (HVCI, Pluton, "Memory integrity"), not a BIOS hotkey trip.

A user on ARM64 reading this message is sent looking for a setting that doesn't exist on their machine.

Suggested fix

Branch the remediation wording on RuntimeInformation.OSArchitecture:

• x64/x86: keep the existing "Enable VT-x/AMD-V (Intel VT or AMD SVM)…" text.
• Arm64: something like "Enable virtualization in your device's UEFI settings (look for 'Virtualization Support' or similar). On managed devices this may be controlled by your organization's Intune policy (Memory Integrity / Pluton / HVCI). Reboot and retry setup."

Location: the branch that emits the message lives in src/OpenClaw.SetupEngine/SetupSteps.cs around lines 96-106 (the Contains(text, "virtualization is not enabled") branch in the helper that translates wsl.exe output into actionable messages).

Repro

1. Microsoft Cadmus ARM64 device with hardware virtualization disabled (firmware or Intune policy).
2. Latest master (after commit 91067255 — "Fix local dev setup on launcher branch", May 28 2026, which added this detection branch).
3. Run OpenClaw Setup → reaches preflight-wsl → fails with the x86-only message above.

Notes

• The detection itself is not a false positive — we only show the message when wsl.exe prints "virtualization is not enabled". The underlying issue (no hypervisor) is real on the reporter's machine.
• This is purely a UX/wording bug for ARM64 devices.
• First-seen: ~1 day after the detection branch landed.

Environment

• OS: Windows 11 ARM64 (Cadmus)
• App: OpenClaw Tray Setup, master at HEAD ~2026-05-29
• Step: preflight-wsl

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 29, 2026, 7:55 PM ET / 23:55 UTC.

Summary
Keep open: current master still emits the x86-specific VT-x/AMD-V BIOS guidance for every WSL “virtualization is not enabled” diagnostic, and the existing tests assert that wording, so the ARM64 setup UX bug remains actionable.

Reproducibility: yes. from source inspection: feeding the observed WSL virtualization-disabled text into WslInstallSupport.TryGetEnvironmentIssue on current master returns the x86 BIOS/VT-x/AMD-V guidance with no ARM64 branch. I did not run a live ARM64 Windows setup session in this read-only review.

Next step
A narrow repair PR is safe to queue because the affected helper, tests, and expected validation path are clear and no product decision is needed.

Review details

Best possible solution:

Add a narrow architecture-aware message path for ARM64 while preserving the existing x86/x64 wording, and cover both branches with focused setup-engine tests.

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

Yes, from source inspection: feeding the observed WSL virtualization-disabled text into WslInstallSupport.TryGetEnvironmentIssue on current master returns the x86 BIOS/VT-x/AMD-V guidance with no ARM64 branch. I did not run a live ARM64 Windows setup session in this read-only review.

Is this the best way to solve the issue?

Yes, the suggested architecture branch is the narrowest maintainable fix: use RuntimeInformation.OSArchitecture only for the remediation copy, keep the existing diagnostic detection, and update focused tests.

AGENTS.md: found, but no applicable review policy affected this item.

Remaining risk / open question:

• No live Windows ARM64 setup run was performed during this read-only review; the failure is source-reproducible from the current helper and the reporter’s screenshot/context.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 8af4b70360a9.

Label changes

Label changes:

• add P3: This is a low-risk setup UX wording bug with limited blast radius and a narrow fix path.
• add impact:other: The issue affects setup remediation guidance for ARM64 users but does not fit the more specific owned impact classes.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P3: This is a low-risk setup UX wording bug with limited blast radius and a narrow fix path.
• impact:other: The issue affects setup remediation guidance for ARM64 users but does not fit the more specific owned impact classes.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj

What I checked:

• Repository policy read: AGENTS.md was read fully; this read-only review made no changes, while any future fix must follow the repo validation commands after editing. (AGENTS.md:1, 8af4b70360a9)
• Current source still has x86-only remediation: WslInstallSupport.TryGetEnvironmentIssue matches virtualization is not enabled and unconditionally returns Enable VT-x/AMD-V (Intel VT or AMD SVM) in your computer's BIOS/UEFI settings, with no architecture branch. (src/OpenClaw.SetupEngine/SetupSteps.cs:100, 8af4b70360a9)
• Regression coverage currently locks in BIOS wording: The setup tests assert that the environment-issue helper and PreflightWslStep messages contain BIOS, confirming current expectations do not cover ARM64 wording. (tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs:516, 8af4b70360a9)
• History provenance for the wording: Git blame ties the current virtualization-disabled branch and message to commit 9106725567af7a257f1da45b7fc56a1bde3300ec from 2026-05-28. (src/OpenClaw.SetupEngine/SetupSteps.cs:96, 9106725567af)
• Area history: Recent setup-engine history shows the preflight WSL/environment handling was introduced and then extended through commits by Ranjesh Jaganathan and Keith Mahoney. (src/OpenClaw.SetupEngine/SetupSteps.cs:420, 9106725567af)
• Canonical search: GitHub issue search for the core ARM64/preflight virtualization terms only returned this issue, so no canonical duplicate or already-open replacement was found.

Likely related people:

• kmahone: Blame shows commit 9106725567af7a257f1da45b7fc56a1bde3300ec introduced the current virtualization-disabled message and tests that assert BIOS wording. (role: introduced behavior; confidence: high; commits: 9106725567af; files: src/OpenClaw.SetupEngine/SetupSteps.cs, tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs)
• ranjeshj: Recent setup-engine history and shortlog show multiple commits in the WSL setup/preflight area, including the out-of-process SetupEngine and deterministic WSL setup work. (role: recent area contributor; confidence: medium; commits: cefce3952ab1, 98d0760cb5b6, ff3a7cc53736; files: src/OpenClaw.SetupEngine/SetupSteps.cs, tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs)

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.

[shanselman]

@RBrid Does WSL return English and are we looking at an English string and does it return English on every computer? maybe ask craig or ben hillis

[github-actions]

🤖 This is an automated response from Repo Assist.

@RBrid Does WSL return English and are we looking at an English string and does it return English on every computer? maybe ask craig or ben hillis

This is a great concern to raise, @shanselman. WSL's console output language depends on the Windows display language — on a non-English Windows install, wsl.exe output (including the "virtualization is not enabled" string this helper matches) will be in the system locale. So the detection in WslInstallSupport.TryGetEnvironmentIssue is already locale-fragile on non-English Windows, regardless of the ARM64 wording.

The current x86-only message is a wording bug specifically on ARM64 (the detection works fine there, as confirmed by the reporter's screenshot). The broader locale sensitivity of Contains(text, "virtualization is not enabled") is a separate pre-existing issue worth tracking — if WSL is installed on a French or Japanese Windows system, neither the x86 nor the ARM64 path would trigger.

PR #594 addresses the ARM64 wording. The locale sensitivity is worth filing as a follow-up if it becomes a practical issue, or it could be noted in code comments now.

For immediate context: the detection has worked in practice because the target audience (developers setting up WSL on ARM64 Surface-class devices) typically runs English Windows. But it's a good hygiene question.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a