openclaw - 💡(How to fix) Fix [Bug]: Slack channel provider crash-loops on Windows with ERR_UNSUPPORTED_ESM_URL_SCHEME ('Received protocol c:') after wizard-driven setup [1 comments, 2 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

Bug type

Crash (process/app exits or hangs) — Slack channel provider enters auto-restart loop and never connects.

Beta release blocker

No (workaround: disable Slack channel in config)

Summary

After completing the interactive openclaw configure wizard to add a Slack channel (Socket Mode, with bot token + app token + 11-channel allowlist + pairing DM policy + interactive replies enabled), the Slack provider fails to start at gateway boot and at every auto-restart attempt with ERR_UNSUPPORTED_ESM_URL_SCHEME / Received protocol 'c:'.

This is the same bug class documented in #2829, #61810, #61899, and #71925 (Feishu equivalent), but on the Slack provider in version 2026.4.24.

Steps to reproduce

1. Fresh-ish OpenClaw install on Windows 11 (npm install -g openclaw), version 2026.4.24
2. Run openclaw configure
3. Pick "Channels" → "Slack"
4. Provide xoxb bot token and xapp app-level token (both valid, verified working tokens from a Slack app with Socket Mode enabled, 14 OAuth scopes, 12 bot events subscribed, Messages Tab enabled)
5. Configure 11 channels in allowlist mode (entered as "#channel-name" comma-separated; wizard reports "Unresolved (kept as typed)")
6. Enable interactive replies = Yes
7. Set DM policy = Pairing (recommended)
8. Exit wizard via "Continue"
9. Gateway hot-reloads; configure-complete reported successfully
10. Wait for Slack provider to attempt connection

Observed behavior

Gateway logs show repeated:

[slack] [default] starting provider
[slack] [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:'
[slack] [default] auto-restart attempt N/10 in <backoff>s
[health] refresh failed: 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:'

Auto-restart escalates with exponential backoff (5s → 86s → 160s → 300s observed) until presumably the provider gives up at attempt 10.

openclaw gateway status reports overall gateway healthy (probe ok, admin-capable). Slack provider is the only failing component.

openclaw config get channels.slack shows the saved configuration with both tokens redacted (__OPENCLAW_REDACTED__), 11 channels enabled, groupPolicy "allowlist", mode "socket", capabilities.interactiveReplies true, userTokenReadOnly true. The config itself appears well-formed.

Expected behavior

Slack provider connects to Socket Mode, registers with the gateway, and is ready to receive events from the configured channels.

Environment

• OS: Windows 11
• OpenClaw: 2026.4.24 (cbcfdf6)
• Node.js: v22.18.0
• Install location: C:\Users\aiops\AppData\Roaming\npm\node_modules\openclaw
• Config path: C:\Users\aiops\.openclaw\openclaw.json
• Gateway mode: local, loopback, port 18789, token auth
• Slack app: Socket Mode, 14 OAuth scopes, 12 bot events, Messages Tab enabled, freshly installed to workspace prior to OpenClaw configure

Notes / additional context

• This appears to be the same root cause as #2829 (raw Windows path passed to import() instead of file:/// URL), surfacing on the Slack provider this time.
• #61810 reports that non-interactive onboarding works on the same machine. It would be useful to know whether constructing the Slack channel config purely via openclaw config set (bypassing the interactive wizard) avoids the bug, or whether the bug is at provider start regardless of config-write path.
• I have not yet tested whether downgrading or upgrading to a different release channel resolves it.

Workaround applied

openclaw config set channels.slack.enabled false to stop the auto-restart loop. Slack functionality fully disabled until fix available.

Steps to reproduce

1. Fresh-ish OpenClaw install on Windows 11 (npm install -g openclaw), version 2026.4.24
2. Run openclaw configure
3. Pick "Channels" from the section menu, then "Slack (Socket Mode)" from the channel type menu
4. Provide xoxb bot token and xapp app-level token (both valid, verified working tokens from a Slack app with Socket Mode enabled, 14 OAuth scopes, 12 bot events subscribed, Messages Tab enabled in App Home)
5. When prompted "Configure Slack channels access?" answer Yes, then provide 11 channel names in allowlist mode (entered as comma-separated "#channel-name" values)
6. Wizard reports allowlist as "Unresolved (kept as typed)"
7. Enable interactive replies = Yes
8. Configure DM access policies = Yes, choose "Pairing (recommended)"
9. Exit wizard via Continue
10. Gateway hot-reloads; "Configure complete" reported successfully
11. Wait for Slack provider to attempt connection

Expected behavior

Slack provider connects to Slack via Socket Mode, registers with the gateway, and is ready to receive events from the configured channels. Subsequent test DMs to the bot should produce a pairing code per the configured DM policy.

Actual behavior

Slack provider fails to start at gateway boot and at every auto-restart attempt with ERR_UNSUPPORTED_ESM_URL_SCHEME / "Received protocol 'c:'". The provider enters an exponential-backoff auto-restart loop that never succeeds.

Gateway logs show the repeating pattern:

[slack] [default] starting provider [slack] [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:' [slack] [default] auto-restart attempt N/10 in <backoff>s [health] refresh failed: 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:'

Backoff progression observed: 5s → 86s → 160s → 300s. Auto-restart escalates until attempt 10.

openclaw gateway status reports overall gateway healthy (probe ok, admin-capable). The Slack provider is the only failing component. openclaw config get channels.slack shows the saved configuration with both tokens redacted, 11 channels enabled, groupPolicy "allowlist", mode "socket", capabilities.interactiveReplies true, userTokenReadOnly true. The config itself appears well-formed.

This appears to be the same root cause as #2829 (raw Windows path passed to import() instead of file:/// URL), surfacing on the Slack provider this time. Similar Windows-path ESM issues are documented in #61810, #61899, and #71925 (Feishu equivalent).

OpenClaw version

2026.4.24 (cbcfdf6)

Operating system

Windows 11 Node.js: v22.18.0

Install method

npm install -g openclaw Install location: C:\Users\aiops\AppData\Roaming\npm\node_modules\openclaw

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

Anthropic API direct (no gateway/proxy/Bedrock/Vertex). API key authenticated via OpenClaw config (channels.slack-unrelated). Token validated; gateway model resolution successful. The bug is in the Slack channel provider startup, not the model or routing chain.

Additional provider/model setup details

Anthropic API key configured during initial gateway setup. Default model anthropic/claude-sonnet-4-6 confirmed working via prior end-to-end test (openclaw agent --agent main --message "..." returned a valid Sonnet response). The bug surfaces specifically when the Slack channel provider attempts to start, not when the agent or model is invoked.

Logs, screenshots, and evidence

Excerpt from C:\Users\aiops\AppData\Local\Temp\openclaw\openclaw-2026-04-28.log:

22:22:46 [slack] [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:'
22:22:46 [slack] [default] auto-restart attempt 5/10 in 86s
22:23:46 [health] refresh failed: 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:'
22:24:13 [slack] [default] starting provider
22:24:13 [slack] [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:'
22:24:13 [slack] [default] auto-restart attempt 6/10 in 160s
22:24:46 [health] refresh failed: ...
22:25:46 [health] refresh failed: ...
22:26:46 [health] refresh failed: ...
22:26:51 [health] post-connect health refresh failed: ...
22:26:54 [slack] [default] starting provider
22:26:54 [slack] [default] channel exited: ...
22:26:54 [slack] [default] auto-restart attempt 7/10 in 300s

The error message and "Received protocol 'c:'" are identical across all attempts.

Slack channel config (tokens redacted by openclaw config get):
{
  "enabled": true,
  "botToken": "__OPENCLAW_REDACTED__",
  "appToken": "__OPENCLAW_REDACTED__",
  "groupPolicy": "allowlist",
  "channels": { ... 11 channels with "enabled": true ... },
  "capabilities": { "interactiveReplies": true },
  "mode": "socket",
  "webhookPath": "/slack/events",
  "userTokenReadOnly": true
}

Impact and severity

Severity: High for any deployment using Slack as the primary channel. Slack channel completely non-functional on Windows installs after wizard-driven setup; cannot be used for DM, channel messaging, or pairing. No Slack interaction possible.

Impact: Windows users wanting Slack integration are blocked. Workaround is to disable the Slack channel entirely (openclaw config set channels.slack.enabled false) which stops the auto-restart loop but provides no Slack functionality.

For the deployment that surfaced this, the impact is mitigated because Slack-dependent work can be deferred. Other deployments may be more sensitive.

Additional information

Possible root cause hypothesis (not verified): the Slack channel provider's startup code dynamically imports a module using a raw Windows absolute path (e.g., C:\Users...) instead of a properly-converted file:/// URL. This matches the pattern documented in #2829 with the suggested fix:

const slugGenUrl = new URL(file:///${slugGenPath.replace(/\\/g, "/")}).href; const { generateSlugViaLLM } = await import(slugGenUrl);

It would be useful to know whether bypassing the interactive wizard and writing channels.slack config directly via openclaw config set avoids the bug, or whether the bug surfaces at provider-start regardless of how the config was written. Issue #61810 reports non-interactive onboarding works around a similar bug, suggesting the wizard may write some path field that triggers the bug downstream.

Cross-references:

• #2829 (Windows ESM path bug, root cause + suggested fix)
• #61810 (Interactive onboarding fails with same error class)
• #61899 (ERR_UNSUPPORTED_ESM_URL_SCHEME on install)
• #71925 (Feishu provider, same error pattern, recent — 3 days ago)