Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Windows Telegram provider still crashes with ERR_UNSUPPORTED_ESM_URL_SCHEME in 2026.4.24 unless native Jiti is disabled [1 pull requests, 3 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71749•Fetched 2026-04-26 05:08:53
View on GitHub
Comments
3
Participants
4
Timeline
10
Reactions
0
Author
smeyer9smeyer9
Participants
AdminExcellenc3AdminExcellenc3jonathanbcall-cmykjonathanbcall-cmyksmeyer9smeyer9steipetesteipete
Timeline (top)
commented ×3cross-referenced ×3closed ×1labeled ×1

On native Windows, OpenClaw 2026.4.24 starts successfully, but the Telegram provider crash-loops on startup with:

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 happens even after a clean reinstall and after isolating external plugins. The gateway itself is reachable, but Telegram stays stopped until a local hotfix disables native Jiti loading on Windows in the shared plugin loader path.

This appears related to the previously fixed Windows ESM path issue, but the fix seems incomplete for Telegram/channel provider loading in 2026.4.24.

Error Message

Before local patch:

OpenClaw 2026.4.24 (cbcfdf6) Node: v24.14.1 npm: 11.11.0 Install path: C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw

Gateway startup:

[gateway] loading configuration… [gateway] resolving authentication… [gateway] starting... [gateway] starting HTTP server... [canvas] host mounted at http://0.0.0.0:18789/__openclaw__/canvas/ [gateway] agent model: openrouter/deepseek/deepseek-v4-pro [gateway] ready (4 plugins: active-memory, browser, device-pair, telegram) [gateway] starting channels and sidecars... [telegram] [default] starting provider (@redacted) [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:' [telegram] [default] auto-restart attempt 1/10 in 5s

Status before patch:

Gateway reachable.

  • Telegram default: enabled, configured, stopped, mode:polling, bot:@redacted, token:config, works, 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:'

Isolation test:

  • lossless-claw disabled
  • plugins.load.paths emptied
  • contextEngine set to legacy
  • gateway started with only 4 plugins: active-memory, browser, device-pair, telegram
  • same Telegram provider crash occurred

Environment override attempted and did not fix it: JITI_TRY_NATIVE=0 JITI_REBUILD_FS_CACHE=1 OPENCLAW_DIAGNOSTICS=telegram.,gateway.,channels.*

Local hotfix that made Telegram work:

  1. Patched: C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\runtime-web-channel-plugin-DJqeP2uH.js

Changed: const tryNative = shouldPreferNativeJiti(modulePath);

To: const tryNative = process.platform !== "win32" && shouldPreferNativeJiti(modulePath);

This alone did not fix the crash.

  1. Patched: C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\sdk-alias-K6JYDrXB.js

Changed: function resolvePluginLoaderJitiTryNative(modulePath, options) {

To: function resolvePluginLoaderJitiTryNative(modulePath, options) { if (process.platform === "win32") return false;

This fixed Telegram provider startup.

After patch:

[telegram] [default] starting provider (@redacted)

Status after patch:

Gateway reachable.

  • Telegram default: enabled, configured, running, connected, mode:polling, bot:@redacted, token:config, works

Telegram messages are now processed successfully:

[diagnostic] message processed: channel=telegram chatId=telegram:REDACTED messageId=REDACTED sessionId=unknown sessionKey=agent:main:main outcome=completed

Root Cause

The gateway starts, but Telegram cannot run at all. Users see no responses in Telegram because the provider crash-loops during startup.

Fix Action

Fix / Workaround

This happens even after a clean reinstall and after isolating external plugins. The gateway itself is reachable, but Telegram stays stopped until a local hotfix disables native Jiti loading on Windows in the shared plugin loader path.

Observed status before local patch:

After applying a local patch to disable native Jiti on Windows in the shared plugin loader helper, Telegram starts and works:

PR fix notes

PR #71755: fix(plugins): force non-native jiti on Windows to avoid ERR_UNSUPPORTED_ESM_URL_SCHEME

Description (problem / solution / changelog)

Summary

Fixes #71749. On native Windows, OpenClaw 2026.4.24's gateway starts but the Telegram channel provider crash-loops on startup with:

ERR_UNSUPPORTED_ESM_URL_SCHEME: 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 regresses an earlier fix tracked in #61911 and reproduces in a clean reinstall, with external plugins disabled, even with only the four bundled plugins (active-memory, browser, device-pair, telegram) loaded.

Root cause

jiti's native import() fast-path forwards the resolved module path directly to Node's ESM loader. On Windows, Node's loader requires file:// URLs and rejects raw absolute paths like C:\Users\…\node_modules\openclaw\dist\…, hence Received protocol 'c:'. Until jiti normalizes those paths via pathToFileURL upstream, the right answer in OpenClaw is to force the non-native (vfs/transpile) jiti path on win32.

The reporter independently arrived at this conclusion and confirmed end-to-end: patching resolvePluginLoaderJitiTryNative in the installed dist to return false when process.platform === "win32" makes the Telegram provider start and Telegram messages flow normally.

Fix

Single chokepoint: supportsNativeJitiRuntime() in src/plugins/sdk-alias.ts already gates both shouldPreferNativeJiti and resolvePluginLoaderJitiTryNative. Add process.platform === "win32" alongside the existing Bun exclusion so both APIs short-circuit consistently:

function supportsNativeJitiRuntime(): boolean {
  const versions = process.versions as { bun?: string };
  if (typeof versions.bun === "string") return false;
  if (process.platform === "win32") return false;   // new
  return true;
}

Tests

Two existing tests in sdk-alias.test.ts previously locked in the broken native-on-win32 behavior:

  • prefers native Jiti loads on Windows for built JavaScript entries
  • keeps plugin loader dist shortcuts native on Windows

Both are rewritten to assert the fixed behavior, with a comment pointing back to this issue. macOS / Linux / Bun expectations are unchanged.

Behavior matrix

PlatformBuilt .js plugin entriesTS plugin entriesBundled dist/extensions/*
Linux/macOSnative (unchanged)transpile (unchanged)native (unchanged)
Buntranspile (unchanged)transpile (unchanged)transpile (unchanged)
Windowstranspile (fix)transpile (unchanged)transpile (fix)

Risk

Low. The transpile path is what every Windows install was effectively forced into via the reporter's local hotfix anyway. Slight cold-start cost on Windows for built-JS plugins, in exchange for not crashing.

Out of scope

Reporter notes the prior targeted patch in runtime-web-channel-plugin-DJqeP2uH.js did not fix it on its own; the decisive fix is the shared resolver. This PR fixes the shared resolver, which is the upstream of both call sites.

A follow-up could push the fix down into jiti itself (normalize paths via pathToFileURL before passing to native import()). That belongs in unjs/jiti, not here.

Closes #71749. Related: #61911, #49716.

Changed files

  • src/plugins/sdk-alias.test.ts (modified, +13/-5)
  • src/plugins/sdk-alias.ts (modified, +15/-1)

Code Example

Before local patch:

OpenClaw 2026.4.24 (cbcfdf6)
Node: v24.14.1
npm: 11.11.0
Install path:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw

Gateway startup:

[gateway] loading configuration…
[gateway] resolving authentication…
[gateway] starting...
[gateway] starting HTTP server...
[canvas] host mounted at http://0.0.0.0:18789/__openclaw__/canvas/
[gateway] agent model: openrouter/deepseek/deepseek-v4-pro
[gateway] ready (4 plugins: active-memory, browser, device-pair, telegram)
[gateway] starting channels and sidecars...
[telegram] [default] starting provider (@redacted)
[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:'
[telegram] [default] auto-restart attempt 1/10 in 5s

Status before patch:

Gateway reachable.
- Telegram default: enabled, configured, stopped, mode:polling, bot:@redacted, token:config, works, 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:'

Isolation test:
- lossless-claw disabled
- plugins.load.paths emptied
- contextEngine set to legacy
- gateway started with only 4 plugins: active-memory, browser, device-pair, telegram
- same Telegram provider crash occurred

Environment override attempted and did not fix it:
JITI_TRY_NATIVE=0
JITI_REBUILD_FS_CACHE=1
OPENCLAW_DIAGNOSTICS=telegram.*,gateway.*,channels.*

Local hotfix that made Telegram work:

1. Patched:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\runtime-web-channel-plugin-DJqeP2uH.js

Changed:
const tryNative = shouldPreferNativeJiti(modulePath);

To:
const tryNative = process.platform !== "win32" && shouldPreferNativeJiti(modulePath);

This alone did not fix the crash.

2. Patched:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\sdk-alias-K6JYDrXB.js

Changed:
function resolvePluginLoaderJitiTryNative(modulePath, options) {

To:
function resolvePluginLoaderJitiTryNative(modulePath, options) { if (process.platform === "win32") return false;

This fixed Telegram provider startup.

After patch:

[telegram] [default] starting provider (@redacted)

Status after patch:

Gateway reachable.
- Telegram default: enabled, configured, running, connected, mode:polling, bot:@redacted, token:config, works

Telegram messages are now processed successfully:

[diagnostic] message processed: channel=telegram chatId=telegram:REDACTED messageId=REDACTED sessionId=unknown sessionKey=agent:main:main outcome=completed
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On native Windows, OpenClaw 2026.4.24 starts successfully, but the Telegram provider crash-loops on startup with:

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 happens even after a clean reinstall and after isolating external plugins. The gateway itself is reachable, but Telegram stays stopped until a local hotfix disables native Jiti loading on Windows in the shared plugin loader path.

This appears related to the previously fixed Windows ESM path issue, but the fix seems incomplete for Telegram/channel provider loading in 2026.4.24.

Steps to reproduce

  1. Install OpenClaw 2026.4.24 globally on native Windows using npm.
  2. Configure Telegram channel in polling mode.
  3. Start the gateway.
  4. Observe that the gateway starts and reports Telegram as configured.
  5. Wait for Telegram provider startup.
  6. Telegram provider exits immediately with ERR_UNSUPPORTED_ESM_URL_SCHEME / Received protocol 'c:'.
  7. Run openclaw channels status --probe.

Observed status before local patch:

Gateway reachable.

  • Telegram default: enabled, configured, stopped, mode:polling, bot:@redacted, token:config, works, 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:'

I also reproduced this with external plugins disabled:

  • lossless-claw disabled
  • plugins.load.paths emptied
  • contextEngine set to legacy

Gateway then started with only:

  • active-memory
  • browser
  • device-pair
  • telegram

Telegram still failed with the same Received protocol 'c:' error.

Expected behavior

Telegram provider should start normally on native Windows and remain running/connected in polling mode.

Actual behavior

The gateway starts, but Telegram provider crash-loops:

[telegram] [default] starting provider (@redacted) [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:' [telegram] [default] auto-restart attempt 1/10 in 5s

After applying a local patch to disable native Jiti on Windows in the shared plugin loader helper, Telegram starts and works:

Gateway reachable.

  • Telegram default: enabled, configured, running, connected, mode:polling, bot:@redacted, token:config, works

OpenClaw version

OpenClaw 2026.4.24 (cbcfdf6)

Operating system

Windows 11

Install method

npm global install

Model

openrouter/deepseek/deepseek-v4-pro Also observed during fallback/cron runs with: openrouter/moonshotai/kimi-k2.6 openrouter/xiaomi/mimo-v2-flash The failure occurs before Telegram can reliably dispatch to the model, so this does not appear model-specific. Node: v24.14.1 npm: 11.11.0

Provider / routing chain

OpenRouter

Additional provider/model setup details

The model/provider does not appear to be the cause. The failure occurs when the Telegram channel provider starts. The gateway itself loads and is reachable.

Logs, screenshots, and evidence

Before local patch:

OpenClaw 2026.4.24 (cbcfdf6)
Node: v24.14.1
npm: 11.11.0
Install path:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw

Gateway startup:

[gateway] loading configuration…
[gateway] resolving authentication…
[gateway] starting...
[gateway] starting HTTP server...
[canvas] host mounted at http://0.0.0.0:18789/__openclaw__/canvas/
[gateway] agent model: openrouter/deepseek/deepseek-v4-pro
[gateway] ready (4 plugins: active-memory, browser, device-pair, telegram)
[gateway] starting channels and sidecars...
[telegram] [default] starting provider (@redacted)
[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:'
[telegram] [default] auto-restart attempt 1/10 in 5s

Status before patch:

Gateway reachable.
- Telegram default: enabled, configured, stopped, mode:polling, bot:@redacted, token:config, works, 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:'

Isolation test:
- lossless-claw disabled
- plugins.load.paths emptied
- contextEngine set to legacy
- gateway started with only 4 plugins: active-memory, browser, device-pair, telegram
- same Telegram provider crash occurred

Environment override attempted and did not fix it:
JITI_TRY_NATIVE=0
JITI_REBUILD_FS_CACHE=1
OPENCLAW_DIAGNOSTICS=telegram.*,gateway.*,channels.*

Local hotfix that made Telegram work:

1. Patched:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\runtime-web-channel-plugin-DJqeP2uH.js

Changed:
const tryNative = shouldPreferNativeJiti(modulePath);

To:
const tryNative = process.platform !== "win32" && shouldPreferNativeJiti(modulePath);

This alone did not fix the crash.

2. Patched:
C:\Users\REDACTED\AppData\Roaming\npm\node_modules\openclaw\dist\sdk-alias-K6JYDrXB.js

Changed:
function resolvePluginLoaderJitiTryNative(modulePath, options) {

To:
function resolvePluginLoaderJitiTryNative(modulePath, options) { if (process.platform === "win32") return false;

This fixed Telegram provider startup.

After patch:

[telegram] [default] starting provider (@redacted)

Status after patch:

Gateway reachable.
- Telegram default: enabled, configured, running, connected, mode:polling, bot:@redacted, token:config, works

Telegram messages are now processed successfully:

[diagnostic] message processed: channel=telegram chatId=telegram:REDACTED messageId=REDACTED sessionId=unknown sessionKey=agent:main:main outcome=completed

Impact and severity

High impact for native Windows users using Telegram.

The gateway starts, but Telegram cannot run at all. Users see no responses in Telegram because the provider crash-loops during startup.

Workaround exists by locally patching the installed package to disable native Jiti loading on Windows in resolvePluginLoaderJitiTryNative(), but this will be overwritten by npm reinstall/update.

Additional information

This appears related to the prior Windows ERR_UNSUPPORTED_ESM_URL_SCHEME / Received protocol 'c:' issue, but it still reproduces in OpenClaw 2026.4.24 for Telegram provider startup.

The working local patch suggests the remaining problem is in the shared plugin/channel loader path allowing native Jiti/ESM loading on Windows. Disabling native Jiti for Windows inside resolvePluginLoaderJitiTryNative() fixed the issue.

A previous targeted patch in runtime-web-channel-plugin-DJqeP2uH.js did not fix it by itself. The decisive fix was the shared helper patch in sdk-alias-K6JYDrXB.js.

Possibly related:

  • Prior closed Windows ERR_UNSUPPORTED_ESM_URL_SCHEME issue: #61911
  • Similar channel-provider startup failure reported for Feishu: #49716

extent analysis

TL;DR

Disable native Jiti loading on Windows in the shared plugin loader path to fix the Telegram provider crash-loop on startup.

Guidance

  • The issue is likely caused by the resolvePluginLoaderJitiTryNative function not handling Windows paths correctly, leading to an ERR_UNSUPPORTED_ESM_URL_SCHEME error.
  • To verify, check the gateway logs for the Received protocol 'c:' error message, which indicates the issue.
  • To mitigate, apply a local patch to disable native Jiti loading on Windows in the resolvePluginLoaderJitiTryNative function, as described in the issue body.
  • Consider testing with other plugins and channels to ensure the fix does not introduce new issues.

Example

function resolvePluginLoaderJitiTryNative(modulePath, options) {
  if (process.platform === "win32") return false;
  // ... rest of the function remains the same
}

Notes

The provided local patch fixes the issue, but it will be overwritten by npm reinstall/update. A more permanent solution would require updating the OpenClaw codebase to handle Windows paths correctly.

Recommendation

Apply the workaround by patching the resolvePluginLoaderJitiTryNative function to disable native Jiti loading on Windows, as this is the only known fix at this time.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Telegram provider should start normally on native Windows and remain running/connected in polling mode.

#model compatibility#GPU setup#container setup#orchestration issue#cache issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Windows Telegram provider still crashes with ERR_UNSUPPORTED_ESM_URL_SCHEME in 2026.4.24 unless native Jiti is disabled [1 pull requests, 3 comments, 4 participants]