Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

BUG: Windows ESM loader fails for bundled plugins after cold registry update in v2026.4.25

• Version: v2026.4.25
• OS: Windows
• Component: Plugin Loader, Bundled Channels (e.g., Telegram, iMessage)

Summary

After updating to v2026.4.25, bundled channel plugins like telegram and imessage fail to load on Windows. The gateway log shows a repeating error: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'.

This appears to be a regression introduced by the new "cold persisted registry" architecture for plugin loading.

Logs

05:36:21 [telegram] [default] channel exited: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'
05:36:21 [telegram] [default] auto-restart attempt 2/10 in 10s
...
05:39:50 [channels] failed to load bundled channel imessage: No "exports" main defined in C:\Users\kaido\.openclaw\plugin-runtime-deps\openclaw-20...

Analysis

The root cause is likely that the new lazy-loading mechanism, introduced in v2026.4.25 for performance, is passing raw Windows absolute paths (e.g., C:\...) directly to Node.js's dynamic import() function.

• The ESM loader expects URL-like paths, specifically file:// URLs for local files on Windows.
• The error message Received protocol 'c:' confirms that a raw path is being treated as a URL, failing the scheme check.
• The issue is tied to the architectural shift towards a "cold persisted registry," as noted in the v2026.4.25 release notes. This new code path seems to have missed the necessary pathToFileURL conversion for Windows environments.
• The No "exports" main defined error for other plugins (imessage) is likely a downstream effect of this initial path resolution failure.

This is a regression from v2026.4.23 and v2026.4.24, where plugin loading was more direct and presumably handled path normalization correctly. The issue is not with the individual plugins but with the core loader itself.

Proposed Temporary Workaround (Monkey Patch)

A temporary fix could involve creating a patch that intercepts the problematic import() calls and wraps the Windows path with pathToFileURL before execution. This would restore functionality without modifying the core OpenClaw source, ensuring future updates can be applied cleanly.

Suggested Permanent Fix

The core plugin loader should be updated to use pathToFileURL from Node's url module when resolving plugin paths on the Windows platform before passing them to the ESM import() loader.

Steps to reproduce

Requirement: "Provide the shortest deterministic repro path supported by direct observation." Input Example: Start OpenClaw 2026.2.17 with the attached config. Send a Telegram thread reply in the affected chat. Observe no reply and confirm the attached reply target not found log line. Analysis: This section demands a concrete, minimal, and verifiable sequence of actions. It requires evidence-based reporting, not speculation. The key is "direct observation."

Expected behavior

Requirement: "State the expected result using a concrete reference such as prior observed behavior, attached docs, or a known-good version." Input Example: "In 2026.2.10, the agent posted replies in the same Telegram thread under the same workflow." Analysis: This establishes a baseline. The report must compare the buggy behavior to a "known-good" state, citing a specific version number or documented feature. This prevents reports based on user assumptions about how a feature should work.

Actual behavior

Requirement: "Describe only the observed result, including user-visible errors and cited evidence." Input Example: [Empty in the provided text, but would contain logs/screenshots] Analysis: This section is for raw, factual evidence of the failure. It should include logs, error messages, and screenshots, directly linked to the "Steps to reproduce."

OpenClaw version

2026.4.24

Operating system

Windows11

Install method

npm

Model

cliproxyai/Codex GPT5.5

Provider / routing chain

Gateway Start → Cold Registry Read → Telegram Enable → Lazy Load Trigger → Path Resolution Bug → ESM Loader Error → Restart Loop

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response