PR #63906: Handle native ELF binaries execution on WSL

• Repository: openclaw/openclaw
• Author: vincenthsin
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/63906

Description (problem / solution / changelog)

Summary

• Problem: On WSL with a standalone pnpm install, npm_execpath points to a native ELF binary. pnpm-runner.mjs detected it as a pnpm path and invoked it as node <elf-binary>, causing a SyntaxError: Invalid or unexpected token crash on every build.
• Why it matters: The build is completely broken on WSL with standalone pnpm — no workaround short of reinstalling pnpm via npm/corepack.
• What changed: resolvePnpmRunner in scripts/pnpm-runner.mjs now checks whether npm_execpath ends in .js or .cjs. If it does, it runs via node (existing behavior). If not (native binary), it executes the binary directly as the command.
• What did NOT change: All other platforms are unaffected. Windows takes the win32 branch before this check. macOS and Linux npm/corepack installs still go through node. No build logic, config, or plugin SDK changes.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes #63862

Root Cause (if applicable)

• Root cause: resolvePnpmRunner assumed any path matching the pnpm filename pattern could be run via node <path>. This holds for JS-based installs but breaks when the path is a native ELF binary, which Node.js cannot interpret as a script.
• Missing detection / guardrail: No check on whether the resolved executable is a JS file vs. a native binary before choosing the invocation strategy.
• Contributing context: pnpm's standalone Linux installer distributes a native ELF binary (via @pnpm/exe). When pnpm runs a script, it sets npm_execpath to this binary's path. Node v24 no longer silently ignores the parse error — it throws immediately.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: scripts/pnpm-runner.test.mjs (new or existing)
• Scenario the test should lock in: When npmExecPath matches the pnpm pattern but has no .js/.cjs extension, resolvePnpmRunner must return the binary path as command, not as an arg to nodeExecPath.
• Why this is the smallest reliable guardrail: Pure unit test on the resolver function — no process spawning needed, no platform dependency.
• Existing test that already covers this: None.
• If no new test is added, why not: N/A — test should be added.

User-visible / Behavior Changes

Build no longer crashes on WSL with a standalone pnpm install. No other user-visible change.

Diagram (if applicable)

Before:
[pnpm runs build] -> npm_execpath=/path/to/pnpm (ELF)
                  -> node /path/to/pnpm (ELF) -> SyntaxError crash

After:
[pnpm runs build] -> npm_execpath=/path/to/pnpm (ELF)
                  -> isJsScript = false
                  -> exec /path/to/pnpm directly -> success

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No — the same binary is invoked; only the invocation method changes (direct exec vs. node wrapper).
• Data access scope changed? No

Repro + Verification

Environment

• OS: Ubuntu 24 on WSL2 (Windows host)
• Runtime/container: Node.js v24.14.1
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): pnpm 10.33.0 standalone install (~/.local/share/pnpm/pnpm)

Steps

1. Install pnpm via standalone installer on WSL2
2. Run pnpm build from repo root
3. Observe SyntaxError: Invalid or unexpected token at @pnpm+exe/.../pnpm:1

Expected

• Build completes successfully

Actual

• Build crashes immediately with Node.js trying to parse ELF binary as JS

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: pnpm build completes on WSL2 with standalone pnpm after the fix.
• Edge cases checked: macOS (corepack install), Linux npm install — both follow existing code path unchanged. Windows not applicable (separate branch).
• What you did not verify: macOS standalone pnpm install (Mach-O binary path).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: macOS standalone install ships a Mach-O binary with no .js extension — would take the new direct-exec path. If pnpm previously worked on macOS standalone via the node path (unlikely), this could regress it.
  • Mitigation: macOS standalone pnpm installs were already broken by the same logic if npm_execpath was set — direct exec is strictly more correct for native binaries on any platform.

Changed files

• scripts/pnpm-runner.mjs (modified, +17/-5)