chore(deps): refresh Windows packaging toolchain

[steipete]

Dependency refresh for the Windows packaging toolchain.

• .NET SDK 10.0.100 → 10.0.400
• Windows SDK BuildTools 10.0.26100.4948 → 10.0.28000.2705
• Test SDK 18.6 → 18.9, xUnit adapter 3.1.5 → 4.0
• Node 24.16 → 24.20 LTS, pnpm 11.15.1 → 11.24, setup-node v6 → v7

Also fixes an upstream pin that was overriding the workflow's pnpm version, and adds a packaged-launcher smoke check.

Local proof on this host:

dotnet build OpenClaw.Gateway.MSIX.slnx --configuration Release --no-restore -p:EnableWindowsTargeting=true
Build succeeded. 0 Warning(s) 0 Error(s)

dotnet test OpenClaw.Gateway.MSIX.slnx --configuration Release --no-build --no-restore -p:EnableWindowsTargeting=true
Passed: 38, Failed: 0, Skipped: 0

Windows CI on this candidate is unverified until this PR runs it — that is the point of opening it. Signing remains manual-only; no scheduled monitoring workflows were touched. Codex autoreview: scoped-clean.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed August 31, 2026, 7:14 AM ET / 11:14 UTC.

ClawSweeper review

What this changes

Refreshes the Windows MSIX packaging toolchain versions and adds an x64 packaged-launcher smoke check to the build workflow.

Merge readiness

⛔ Blocked until stronger real behavior proof is added - 3 items remain

Keep open: this is a coherent, narrowly scoped packaging-toolchain refresh, but end-to-end Windows MSIX behavior with the refreshed runtime is not yet evidenced.

Priority: P3
Reviewed head: f90acaf3f8b2d207c8b605ee745e1400b8d7afc3

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The implementation is focused and consistent with the existing packaging design, while proof remains partial until the refreshed Windows package path completes.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: The body supplies a terminal build/test result for the refreshed .NET host, but it does not exercise the workflow's Node/pnpm build, MSIX composition, or new packaged-launcher smoke path; the relevant Windows jobs are still queued or in progress. Attach redacted end-to-end Windows workflow output after completion, then update the PR body for a fresh review.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: The body supplies a terminal build/test result for the refreshed .NET host, but it does not exercise the workflow's Node/pnpm build, MSIX composition, or new packaged-launcher smoke path; the relevant Windows jobs are still queued or in progress. Attach redacted end-to-end Windows workflow output after completion, then update the PR body for a fresh review.
Evidence reviewed	5 items	Introduced scope: The verified merge-base-to-head delta changes six files: the packaging workflow, centralized .NET package versions, SDK selection, local packaging script, README, and changelog. Bundled runtime path: The workflow passes the refreshed Node version to MSIX composition, and the composer downloads, checksum-verifies, and packages that runtime. Launcher smoke target: The new smoke step extracts the x64 MSIX and invokes its launcher; the launcher resolves its bundled runtime and stages the packaged payload before forwarding CLI arguments.
Findings	None	None.
Security	None	None.

How this fits together

The packaging workflow builds OpenClaw into an npm payload, combines it with a bundled Node.js runtime and NativeAOT launcher, then emits Windows MSIX packages. The refreshed toolchain affects both the CI build path and the runtime included in installed packages.

flowchart TD
  A[OpenClaw source revision] --> B[Build npm package]
  C[Node and pnpm toolchain] --> B
  B --> D[Windows payload]
  E[.NET MSIX host] --> F[Unsigned MSIX package]
  D --> F
  F --> G[Gateway launcher]

Loading

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: The body supplies a terminal build/test result for the refreshed .NET host, but it does not exercise the workflow's Node/pnpm build, MSIX composition, or new packaged-launcher smoke path; the relevant Windows jobs are still queued or in progress. Attach redacted end-to-end Windows workflow output after completion, then update the PR body for a fresh review.
• Resolve merge risk (P1) - The refreshed Node runtime and workflow changes have not yet completed the candidate's Windows payload/MSIX path for both architectures, so an installed-package regression would be discovered only after merge if the pending jobs fail.
• Complete next step (P2) - Complete the pending Windows package validation and review the resulting end-to-end proof; there is no narrow repository repair for an automation worker to make now.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Change footprint	6 files affected; 37 additions, 10 deletions	The small diff updates seven toolchain coordinates and adds one packaged-launcher smoke step across the release build path.

Merge-risk options

Maintainer options:

1. Complete packaged Windows validation (recommended)
   Wait for both architecture jobs, then attach redacted output showing the refreshed MSIX build and x64 launcher smoke result before merge.

Technical review

Best possible solution:

Merge after the Windows workflow completes successfully and an end-to-end packaged-launcher result is attached as redacted proof.

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

Not applicable: this PR refreshes packaging dependencies rather than repairing a reported bug. Its supplied host build/test transcript is useful partial validation but does not reproduce the full Windows packaging path.

Is this the best way to solve the issue?

Yes, centralizing the version updates in the workflow, local packager, SDK selector, and package manifest is the maintainable approach; it needs completed package-level validation before landing.

AGENTS.md: not found in the target repository.

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

Labels

Label changes:

• add P3: This is a routine dependency and CI-maintenance refresh rather than a reported user-facing regression.
• add merge-risk: 🚨 compatibility: The embedded Node.js runtime changes from 24.16.0 to 24.20.0, affecting the runtime used by installed Gateway packages.
• add merge-risk: 🚨 automation: The PR changes the CI workflow's Node, pnpm, and setup-action behavior, with the Windows package jobs still incomplete.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The body supplies a terminal build/test result for the refreshed .NET host, but it does not exercise the workflow's Node/pnpm build, MSIX composition, or new packaged-launcher smoke path; the relevant Windows jobs are still queued or in progress. Attach redacted end-to-end Windows workflow output after completion, then update the PR body for a fresh review.

Label justifications:

• P3: This is a routine dependency and CI-maintenance refresh rather than a reported user-facing regression.
• merge-risk: 🚨 compatibility: The embedded Node.js runtime changes from 24.16.0 to 24.20.0, affecting the runtime used by installed Gateway packages.
• merge-risk: 🚨 automation: The PR changes the CI workflow's Node, pnpm, and setup-action behavior, with the Windows package jobs still incomplete.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The body supplies a terminal build/test result for the refreshed .NET host, but it does not exercise the workflow's Node/pnpm build, MSIX composition, or new packaged-launcher smoke path; the relevant Windows jobs are still queued or in progress. Attach redacted end-to-end Windows workflow output after completion, then update the PR body for a fresh review.

Evidence

What I checked:

• Introduced scope: The verified merge-base-to-head delta changes six files: the packaging workflow, centralized .NET package versions, SDK selection, local packaging script, README, and changelog. (.github/workflows/gateway-msix.yml:65, f90acaf3f8b2)
• Bundled runtime path: The workflow passes the refreshed Node version to MSIX composition, and the composer downloads, checksum-verifies, and packages that runtime. (scripts/Build-MSIX.ps1:166, f90acaf3f8b2)
• Launcher smoke target: The new smoke step extracts the x64 MSIX and invokes its launcher; the launcher resolves its bundled runtime and stages the packaged payload before forwarding CLI arguments. (.github/workflows/gateway-msix.yml:244, f90acaf3f8b2)
• Current validation state: The supplied check state confirms the Linux npm-package build and host tests, while the x64 payload build is queued and the ARM64 payload build remains in progress; neither completed result yet proves the refreshed MSIX path. (.github/workflows/gateway-msix.yml:145, f90acaf3f8b2)
• Feature-history routing: Current-main history shows Linus Huang authored the recent standalone Gateway packaging restoration and launcher repair work that established this workflow and host area. (src/OpenClaw.Gateway.Launcher/Program.cs:95, 86aee87ed613)

Likely related people:

• Linus Huang: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Attach redacted successful Windows workflow output covering the refreshed package build and x64 packaged-launcher smoke test.
• Update the PR body after adding proof; if a review does not refresh automatically, ask a maintainer to comment @clawsweeper re-review.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.