build.ps1 should detect Windows without requiring OS=Windows_NT

[TheAngryPit]

Summary

build.ps1 currently treats a Windows host as unsupported when the OS environment variable is missing, even though PowerShell/.NET can identify the platform directly.

I hit this on a Windows Insider/preview host (25H2, build 26200.8737) from a PowerShell 7 process where $env:OS was not populated. The script failed at the prerequisite stage with This project requires Windows despite running on Windows.

Reproduction

From a Windows PowerShell 7 session:

$env:OS = $null
.\build.ps1 -CheckOnly

Before the fix, the OS prerequisite check fails because it only checks:

$env:OS -ne "Windows_NT"

Expected behavior

build.ps1 should detect Windows from the host/runtime, not from a mutable optional environment variable.

Proposed fix

Use PowerShell's $IsWindows automatic variable when available, with a Windows PowerShell-compatible fallback through [System.Environment]::OSVersion.Platform.

Local validation

On Windows 25H2 build 26200.8737:

• ./build.ps1 -CheckOnly with $env:OS = $null passed and reported Windows detected.
• ./build.ps1 with $env:OS = $null passed.
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore passed: 2417 passed, 29 skipped.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore passed: 1154 passed.
• openclaw-autoreview on the one-file diff reported no accepted/actionable findings.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 8:41 AM ET / 12:41 UTC.

Summary
Keep this issue open: current main and the latest release still use the mutable OS=Windows_NT prerequisite check, and the open same-author PR at #822 is the active candidate fix.

Reproducibility: yes. from source inspection rather than live Windows execution: current build.ps1 exits when $env:OS is null before any runtime-based Windows check can pass.

Root-cause cluster
Relationship: canonical
Canonical: #821
Summary: This issue is the canonical tracker for the build-script OS detection bug; the open same-author PR is a candidate fix, while the WSL preflight search hit is adjacent but distinct.

Members:

• fixed_by_candidate: Fix Windows build detection without OS env var #822 - The PR uses closing syntax for this issue and changes only build.ps1 to replace the mutable environment-variable OS check.
• adjacent_distinct: preflight-wsl UTF-16 parsing bug still present in v0.6.0 (re: #660 closed prematurely) #661 - GitHub search found this Windows-related setup issue, but its root cause is localized/UTF-16 WSL version parsing rather than build.ps1 host OS detection.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
No separate ClawSweeper repair job should be queued because the open same-author PR at #822 already owns the candidate fix.

Review details

Best possible solution:

Merge a narrow build.ps1 host/runtime Windows detection fix, preserving the non-Windows fail-fast behavior and validating it with the repository-required build and test commands.

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

Yes, from source inspection rather than live Windows execution: current build.ps1 exits when $env:OS is null before any runtime-based Windows check can pass.

Is this the best way to solve the issue?

Yes, the proposed direction is the narrow maintainable fix: use PowerShell/.NET host detection and keep the existing unsupported-platform failure for non-Windows hosts.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I could not run the live Windows PowerShell reproduction in this Linux checkout; the failure is source-reproducible from the current build.ps1 control flow and the reporter provided Windows validation.

Codex review notes: model internal, reasoning high; reviewed against 4e7982bafb86.

Label changes

Label changes:

• add P2: This is a normal-priority build-script bug with a clear source path and limited blast radius to affected Windows development environments.
• add impact:other: The affected surface is local build prerequisite availability, which is maintainer-visible but outside the specific data, auth, message, session, security, and 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:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority build-script bug with a clear source path and limited blast radius to affected Windows development environments.
• impact:other: The affected surface is local build prerequisite availability, which is maintainer-visible but outside the specific data, auth, message, session, security, and crash-loop labels.

Evidence reviewed

What I checked:

• Current source still has the reported gate: At current main, build.ps1 checks $env:OS -ne "Windows_NT", writes This project requires Windows, and exits before prerequisite checks continue. (build.ps1:146, 4e7982bafb86)
• Documented build path uses CheckOnly: README documents Windows prerequisites and ./build.ps1 -CheckOnly, so rejecting a Windows host because an optional environment variable is missing breaks an advertised local build path. (README.md:39, 4e7982bafb86)
• Latest release still has the same check: Inspecting v0.6.3:build.ps1 shows the same $env:OS -ne "Windows_NT" check, so the issue is not already fixed in the latest release. (build.ps1:146, 85445c78066b)
• History provenance for the fragile check: git log -S ties the original build-script prerequisite check to the commit that added build.ps1; later build-script hardening did not replace this OS detection. (build.ps1:146, 5f18e7b530a6)
• Open fix candidate exists: GitHub reports Fix Windows build detection without OS env var #822 as open and closing this issue; its diff adds Test-WindowsHost and replaces the $env:OS check in build.ps1. (build.ps1:146, 4337fe742586)

Likely related people:

• shanselman: History shows the original build.ps1 prerequisite detection and later local build-script hardening were authored by Scott Hanselman, including the $env:OS check that remains today. (role: introduced behavior and build-script area contributor; confidence: high; commits: 5f18e7b530a6, 782153f0313a; files: build.ps1, README.md)
• Vincent Koc: The most recent focused build.ps1 commit changed build output capture in the same script, making this a relevant recent ownership signal for review routing. (role: recent build-script contributor; confidence: medium; commits: 0e61fa287afb; files: build.ps1)
• RBrid: Current-line blame in this grafted checkout attributes the present build.ps1 lines to the broad current-main import commit, though the more specific build-script history points to earlier authors. (role: current-main provenance signal; confidence: low; commits: 6623cb8410a4; files: build.ps1)

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.