feat: prepare bundled Bun for Windows desktop

[steipete]

What Problem This Solves

Prepares the Tauri desktop companion to run its local Gateway on the bundled fork Bun on Windows x64 and ARM64 through the canonical Windows service owner.

User Impact

DRAFT — do not merge or publish Windows builds. Windows runtime admission stays inert until a signed fork artifact exists for the matching architecture. The OpenClaw Foundation Azure Artifact Signing identity is approved. Production qualification requires the corrected signed fork prerelease, coordinator-generated x64/ARM64 pins, and matching release-profile proof. Native existing-install proof also confirmed a privilege-boundary blocker below. Work is stopped for the requested design decision; this draft is not ready for merge. The current real unsigned x64 pin is test preparation data; no ARM64 hash or artifact is fabricated.

Existing Gateways retain their runtime across startup, reconnect, quit and app updates. Adoption requires Use bundled runtime… and its native confirmation. Fresh Windows setup supports Stable and Beta packages.

Why This Change Was Made

The shared release-manifest projection supports both Windows targets while preserving all four Unix pin entries and their provenance. The stager verifies archive/executable hashes and matching PE architecture. The existing materializer publishes immutable .exe slots under the Windows state root with native file locking, reparse rejection and closed write handles before rename. The build-only local-artifact option admits explicitly test-only debug proof; unsigned release-profile input is refused.

The CLI stays on private Node; the Gateway uses bundled Bun. The explicit action carries the observed --expected-runtime-pin into the existing Scheduled Task reconciliation owner. Prerequisites #165261 (stop old → publish definition → start new) and #165538 (authored runtime-pin identity versus effective native cwd) are merged. No new service owner, user configuration or automatic migration is introduced.

Updates preserve the selected runtime and native task policy. Fresh setup needs Windows private CLI installation and command transport; these remain in the existing installer/CLI owners. PowerShell 5 transports npm policy and account aliases without dropping empty arguments or nesting arrays. The prerequisite's published 2026.9.8 → candidate update passed; its known same-account UserId warning was retained. This branch fixes that alias comparison with a native regression. Uninstall uses the independent canonical CLI contract: quit the app, then run from Node and a CLI package outside the state directory.

The native privilege boundary requires a design decision before continuing: an explicitly consented one-shot elevation handoff through the existing canonical CLI, retaining the captured pin across elevation, or manual elevated-CLI guidance for these installations. Neither option is implemented; the ordinary desktop app is not elevated and task permissions are unchanged.

Evidence

• Native Windows x64 debug app build passed. The unsigned fork's source identity, executable hash, SQLite 3.53.4 and CLI startup were verified. No Windows binary, npm package or release was published.
• Real fresh app setup reached the Gateway Control UI on bundled Bun. Actual PID, executable SHA-256 and saved runtime pin agree; RPC, health and readiness passed. Doctor exited 0 and completed, with a recorded shared-state cleanup-timeout warning. Actual tray Quit preserved the same Gateway PID; independent canonical uninstall verified task, listener, launcher, state and runtime removal. The separately staged debug app binary is outside that uninstall scope.
• Existing Node startup → actual Quit → relaunch passed with the same process, executable and saved pin. Actual native runtime confirmation then refused before calling install: the ordinary desktop CLI reports the existing S4U process as unknown because its executable/command line cannot be inspected, while the SSH CLI context verifies it. Exact desktop argv reproduced the refusal with matching HOME/profile/config and target role; no timeout/profile workaround or guard bypass was used. The original healthy Node process and pin were preserved through refusal and actual Quit. Canonical test cleanup then ran successfully from the existing administrative CLI context; Gateway task, listener, state, runtime and both scratch CLI prefixes were removed. The disposable lease and its private checkpoint are verified released/deleted. This cleanup is not claimed as successful desktop adoption. Native Windows rights inspection confirmed the boundary: the same desktop user SID matches the task principal, but both limited process query and termination access return Win32 error 5; the task grants this user read-only access and grants full access to Administrators/SYSTEM. No process handle opened and no termination was attempted. The earlier install/status cwd mismatch is fixed and independently proven.
• Windows materialization/path tests passed; the compiled build script refused unsigned release-profile input. All 48 native installer tests and 15 refreshed native service-audit tests passed; the same-account SID negative control failed on the original code.
• Final 27-file service/CLI/stager union: 590 passed, 55 platform skips on each of Node 24 and the pinned fork Bun (101.00s / 83.88s). Core, service-test and CLI-test type graphs passed. The lower count than earlier proof follows main's test cleanup.
• Final committed-branch P2 scoped review is clean. Rust formatting and workflow validation passed. Full dead-export scans were qualified against their exact bases; inherited findings were retained, not suppressed in source. These are not claimed as an unqualified full-repository check pass.

Exact-head native CI passed Windows x64, Windows ARM64, Linux and macOS. Each Windows job asserts its native OS architecture and explicit Rust target, then passes 10 materialization cases, 61 Windows-filtered cases (four overlap), one power test and one process-owner test. General CI is skipped for the draft. This proves app-side fixtures; real ARM64 Bun execution awaits the corrected fork artifact and signed prerelease.

The actual app executable was built before the final rebase; all production Rust/UI and embedded installer inputs are byte-identical to the final candidate. Only docs, a JS test and nine cfg(test) lines changed. The final canonical CLI was rebuilt natively in 3m44.2s and its package validation passed in 146s.

Measured file costs with the repository wrapper and --maxWorkers=1:

File	Wall time
src/cli/daemon-cli/install.test.ts	26.63s
src/daemon/service-audit-schtasks.windows.test.ts	22.29s
src/daemon/service-definition-schtasks.test.ts	18.4s
test/scripts/install-ps1.release.test.ts	2.09s (Windows cases skipped on macOS)
test/scripts/stage-openclaw-bun.test.ts	21.91s (ARM64 extension)

Initial native Windows installer/audit proof took 264.98s including cold transforms; the SID regression took 664ms. The refreshed 15-case native audit suite took 138.78s including cold transforms. Final CI wall times: Windows ARM64 358s, Windows x64 241s, Linux 326s, macOS 252s.

Before: Windows CLI installation was unavailable in the companion.

After: explicit Stable/Beta setup and the actual Gateway Control UI on the unsigned test-only build.

Existing Node Gateway: the native tray exposes the explicit runtime action. Its confirmation names the observed runtime and explains the service restart and future explicit-action requirement. Only the synthetic test path is redacted.

Current native refusal, before any service mutation:

[clawsweeper]

🦞👀
ClawSweeper picked this up.

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

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed October 5, 2026, 9:48 AM ET / 13:48 UTC (Revision 7).

ClawSweeper review

What this changes

The Tauri desktop companion gains Windows bundled-Bun staging, private Node-based CLI installation, and explicit Gateway runtime selection through the existing Windows service owner.

Merge readiness

⛔ Blocked before merge - 4 items remain

Useful Windows desktop preparation remains absent from current main. The draft accurately records its native adoption limitation and outstanding signed-artifact qualification; neither merged prerequisite supersedes this work.

Priority: P2
Reviewed head: d8916dcf74d44113988816264f6a94be223653f4
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	Strong native preparation evidence and coherent owner reuse support a good patch rating, with specific adoption and production-qualification work still outstanding.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.
Evidence reviewed	10 items	Pinned introduced changes: Reviewed the merge-base-to-head introduced hunks across staging, native runtime materialization, desktop actions, installer, service admission, tests, docs, and workflow. Base-only dependency and updater changes were excluded from PR ownership. Still necessary on main: Fetched main's staging implementation explicitly excludes Windows and its shared pin contains only the four Unix artifacts. The latest release also lacks this desktop staging path. No merged replacement implementing Windows desktop preparation was established. Production admission remains inert: Windows staging returns an unavailable sentinel for absent or unsigned pins; build.rs rejects explicitly unsigned proof outside debug builds. The committed x64 pin is unsigned and no ARM64 artifact is fabricated.
Findings	None	None.
Security	None	None.

How this fits together

The desktop companion installs or invokes the canonical CLI, which owns Windows Gateway service changes. Verified bundled runtime files supply the executable, while explicit user confirmation and captured service state control adoption.

flowchart TD
  A[Windows artifact pins] --> B[Verify and stage runtime]
  B --> C[Immutable runtime files]
  D[Desktop setup or confirmation] --> E[Canonical CLI]
  C --> E
  E --> F[Check current service authority]
  F --> G[Preserve or replace Gateway]

Loading

Decision needed

Question	Recommendation
Should access-restricted S4U installations adopt bundled Bun through a consented one-shot elevated canonical CLI, or through explicit manual elevated-CLI guidance?	Consent to one-shot elevation: Implement a narrowly scoped canonical-CLI handoff with native consent, captured-pin preservation, and final service-authority checks.

Why: Native proof establishes an actual privilege boundary; choosing the supported user experience and elevation contract requires maintainer intent.

Before merge

• Resolve merge risk (P1) - Existing access-restricted S4U Gateways remain healthy but cannot adopt bundled Bun from the ordinary desktop context; a supported consented elevation path or explicit elevated-CLI guidance remains unimplemented.
• Resolve merge risk (P1) - Production Windows qualification still requires corrected signed x64 and ARM64 fork artifacts, generated matching pins, and native release-profile proof; current debug x64 evidence and ARM64 fixtures do not cover that gate.
• Complete next step (P2) - Choose and implement the restricted-S4U adoption path, complete signed x64/ARM64 qualification, and resolve current merge conflicts with affected validation before marking the draft ready.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

PR surface

Source +146, Tests +498, Docs +116, Config +24, Other +777. Total +1561 across 31 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	3	165	19	+146
Tests	5	531	33	+498
Docs	4	125	9	+116
Config	1	32	8	+24
Generated	0	0	0	0
Other	18	982	205	+777
Total	31	1835	274	+1561

Review metrics

Metric	Value	Why it matters
Production versus test growth	production/tooling +668 net lines; tests +753 net lines	Excluding docs and workflow YAML and separating Rust test modules, the growth supports Windows materialization, private CLI transport, and service admission.
New installer options	2 PowerShell options: RuntimeOnly and Prefix	The new private-install mode must remain isolated from ordinary installation, Gateway probes, and persistent PATH changes.

Merge-risk options

Maintainer options:

1. Complete the chosen adoption contract (recommended)
   Implement and prove the selected restricted-service adoption path, then qualify signed artifacts on both native architectures before enabling production Windows setup.
2. Keep preparation paused
   Retain the draft and inert Windows admission while the privilege-boundary decision and signed artifacts remain outstanding.

Technical review

Best possible solution:

Provide a consented one-shot canonical-CLI elevation handoff that retains the captured pin and revalidates service authority, while preserving ordinary desktop privileges and existing runtime selections.

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

Not applicable as a feature proposal; supplied native Windows proof does establish fresh setup success and reproducible restricted-service adoption refusal.

Is this the best way to solve the issue?

Yes for the ownership structure: reuse the canonical installer and Windows service writer. Completion still depends on choosing the supported privilege handoff and qualifying signed native artifacts.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 740ddaa458e3.

Labels

Label changes:

• add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.

Label justifications:

• P2: This is bounded Windows desktop capability preparation with preserved existing services and no demonstrated urgent runtime regression.
• merge-risk: 🚨 compatibility: Native proof exposes an unsupported adoption path for existing restricted S4U installations, and production architecture qualification remains incomplete.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.
• proof: sufficient: Contributor real behavior proof is sufficient. Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Native Windows x64 debug proof exercises desktop private-CLI setup through canonical installation to a serving bundled-Bun Gateway and preserves an existing Node service through denied adoption. Inspected screenshots corroborate setup and connection; signed release-profile and real ARM64 qualification remain separate readiness blockers. No existing stored-data format changes were identified.

Evidence

What I checked:

• Pinned introduced changes: Reviewed the merge-base-to-head introduced hunks across staging, native runtime materialization, desktop actions, installer, service admission, tests, docs, and workflow. Base-only dependency and updater changes were excluded from PR ownership. (d8916dcf74d4)
• Still necessary on main: Fetched main's staging implementation explicitly excludes Windows and its shared pin contains only the four Unix artifacts. The latest release also lacks this desktop staging path. No merged replacement implementing Windows desktop preparation was established. (apps/linux/scripts/stage-runtime.mjs:19, 740ddaa458e3)
• Production admission remains inert: Windows staging returns an unavailable sentinel for absent or unsigned pins; build.rs rejects explicitly unsigned proof outside debug builds. The committed x64 pin is unsigned and no ARM64 artifact is fabricated. (apps/linux/scripts/stage-runtime.mjs:57, d8916dcf74d4)
• Existing-service authority preserved: Runtime adoption rechecks the confirmed observation and passes its expected pin to canonical installation. Guarded Windows installs use existing definition reconciliation, native locking, backup, policy preservation, and writer checks. Account aliases are compared by SID; foreign-account and unavailable-inspection controls remain rejecting. (src/cli/daemon-cli/install.ts:560, d8916dcf74d4)
• Native proof and explicit limitation: The captured body reports actual Windows x64 fresh setup with matching serving PID, executable hash, saved pin, RPC and readiness, plus preservation across tray Quit. Existing S4U adoption refused before installation because the ordinary desktop context could not inspect the running process; native access checks returned error 5. This is safe refusal, not successful adoption. Four prepared screenshots were inspected: before setup failure, after channel selection, connected Control UI, and the runtime tray action. The two newer confirmation/refusal images were not in the prepared manifest; their textual observations remain available in the captured body. (d8916dcf74d4)
• Exact-head native CI: https://github.com/openclaw/openclaw/actions/runs/37310089357 reports success for the reviewed head. Windows x64/ARM64 fixtures supplement the native x64 setup evidence; they do not establish signed release-profile execution or real ARM64 Bun behavior. (.github/workflows/linux-app.yml:381, d8916dcf74d4)

Likely related people:

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

• Choose and implement the supported adoption path for access-restricted S4U installations.
• Complete signed x64 and ARM64 release-profile qualification with generated matching pins.

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.

History

Review history (6 earlier review cycles)

• reviewed 2026-10-05T09:38:01.037Z sha 81a0ebc :: blocked before merge. :: none
• reviewed 2026-10-05T09:44:44.550Z sha 81a0ebc :: blocked before merge. :: none
• reviewed 2026-10-05T10:18:01.396Z sha 8dff06a :: blocked before merge. :: none
• reviewed 2026-10-05T10:34:30.042Z sha 8dff06a :: blocked before merge. :: none
• reviewed 2026-10-05T12:38:00.713Z sha d8916dc :: blocked before merge. :: none
• reviewed 2026-10-05T13:25:55.951Z sha d8916dc :: blocked before merge. :: none