Summary

• Problem: On Windows multi-instance deployments (5x PM2 workers, OpenClaw 2026.4.27, Node v22.x), bundled channels fail to load with ENOENT on shared dist chunks under ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-<hash>/dist/*.js (e.g. channel-reply-pipeline-DIVeGRyD.js, channel-options-UH47ik5d.js, cache-controls-DyMccij0.js). Different processes — and even different code paths inside the same process — derive different <hash> values for the same physical install, so loaders look up files in a stage directory that was populated under a different key. Site of the divergence: src/plugins/bundled-runtime-deps-roots.ts:55-57, createPathHash, which hashes path.resolve(value) instead of the canonical filesystem path.
• Root Cause: createPathHash did not canonicalize the packageRoot to its OS-real path before hashing — it only normalized lexically via path.resolve. The two consumers of this hash arrive with different lexical forms of the same physical directory:
  • Loader path: src/plugins/loader.ts:1419 produces pluginRoot = safeRealpathOrResolve(candidate.rootDir) which already resolves symlinks via fs.realpathSync. Walking up to packageRoot yields the realpath form (e.g. C:\Users\<u>\.npm\node_modules\openclaw).
  • Bundled-channel path: src/channels/plugins/bundled.ts:206-211 calls resolveBundledChannelBoundaryRoot with params.rootScope.packageRoot, which originates from OPENCLAW_PACKAGE_ROOT in src/channels/plugins/bundled-root.ts and is not realpath-normalized. Walking up yields the symlinked form (e.g. C:\Users\<u>\AppData\Roaming\npm\node_modules\openclaw).
    Because path.resolve only normalizes path components — it does not resolve symlinks, junctions, or drive-letter casing — the same physical install hashes to two different 12-char keys (matching the two values reported in [BUG] 4.27 multi-instance: plugin-runtime-deps hash mismatch causes ENOENT on bundled channel dist files #74963: 5f4e2e59ed9a and 456555aaef5c). The loader stages dist chunks into hash-A's directory; the channel loader then opens hash-B and gets ENOENT. PM2 multi-instance amplifies the symptom because each worker can independently produce a third lexical form via its argv1/cwd context, but the bug also reproduces single-instance whenever an npm symlink, Windows junction, or drive-letter casing variant is in play.
• Fix: Hash the OS-canonical (realpath) form of packageRoot instead of the lexical form. createPathHash now delegates path normalization to the file-local realpathOrResolve helper (src/plugins/bundled-runtime-deps-roots.ts:240), which calls fs.realpathSync.native(value) and falls back to path.resolve(value) only when the path does not yet exist. This is the same canonicalization already used by resolveExistingExternalBundledRuntimeDepsRoots to detect already-staged package roots, so the file's two normalization sites are now consistent. Side-effect surface stays small: createPathHash is reachable from exactly one caller (resolveExternalBundledRuntimeDepsInstallRoots, line 213); no other call site re-implements the hash format. Existing 4.27 stage directories created with the old (lexical) hash become orphaned on disk after upgrade — they are not referenced by the new key but cause no functional regression; first start after upgrade re-stages once into the canonical directory and all subsequent starts (including all PM2 workers) share it. The fallback to path.resolve preserves the old behavior in the degenerate case where the package root has been deleted between resolution and hashing.
• What changed:
  • src/plugins/bundled-runtime-deps-roots.ts: createPathHash now hashes realpathOrResolve(value) instead of path.resolve(value); one-line behavioral change plus a two-line comment explaining why.
  • src/plugins/bundled-runtime-deps.test.ts: new regression test stages bundled runtime deps to the same root for symlinked packageRoot views (issue #74963) — creates a real package root and a sibling symlink to it, calls resolveBundledRuntimeDependencyInstallRoot via both views, and asserts the two install roots are byte-equal and match the openclaw-<version>-<12-hex> shape. Skipped on win32 to follow the existing itSupportsSymlinks precedent at line 2938 (Windows symlink creation requires admin in CI).
• What did NOT change (scope boundary):
  • No CHANGELOG.md entry — left for maintainers to place under the active release section per their preferred phrasing/credit format.
  • No change to realpathOrResolve itself, the file lock implementation (bundled-runtime-deps-lock.ts), the dist-mirror cache (bundled-runtime-dist-mirror-cache.ts), the channel loader (src/channels/plugins/bundled.ts), or the manifest discovery flow (src/plugins/loader.ts). The fix is intentionally confined to the hashing seam; it does not also "fix" the lexical inconsistency between the loader and channel call sites because doing so would broaden the surface (hot import paths per src/channels/CLAUDE.md) without changing the observable outcome — converging the hash already converges the stage directory.
  • No change to the existing path.resolve(installRoot) hash construction inside the test at bundled-runtime-deps.test.ts:2444. That value is computed only as the right-hand side of a .not.toBe assertion (line 2450), so the assertion still holds: the resolver returns the canonical installRoot, which is not equal to any hypothetical fallback root — regardless of whether the fallback is computed lexically or canonically.
  • No new env vars, no new public API, no new types, no any, no behavioral change for source-checkout layouts (the source-checkout branch in resolveBundledRuntimeDependencyInstallRootPlan/resolveBundledRuntimeDependencyPackageInstallRootPlan short-circuits before reaching createPathHash).
  • No deprecation, no migration shim. Existing stage dirs from the buggy hash become disk-resident orphans; they are version-prefixed (openclaw-2026.4.27-*) so the existing prune logic at pruneUnknownBundledRuntimeDepsRoots (which targets openclaw-unknown-*) leaves them alone — same as any prior version's stage directory. Disk cost is bounded and one-time.

Reproduction

1. On Windows, run 5 OpenClaw 2026.4.27 gateway instances under PM2 against the same install (or, simpler, expose the install via two paths — one canonical and one through an npm/Windows junction).
2. Boot the gateway; observe [channels] failed to load bundled channel <id>: ENOENT for several channels (Discord, Feishu, Google Chat, iMessage, LINE, IRC).
3. Inspect ~/.openclaw/plugin-runtime-deps/: two or more directories named openclaw-2026.4.27-<12-hex> exist with the same version prefix but different hashes. The chunks named in the ENOENT messages exist under one hash but the failing process is reading from the other.

After applying this PR, only one such directory exists per version and all instances/call sites resolve to it.

Equivalent unit-level reproduction (already wired in this PR): pnpm test src/plugins/bundled-runtime-deps.test.ts -t "issue #74963" — fails on main (two install roots), passes after the fix.

Risk / Mitigation

• Risk — Stage-directory churn on upgrade: existing 2026.4.27 deployments will create one new realpath-keyed stage directory on first run and leave the old lexical-keyed directory(ies) behind. This is a one-time disk cost (single-digit GB at worst, dependent on the bundled plugin runtime-deps tree size); subsequent starts share the new directory.
  Mitigation: behavior is identical to any major version's stage directory rotation, no operator action is required. The orphaned directory is version-prefixed so it does not collide with any future hash and does not get pruned by the openclaw-unknown-* cleanup; operators who care about disk usage can rm -rf it manually or wait for the next major version's natural rotation.
• Risk — realpathSync.native failing on a path that does exist: would silently fall back to path.resolve, reproducing the old (buggy) hash. In practice realpathSync.native only fails on ENOENT/EACCES/loop-detection; the packageRoot here is the parent of the dist tree we just enumerated, so it is guaranteed to exist at this point in the flow.
  Mitigation: the fallback preserves the pre-fix behavior, so failure mode is "no improvement", not "new regression". The added regression test exercises the realpath path on Linux/macOS; the Windows-skipped path still benefits from realpath's native libuv resolver in production where realpathSync.native is the canonical Windows realpath.
• Risk — Test flakiness on macOS due to /tmp → /private/tmp symlinking: the new test creates its own intra-tempdir symlink (linkedPackageRoot → realPackageRoot), so it does not rely on /tmp being or not being a symlink — both sides go through the same realpathSync.native.
  Mitigation: tested mentally against macOS /var/folders/.../T (os.tmpdir() default) and Linux /tmp; the test asserts equality between two resolver calls, both of which canonicalize identically.
• Risk — Performance regression: one fs.realpathSync.native stat per createPathHash call.
  Mitigation: createPathHash is invoked only inside resolveExternalBundledRuntimeDepsInstallRoots, which runs at plugin discovery time (cold start), not on the hot request path. Negligible measured impact.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Plugins
• Bundled runtime deps
• Channels (downstream consumer of the converged stage directory)

Linked Issue/PR

Fixes #74963