preflight-wsl UTF-16 parsing bug still present in v0.6.0 (re: #660 closed prematurely)

[panic-Patrick]

Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Current main already normalizes WSL command output before version parsing, so the reported UTF-16-style NUL-byte output no longer blocks preflight-wsl; the fix is present in the v0.6.0 tag.

I found the merged PR that appears to have closed this: #567: Chat: render in-bubble Allow/Deny approval banner + harden plumbing.

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review details

Best possible solution:

Keep the current v0.6.0 setup-engine behavior that strips NUL and BOM characters before parsing WSL version output.

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

No Windows runtime reproduction was run in this Linux checkout, but the source path is clear: NUL-byte WSL version text is normalized before the version regex on current main.

Is this the best way to solve the issue?

Yes. Removing NUL/BOM characters at the WSL parsing boundary is the narrow fix for UTF-16-style ASCII output and preserves the existing preflight behavior.

Security review:

Security review: This is a non-PR issue triage item with no patch security surface to review.

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

What I checked:

• Current source normalizes WSL version output: PreflightWslStep combines stdout/stderr, normalizes the text, and passes it into WslInstallSupport.TryParseWslVersion; WslInstallSupport.Normalize removes \0 and BOM characters before the regex runs. (src/OpenClaw.SetupEngine/SetupSteps.cs:444, 53ff55aff974)
• Git history ties the normalization to the released setup implementation: git blame shows the version parser, preflight version call, and Normalize helper all come from commit 7d9152f. (src/OpenClaw.SetupEngine/SetupSteps.cs:162, 7d9152f427a3)
• Release provenance: git tag --contains reports v0.6.0 contains commit 7d9152f, and inspecting v0.6.0:src/OpenClaw.SetupEngine/SetupSteps.cs confirms the NUL-stripping normalization is in that tag. (src/OpenClaw.SetupEngine/SetupSteps.cs:162, 7d9152f427a3)

Likely related people:

• RBrid: The current WSL preflight parser, NUL/BOM normalization helper, setup command runner, and nearby tests are all attributed by blame/history to the release commit authored by this GitHub account. (role: recent setup-engine contributor; confidence: high; commits: 7d9152f427a3; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine/CommandRunner.cs, tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 53ff55aff974; fix evidence: merged PR #567, release v0.6.0, commit 7d9152f427a3.

Originally posted by @clawsweeper in #660

The bot incorrectly closed this. The fix is NOT present in v0.6.0.

I just tested v0.6.0 (OpenClawCompanion-Setup-x64.exe) and it still
fails with the identical error. Log from v0.6.0 run at 06:32 UTC today:

{"StepId":"preflight-wsl","Event":"completed","Outcome":"FailedTerminal",
"Detail":"WSL version output did not include a parseable WSL version..."}

System: Windows 10.0.26200.0, WSL 2.7.3.0 (fully updated)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 3, 2026, 2:52 AM ET / 06:52 UTC.

Summary
Keep this issue open: current main and v0.6.0 strip NUL/BOM characters, but the parser still only accepts WSL version: with whitespace, while the reported sample includes the hyphenated WSL-Version: form that remains unparsable.

Reproducibility: yes. from source inspection, though not by running the Windows installer here. After current normalization, the reported WSL-Version: label still cannot match the parser's WSL\s+version: regex, so preflight-wsl can still reach the reported terminal failure.

Next step
This is a focused setup-engine parser/test repair with clear files and no product or security decision blocker.

Review details

Best possible solution:

Land a narrow setup-engine parser fix with regression coverage for NUL-separated and hyphenated WSL version output while preserving the existing minimum-version and environment-diagnostic behavior.

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

Yes from source inspection, though not by running the Windows installer here. After current normalization, the reported WSL-Version: label still cannot match the parser's WSL\s+version: regex, so preflight-wsl can still reach the reported terminal failure.

Is this the best way to solve the issue?

Yes, the best path is a narrow parser/test repair. It should accept the observed hyphenated/NUL-separated WSL label without changing setup policy, version thresholds, or unrelated WSL diagnostics.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not run the Windows installer in this Linux checkout, so the exact live wsl.exe --version bytes should be preserved from reporter logs or a Windows smoke when fixing.
• The parser fix should stay narrow enough to accept the observed WSL-Version: form without treating unrelated command output numbers as a valid WSL version.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 53ff55aff974.

Label changes

Label changes:

• add P1: The terminal preflight failure blocks setup for affected Windows users with otherwise supported WSL installations.
• add impact:other: The affected surface is installer/setup preflight availability, which is maintainer-visible but outside the specific auth, message, session, security, or crash-loop labels.
• 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:

• P1: The terminal preflight failure blocks setup for affected Windows users with otherwise supported WSL installations.
• impact:other: The affected surface is installer/setup preflight availability, which is maintainer-visible but outside the specific auth, message, session, security, or crash-loop labels.

Evidence reviewed

Acceptance criteria:

• dotnet test ./tests/OpenClaw.SetupEngine.Tests/OpenClaw.SetupEngine.Tests.csproj --no-restore
• ./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

What I checked:

• Current parser still requires whitespace form: WslInstallSupport.TryParseWslVersion normalizes the string, then matches only WSL\s+version: before the version number; that does not cover the reported normalized WSL-Version: shape. (src/OpenClaw.SetupEngine/SetupSteps.cs:55, 53ff55aff974)
• Preflight failure path is still active: PreflightWslStep combines stdout/stderr, normalizes them, and returns the exact terminal failure when TryParseWslVersion returns false. (src/OpenClaw.SetupEngine/SetupSteps.cs:444, 53ff55aff974)
• Normalization is too narrow for the reported shape: The current normalization removes NUL and BOM characters only; it does not convert WSL-Version: into the whitespace form required by the regex. (src/OpenClaw.SetupEngine/SetupSteps.cs:162, 53ff55aff974)
• Regression coverage does not include the reported format: Existing setup-engine tests cover the plain English WSL version: 2.7.3.0 case but not NUL-separated or hyphenated WSL-Version: output. (tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs:496, 53ff55aff974)
• v0.6.0 has the same parser: Inspecting v0.6.0:src/OpenClaw.SetupEngine/SetupSteps.cs shows the same WSL\s+version: regex, and git diff v0.6.0..HEAD -- src/OpenClaw.SetupEngine/SetupSteps.cs tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs produced no setup parser/test changes. (src/OpenClaw.SetupEngine/SetupSteps.cs:55, 7d9152f427a3)
• Related report contains the missing format clue: The related closed report supplied a NUL-separated sample beginning W^@S^@L^@-^@V...; after NUL stripping, that becomes a hyphenated label rather than the current parser's whitespace label.

Likely related people:

• RBrid: Current blame attributes the WSL preflight parser, NUL/BOM normalization, command runner path, and nearby tests to the v0.6.0 merge commit associated with this GitHub account. (role: recent setup-engine contributor; confidence: high; commits: 7d9152f427a3; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine/CommandRunner.cs, tests/OpenClaw.SetupEngine.Tests/SetupStepsTests.cs)
• Ranjesh Jaganathan: History shows the deterministic WSL setup work added the setup engine, command runner, and setup-engine tests, then adjusted WSL setup failure handling in the same area. (role: introduced WSL setup behavior; confidence: medium; commits: 98d0760cb5b6, ff3a7cc53736; files: src/OpenClaw.SetupEngine/SetupSteps.cs, src/OpenClaw.SetupEngine/CommandRunner.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.

[jdominguez81]

I can reproduce this on a Spanish Windows install.

PowerShell output:
Versión de WSL: 2.7.3.0

OpenClaw Companion v0.6.0 fails at preflight-wsl with:
WSL version output did not include a parseable WSL version.

It looks like the setup engine expects the English "WSL version:" label and does not handle localized WSL output such as Spanish "Versión de WSL:".

[EAGDuelks]

Same in Germany:

Windows-Version: 10.0.26200.8457
WSL-Version: 2.7.3.0
OpenClaw Setup failed at preflight-wsl
Output contains UTF-16/NUL bytes in setup log
German localized output: WSL-Version

[JustAmply]

I can reproduce this as well on a German Windows installation.

The setup fails at the same preflight-wsl step, even though wsl.exe --version exits successfully with exit code 0.

Environment:

• Windows: 10.0.26300.8553
• WSL: 2.7.7.0
• Kernel: 6.18.26.1-1
• Locale / language: German
• Setup log timestamp: 2026-06-03 10:32 UTC

Relevant log excerpt:

step.started: Verify WSL available
cmd.start: C:\WINDOWS\System32\wsl.exe --version
cmd.done: C:\WINDOWS\System32\wsl.exe exit=0
step.completed: preflight-wsl → FailedTerminal
message: WSL version output did not include a parseable WSL version.

The captured stdout contains a valid WSL version, but it is localized and appears to contain NUL bytes:

W\u0000S\u0000L\u0000-\u0000V\u0000e\u0000r\u0000s\u0000i\u0000o\u0000n\u0000:\u0000 \u00002\u0000.\u00007\u0000.\u00007\u0000.\u00000\u0000

Rendered normally, this is:

WSL-Version: 2.7.7.0
Kernelversion: 6.18.26.1-1
WSLg-Version: 1.0.73.2
Windows-Version: 10.0.26300.8553

So this looks like the same issue, with one additional detail: the parser may also be language-dependent. On German Windows, the label is WSL-Version, not WSL version.

A robust fix probably needs both:

• stripping NUL/BOM characters before parsing
• avoiding an English-only WSL version: label match, or accepting localized variants / parsing the version more defensively

[github-actions]

🤖 This is an automated response from Repo Assist.

I've confirmed the root cause and submitted a fix.

Root cause: wsl.exe --version on non-English Windows emits UTF-16LE output. After NUL-byte stripping the line becomes WSL-Version: (hyphen, German) or Versión de WSL: (Spanish), but the parser only matched WSL\s+version: (English whitespace form). The setup engine then reported the terminal failure even though WSL was fully installed and at a supported version.

Fix: Extended the regex in WslInstallSupport.TryParseWslVersion to an alternation covering the English, German/NUL-stripped, and Spanish localized forms, with regression tests for all variants.

I've opened a draft PR — please review when convenient.

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

[fvnks]

I can reproduce this on a Spanish Windows install.

PowerShell output: Versión de WSL: 2.7.3.0

OpenClaw Companion v0.6.0 fails at preflight-wsl with: WSL version output did not include a parseable WSL version.

It looks like the setup engine expects the English "WSL version:" label and does not handle localized WSL output such as Spanish "Versión de WSL:".

---

same here!