fix(cli): skip compile cache on early Node 24.x to avoid startup deadlock by zhangguiping-xydt · Pull Request #89799 · openclaw/openclaw

zhangguiping-xydt · Jun 3, 2026

Summary

Disable Node compile cache for Windows packaged startup on early Node 24.x versions (24.0-24.14), including the case where the packaged launcher or entry helper inherits NODE_COMPILE_CACHE from the parent environment.

This applies the same no-cache startup boundary to both the TypeScript packaged entry decision and the openclaw.mjs packaged launcher path, while keeping compile cache enabled for non-Windows packaged installs on Node 24.0-24.14, for Windows packaged installs on Node 24.15+, and for other Node majors.

This update also fixes the focused compile-cache regression test so its "unaffected packaged install" case explicitly runs as Linux Node 24.1 instead of inheriting the native Windows Node 24.1 proof runner environment.

Fixes #86550

Maintainer-ready summary

Why it matters / User impact: Affected Windows npm-global users on early Node 24.x can hang before basic CLI commands (openclaw --version, openclaw doctor --fix --non-interactive, openclaw gateway start) produce output or exit. This patch removes the startup-level compile-cache trigger for that Windows/Node range while preserving compile-cache behavior outside that boundary.
Maintainer-ready confidence: High for the source boundary, focused regression test, native Windows npm-global CLI proof, gateway proof, and the exact Node 24.15+ re-enable boundary. The previous evidence gap is now closed with native Windows side-by-side proof using the same packed OpenClaw artifact on node@24.14.0 and node@24.15.0.
Compatibility stance: Do not disable compile cache for all Windows Node 24.x. The proof supports the narrower behavior: Windows Node 24.0-24.14 takes the protected no-cache path; Windows Node 24.15+ keeps compile cache enabled.

Real behavior proof

Behavior or issue addressed: Native Windows npm-global CLI startup can hang on early Node 24.x when Node compile cache is active before the CLI import path. The code fix applies to Windows packaged startup on Node 24.0-24.14, including inherited NODE_COMPILE_CACHE.
Real environment tested: Native Windows 10 / Git Bash, packed current PR head 563dcf592ec695bf34cf7fd4ba9aee141843fe6a, isolated npm-global prefixes, isolated OpenClaw home/state/config paths, inherited NODE_COMPILE_CACHE, and explicit proof ports (19114 for Node 24.14, 19115 for Node 24.15).
Same artifact for the cutoff comparison: npm pack produced openclaw-2026.6.2.tgz; that same packed artifact was installed and tested under both node@24.14.0 and node@24.15.0.
Exact steps or command run after this patch: node@24.14.0 node_modules/vitest/vitest.mjs run src/entry.compile-cache.test.ts; node@24.15.0 node_modules/vitest/vitest.mjs run src/entry.compile-cache.test.ts; scripts/build-all.mjs; npm pack; npm install -g --prefix <isolated-prefix> openclaw-2026.6.2.tgz for each runtime; with inherited NODE_COMPILE_CACHE, run openclaw --version and openclaw gateway install/start/status/stop/uninstall --json for both Node 24.14 and Node 24.15; instrument openclaw.mjs gateway status --json with --import compile-cache-proof-logger.mjs to capture the actual process/env transition.
Evidence after fix: Maintainer-readable proof summary: focused startup-decision tests passed on native Windows node@24.14.0 and node@24.15.0; the current PR head built and packed successfully; the same packed tarball installed in isolated npm-global prefixes under both runtimes; openclaw --version and gateway install/start/status/stop/uninstall completed successfully for both runtimes; instrumentation showed Node 24.14 takes the no-cache respawn path while Node 24.15 keeps compile cache enabled through the packaged cache path.
Observed result after fix: Focused compile-cache tests passed 19/19 on both native Windows node@24.14.0 and node@24.15.0; build and pack completed; the same packed artifact installed in isolated npm-global prefixes under both runtimes; both runtime proof scripts completed openclaw --version and gateway install/start/status/stop/uninstall with PROOF_RC=0 and gateway RPC ok: true; the Node 24.14 process log proves the no-cache respawn (NODE_DISABLE_COMPILE_CACHE=1, OPENCLAW_COMPILE_CACHE_DISABLED_RESPAWNED=1, inherited NODE_COMPILE_CACHE removed); the Node 24.15 process log proves compile cache remains enabled by repointing NODE_COMPILE_CACHE to the packaged OpenClaw cache path, without the no-cache respawn marker.
What was not tested: I did not find an upstream Node release note, issue, or PR explicitly saying a Windows module-compile-cache deadlock was fixed in Node 24.15. The upstream evidence supports Node 24.15 as the official module-compile-cache stability boundary, while the OpenClaw-specific cutoff is now supported by direct native Windows side-by-side packed-CLI proof. I am not citing the newest doctor --fix --non-interactive comparison attempt as passing proof because it timed out after printing normal doctor output. Full-file test/openclaw-launcher.e2e.test.ts was previously attempted under native Windows Node 24.1 but is not cited as passing proof due unrelated local fixture/runtime behavior.
Fix classification: Root-cause startup fix plus test portability fix for the native-Windows proof runner.

Current-head validation

node@24.14.0: node_modules/vitest/vitest.mjs run src/entry.compile-cache.test.ts passed 19/19 focused tests.
node@24.15.0: node_modules/vitest/vitest.mjs run src/entry.compile-cache.test.ts passed 19/19 focused tests.
scripts/build-all.mjs completed successfully before packing the current PR artifact.
npm pack generated openclaw-2026.6.2.tgz for the native comparison proof.
Isolated npm-global installs from that tarball succeeded under both node@24.14.0 and node@24.15.0.

Native Windows side-by-side cutoff proof

Node 24.14.0 affected side: With inherited NODE_COMPILE_CACHE, the instrumented process log shows the launcher respawned into the protected no-cache path: the child process had NODE_DISABLE_COMPILE_CACHE=1, OPENCLAW_COMPILE_CACHE_DISABLED_RESPAWNED=1, and no inherited NODE_COMPILE_CACHE. The packed CLI then completed openclaw --version and gateway install/start/status/stop/uninstall --json successfully; gateway status showed the listener running and RPC ok: true. The proof script exited PROOF_RC=0.
Node 24.15.0 re-enabled side: With inherited NODE_COMPILE_CACHE, the instrumented process log shows the launcher did not take the no-cache respawn path. Instead, it kept compile cache enabled and repointed NODE_COMPILE_CACHE to the packaged OpenClaw cache directory (.../openclaw/2026.6.2/...), with no NODE_DISABLE_COMPILE_CACHE and no OPENCLAW_COMPILE_CACHE_DISABLED_RESPAWNED. The packed CLI then completed openclaw --version and gateway install/start/status/stop/uninstall --json successfully; gateway status showed the listener running and RPC ok: true. The proof script exited PROOF_RC=0.

Public evidence summary

The validation is summarized here as maintainer-readable commands and observed outcomes, not as local artifact paths:

Focused startup-decision regression test
- Command shape: node_modules/vitest/vitest.mjs run src/entry.compile-cache.test.ts
- Native Windows node@24.14.0: 19/19 tests passed.
- Native Windows node@24.15.0: 19/19 tests passed.
- Covered boundary: Windows Node 24.0-24.14 disables compile cache / no-cache respawns when inherited cache is active; Windows Node 24.15+ keeps compile cache enabled; non-Windows Node 24.0-24.14 keeps compile cache enabled.
Same packed artifact tested on both runtimes
- scripts/build-all.mjs completed.
- npm pack produced openclaw-2026.6.2.tgz.
- That same tarball installed successfully into isolated npm-global prefixes under both node@24.14.0 and node@24.15.0.
Native Windows packed CLI/gateway lifecycle
- Command shape for both runtimes: openclaw --version, then openclaw gateway install --json, gateway start --json, gateway status --json, gateway stop --json, gateway uninstall --json.
- Node 24.14.0: proof script ended PROOF_RC=0; gateway status showed listener 127.0.0.1:19114, server version 2026.6.2, and RPC ok: true.
- Node 24.15.0: proof script ended PROOF_RC=0; gateway status showed listener 127.0.0.1:19115, server version 2026.6.2, and RPC ok: true.
Instrumented compile-cache behavior at the cutoff
- Node 24.14.0 started with inherited NODE_COMPILE_CACHE, then respawned with NODE_DISABLE_COMPILE_CACHE=1 and OPENCLAW_COMPILE_CACHE_DISABLED_RESPAWNED=1; inherited NODE_COMPILE_CACHE was removed before the CLI import path.
- Node 24.15.0 started with inherited NODE_COMPILE_CACHE, did not set NODE_DISABLE_COMPILE_CACHE, did not set OPENCLAW_COMPILE_CACHE_DISABLED_RESPAWNED, and continued with NODE_COMPILE_CACHE pointed at the packaged OpenClaw cache directory under openclaw/2026.6.2/....

This is why the final scope is narrow: protect Windows packaged startup on Node 24.0-24.14, while keeping compile cache enabled for non-Windows installs and Windows Node 24.15+.

What was not claimed

I did not find an upstream Node release note, issue, or PR that explicitly says a Windows module-compile-cache deadlock was fixed in Node 24.15. The upstream evidence supports Node 24.15 as the official module-compile-cache stability boundary (nodejs/node#60971); the direct reason to keep 24.15+ enabled in this PR is now the native Windows side-by-side OpenClaw proof above.
I am not citing the newest doctor --fix --non-interactive comparison attempt as passing proof because that command timed out after printing normal doctor output. The current-head native comparison proof instead uses openclaw --version and the gateway lifecycle, both of which completed with PROOF_RC=0 for Node 24.14 and Node 24.15.
Full-file test/openclaw-launcher.e2e.test.ts was previously attempted under native Windows Node 24.1 but is not cited as passing proof because local Windows fixture/runtime behavior caused unrelated failures; the source boundary is covered by the focused regression test plus packed CLI proof.

Review findings addressed

RF-001 / RF-003 / RF-004 / RF-008: Addressed with fresh native Windows npm-global proof. The packed PR package ran visible CLI startup and gateway lifecycle commands, observed live listeners/RPC, and cleaned up with stop/uninstall.
RF-002 / RF-006: Addressed by focused regression tests plus the new side-by-side native Windows proof. Windows Node 24.14.0 takes the no-cache respawn path; Windows Node 24.15.0 keeps compile cache enabled through the packaged cache path.
RF-005: The compatibility/performance tradeoff is explicitly scoped. Compile cache is disabled only for Windows packaged startup on Node 24.0-24.14; non-Windows packaged installs and Windows Node 24.15+ keep compile cache enabled.
RF-007: The manual acceptance point is no longer an untested cutoff. There is still no Windows-deadlock-specific upstream Node note, but the PR now contains direct Windows packed-CLI proof at the exact 24.14 / 24.15 boundary.
RF-009: Addressed with current-head focused verification and native packed CLI/gateway behavior proof.

Regression Test Plan

Target test file: src/entry.compile-cache.test.ts; launcher startup behavior is additionally covered by native packed npm-global proof.
Scenario locked in: Early Node 24.x disables compile cache on Windows packaged installs and on the packaged launcher; inherited NODE_COMPILE_CACHE triggers a one-shot no-cache respawn for affected Windows packaged startup; compile cache stays enabled for early Node 24.x on Linux/macOS packaged startup and for Node 24.15+ / Node 22 / Node 25 on Windows packaged startup.
Why this is the smallest reliable guardrail: The changed behavior is a startup decision before command execution. Injecting nodeVersion and platform directly proves the decision boundary, while the native npm-global proof covers the reported Windows packaged-startup class and the exact cutoff behavior.

Root Cause

Root cause: OpenClaw enables or inherits Node's compile cache during packaged CLI startup before importing the full CLI. The linked issue reports a startup hang on native Windows npm-global with early Node 24.x at that entry stage. The source of the failure is the startup-level compile-cache state before command dispatch, not gateway, plugin, channel, provider, or command-specific code.
Why this is root-cause fix: The patch blocks OpenClaw's compile-cache API use for Windows packaged startup on Node 24.0-24.14 and respawns affected packaged startup when NODE_COMPILE_CACHE was inherited, setting NODE_DISABLE_COMPILE_CACHE=1 and removing NODE_COMPILE_CACHE before the runtime entry import. That removes the reported entry-level deadlock trigger for the affected Windows packaged startup class while preserving the existing compile-cache contract outside that boundary.

Scope and architecture

What did NOT change: No unrelated gateway behavior, plugin/channel/provider code, config surface, dependency, lockfile, docs, or unrelated startup path changed. The only behavior change is the compile-cache startup default and inherited-cache respawn for Windows packaged Node 24.0-24.14; unrelated CLI startup hangs remain out of scope.
Architecture / source-of-truth check: The source-of-truth boundary is split by runtime artifact: src/entry.compile-cache.ts is the canonical typed entry helper, and openclaw.mjs is the canonical packaged launcher pre-import compile-cache path. Both now apply the same Windows Node 24.0-24.14 contract before calling enableCompileCache(...), inheriting compile cache, or respawning for packaged compile cache.
Compatibility / related open PR scan: The compatibility-sensitive surface is packaged CLI startup defaulting, and this patch keeps the behavior change scoped to affected Windows early-Node-24 packaged startup. check-upstream-fixed reported current origin/main does not already cover this PR.

Patch quality notes

Patch quality notes: The no-cache respawn is intentionally limited to source checkouts that already needed inherited-cache cleanup and to Windows packaged Node 24.0-24.14, where inherited compile cache can preserve the startup hang. The default for every other packaged runtime remains the existing compile-cache-enabled path. The added return false branches are explicit guard exits for unavailable/malformed version input or already-disabled compile-cache state; they are not silent product fallbacks and they preserve the previous default behavior outside the affected boundary. No new dependencies, config knobs, fallback stacks, or runtime shims were added.
Test quality notes: The added explicit platform/runtime cases keep the focused test valid when run from native Windows Node 24.x and verify both sides of the cutoff.

Merge risk

Risk labels considered: merge-risk: availability, merge-risk: compatibility.
Risk explanation: Availability risk is the reported Windows startup hang. Compatibility/performance risk is changing packaged startup compile-cache behavior.
Why acceptable: Compile cache is a startup optimization, while the reported failure prevents the CLI from starting at all. The patch preserves compile cache outside the Windows early-Node-24 boundary, and the new native Windows side-by-side proof shows the exact 24.14 / 24.15 cutoff behaves as intended.

clawsweeper · Jun 3, 2026

Codex review: needs maintainer review before merge. Reviewed June 15, 2026, 5:27 AM ET / 09:27 UTC.

Summary
The PR changes the OpenClaw packaged launcher and TypeScript entry compile-cache helper so Windows packaged installs on Node 24.0-24.14 skip or respawn out of Node compile cache while unaffected runtimes keep it enabled.

PR surface: Source +38, Tests +241, Other +18. Total +297 across 4 files.

Reproducibility: yes. from source and linked issue context, but not independently reproduced in this read-only pass. Current main enables packaged compile cache before CLI import, and the linked issue gives concrete Windows npm-global Node 24.1 steps for commands that hang before output.

Review metrics: 1 noteworthy metric.

Compile-cache runtime boundary: 1 affected window disabled; 3 neighboring runtime classes preserved. The cutoff is the merge-sensitive behavior: Windows Node 24.0-24.14 is protected while Windows 24.15+, non-Windows early Node 24, and other majors keep compile cache.

Stored data model
Persistent data-model change detected: persistent cache schema: test/openclaw-launcher.e2e.test.ts, serialized state: test/openclaw-launcher.e2e.test.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Maintainer should decide whether the Node 24.15 re-enable boundary is acceptable, since the PR already supplies focused tests and native Windows packed-CLI proof.

Risk before merge

[P1] If the Node 24.15 cutoff is wrong, Windows packaged users on Node 24.15+ could still hit the startup hang because compile cache remains enabled there.
[P1] The PR intentionally changes startup cache behavior for an existing packaged install class; maintainers should accept the availability/performance tradeoff before merge.

Maintainer options:

Accept the narrow cutoff with proof (recommended)
Merge after maintainer review accepts the Windows Node 24.0-24.14 no-cache boundary and the Node 24.15 re-enable proof in the PR body.
Widen the protected Windows range
Ask for a patch that keeps compile cache disabled for a wider Windows Node 24 range if maintainers do not want to rely on the 24.15 cutoff.
Pause for upstream-specific evidence
Hold the PR if maintainers require an upstream note that explicitly names the Windows compile-cache deadlock before changing startup behavior.

Next step before merge

[P2] Maintainer review should accept or adjust the compatibility-sensitive Node 24.15 cutoff; there is no narrow automated repair to apply from this review.

Security
Cleared: The diff changes startup logic and tests only; no dependency, workflow, lockfile, secret, or package-execution supply-chain concern was found.

Review details

Best possible solution:

Land this narrow startup-boundary fix if maintainers accept the Windows Node 24.0-24.14 cutoff and the supplied native Windows packed-CLI proof; otherwise adjust the protected Windows range before merge.

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

Yes from source and linked issue context, but not independently reproduced in this read-only pass. Current main enables packaged compile cache before CLI import, and the linked issue gives concrete Windows npm-global Node 24.1 steps for commands that hang before output.

Is this the best way to solve the issue?

Yes, conditionally: this is the best available fix shape because it touches both pre-import startup entry points and keeps unaffected runtimes enabled. The only remaining solution-fit question is maintainer acceptance of the Node 24.15 cutoff rather than the code layer.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies after-fix native Windows packed-CLI and gateway lifecycle terminal proof for Node 24.14 and Node 24.15 with inherited NODE_COMPILE_CACHE.
add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body supplies after-fix native Windows packed-CLI and gateway lifecycle terminal proof for Node 24.14 and Node 24.15 with inherited NODE_COMPILE_CACHE.
remove rating: 🌊 off-meta tidepool: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.

Label justifications:

P1: The PR targets a user-facing CLI startup hang that can block basic OpenClaw commands on affected Windows npm-global installs.
merge-risk: 🚨 compatibility: The patch changes startup compile-cache behavior for an existing packaged install/runtime class and deliberately preserves it for neighboring runtimes.
merge-risk: 🚨 availability: The affected surface is CLI startup, where an incorrect runtime boundary can leave users hanging or reintroduce startup stalls.
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 (terminal): The PR body supplies after-fix native Windows packed-CLI and gateway lifecycle terminal proof for Node 24.14 and Node 24.15 with inherited NODE_COMPILE_CACHE.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body supplies after-fix native Windows packed-CLI and gateway lifecycle terminal proof for Node 24.14 and Node 24.15 with inherited NODE_COMPILE_CACHE.

Evidence reviewed

PR surface:

Source +38, Tests +241, Other +18. Total +297 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	41	3	+38
Tests	2	246	5	+241
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	1	23	5	+18
Total	4	310	13	+297

What I checked:

Repository policy read: Root AGENTS.md and test/AGENTS.md were read fully; the review applied the compatibility-sensitive startup/fallback guidance and the test scoped fake-timer guidance. (AGENTS.md:1, 233b48daaab4)
Live PR context: GitHub reports the PR open, cleanly mergeable, with head d27faf9, closing [Bug]: #86550, and touching only the launcher, compile-cache helper, and focused tests. (d27faf9ff9d0)
Current main TS entry still lacks cutoff: On current main, shouldEnableOpenClawCompileCache only respects NODE_DISABLE_COMPILE_CACHE and source-checkout detection, with no Windows/Node 24.0-24.14 exclusion. (src/entry.compile-cache.ts:34, 233b48daaab4)
Current main packaged launcher still lacks cutoff: The packaged launcher on current main may respawn to scope NODE_COMPILE_CACHE and then calls module.enableCompileCache for packaged installs without checking the Windows early-Node-24 boundary. (openclaw.mjs:219, 233b48daaab4)
Caller path checked: src/entry.ts calls respawnWithoutOpenClawCompileCacheIfNeeded before normal bootstrap and then enableOpenClawCompileCache, so the helper is the right pre-import startup boundary for the runtime entry path. (src/entry.ts:92, 233b48daaab4)
Latest release lacks this PR's targeted guard: v2026.6.6 still has the same broad packaged compile-cache behavior and no MIN_COMPILE_CACHE_NODE_24_MINOR or Windows cutoff, so this PR is not already shipped. (src/entry.compile-cache.ts:34, 8c802aa68351)

Likely related people:

steipete: GitHub commit history shows recent source-checkout compile-cache disabling and packaged compile-cache scoping in the central files this PR changes. (role: recent area contributor; confidence: high; commits: 36d3722a964a, 52b57d095341, 0e4040837573; files: src/entry.compile-cache.ts, openclaw.mjs, test/openclaw-launcher.e2e.test.ts)
vincentkoc: Recent history shows respawn-child shutdown and entry-startup work in the same launcher and compile-cache helper surfaces. (role: adjacent startup contributor; confidence: medium; commits: 00004ca798d9, 58c8c022c5ec, 805bff6e7e1f; files: src/entry.compile-cache.ts, openclaw.mjs, src/entry.ts)
kevinslin: Commit 592998a modified the launcher, compile-cache helper, and launcher E2E tests to clean up respawn child process behavior adjacent to this change. (role: adjacent respawn contributor; confidence: medium; commits: 592998ae0eff; files: openclaw.mjs, src/entry.compile-cache.ts, test/openclaw-launcher.e2e.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

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.

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.

byungskers · Jun 3, 2026

The mitigation makes sense, but I want to flag one scope question for maintainers: the issue description here is specifically Windows npm-global installs, while the guard disables compile cache for all Node 24.0–24.14 environments.

That broader blast radius may still be the right tradeoff for now, but if the repro really is limited to Windows/global-install topology, it might be worth considering whether the skip can be narrowed so macOS/Linux users on those Node minors don’t lose compile-cache performance unnecessarily.

zhangguiping-xydt · Jun 13, 2026

@clawsweeper re-review

clawsweeper · Jun 13, 2026

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Failed
Detail: The targeted re-review did not finish cleanly. Check the workflow run for details.
Run: https://github.com/openclaw/clawsweeper/actions/runs/27452669275
Updated: 2026-06-13T01:39:19.918Z

vincentkoc · Jun 16, 2026

Maintainer verification on exact head 0deae6a01507c021277271348b9c5d0ddda41a64:

47 focused compile-cache and packaged-launcher tests passed; 2 platform-specific tests skipped.
Targeted oxfmt, oxlint, and diff checks passed.
Native Azure Windows proof passed on Crabbox lease cbx_e67352632e3a, run run_3513a0eaac00: Node 24.14 reached the child with compile cache disabled and inherited cache removed; Node 24.15 retained the packaged compile-cache path.
Fresh Codex autoreview found no accepted/actionable findings at 0.88 confidence.
Exact-head CI completed. The failing type/boundary and session-snapshot shards reproduce on current main at 63825369a24db68fb553b3df6320be8f318a6937; all changed-surface checks passed and no required checks are configured.

Known gap: upstream Node release notes do not identify the OpenClaw-specific deadlock cutoff. The 24.15 boundary is supported by direct native Windows comparison proof.

vincentkoc · Jun 16, 2026

Superseding maintainer verification on final exact head c43a6132a3e615ffe59f92662e9238e4e8f60013:

The contributor branch was truly rebased onto main; the PR now contains only openclaw.mjs, src/entry.compile-cache.ts, its unit test, and the packaged-launcher e2e test.
Range-diff confirms the six-commit repair patch is unchanged from the natively proven version.
47 focused tests passed on the final head; 2 platform-specific tests skipped.
Targeted oxfmt, oxlint, build, and diff checks passed.
Azure Windows Crabbox proof remains applicable to the unchanged patch: lease cbx_e67352632e3a, run run_3513a0eaac00.
Final Codex autoreview found no accepted/actionable findings at 0.90 confidence.
Exact-head CI completed. The six failing type/boundary/session-snapshot shards match the established current-main baseline; all changed-surface checks passed and no required checks are configured.

Known gap: upstream Node release notes do not identify the OpenClaw-specific deadlock cutoff. The 24.15 boundary is supported by direct native Windows comparison proof.

…lock Node 24.0-24.14 enableCompileCache() can deadlock the ESM module loader on Windows npm-global installs, causing CLI to hang at startup. The release CI pins 24.15+ where this is not reproducible. Skip compile cache for Node 24.x < 24.15. Once users upgrade, the cache re-enables automatically. Fixes openclaw#86550

vincentkoc · Jun 16, 2026

Merged via squash.

Prepared head SHA: 46341b26fb2e174ea0d1672fde9274f61603fca1
Merge commit: b5648b1d5ee0f21823ad5873f717a6532000b09a

Thanks @zhangguiping-xydt!

openclaw-barnacle Bot added size: S proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 3, 2026

openclaw-barnacle Bot added size: M and removed size: S labels Jun 3, 2026

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 4, 2026

zhangguiping-xydt force-pushed the feat/issue-86550 branch from 6f2bb2b to 5761118 Compare June 4, 2026 13:19

openclaw-barnacle Bot removed the proof: sufficient ClawSweeper judged the real behavior proof convincing. label Jun 4, 2026

This was referenced Jun 15, 2026

openclaw status CLI command hangs before connecting to gateway (v2026.5.18) #84012

Closed

[Bug]: cli、regression #86546

Closed

[Bug]: #86550

Closed

zhangguiping-xydt and others added 6 commits June 16, 2026 15:58

fix(cli): scope Node 24 compile cache skip to Windows

478fbad

fix(cli): guard launcher compile cache on Windows Node 24

da4b259

fix(cli): clear inherited compile cache on Windows Node 24

ef6d3e1

test(cli): pin unaffected compile-cache runtime in test

0528ac2

style(cli): keep compile-cache comment ASCII

46341b2

github-actions Bot mentioned this pull request Jun 16, 2026

📡 Upstream Digest — 2026-06-16 09:19 UTC curtismercier/openclaw-mods#1087

Open

clawsweeper Bot mentioned this pull request Jun 18, 2026

Launcher: compile-cache root comparison can trigger unnecessary respawn on every run #82688

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(cli): skip compile cache on early Node 24.x to avoid startup deadlock - #89799

fix(cli): skip compile cache on early Node 24.x to avoid startup deadlock#89799
vincentkoc merged 6 commits into
openclaw:mainopenclaw/openclaw:mainfrom
zhangguiping-xydt:feat/issue-86550zhangguiping-xydt/openclaw:feat/issue-86550Copy head branch name to clipboard

zhangguiping-xydt commented Jun 3, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading

Uh oh!

byungskers commented Jun 3, 2026

Uh oh!

zhangguiping-xydt commented Jun 13, 2026

Uh oh!

clawsweeper Bot commented Jun 13, 2026 •

edited

Loading

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Search code, repositories, users, issues, pull requests...

Uh oh!

Uh oh!

Conversation

zhangguiping-xydt commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Maintainer-ready summary

Real behavior proof

Current-head validation

Native Windows side-by-side cutoff proof

Public evidence summary

What was not claimed

Review findings addressed

Regression Test Plan

Root Cause

Scope and architecture

Patch quality notes

Merge risk

Uh oh!

clawsweeper Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

byungskers commented Jun 3, 2026

Uh oh!

zhangguiping-xydt commented Jun 13, 2026

Uh oh!

clawsweeper Bot commented Jun 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

vincentkoc commented Jun 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zhangguiping-xydt commented Jun 3, 2026 •

edited

Loading

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading

clawsweeper Bot commented Jun 13, 2026 •

edited

Loading