openclaw - 💡(How to fix) Fix [Bug]: OpenClaw 2026.4.24 — Telegram Channel Startup Failures [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating to 2026.4.24, the Telegram bundled channel fails to load consistently on startup due to cascading ENOTEMPTY errors in the shared node_modules directory (/home/<user>/node_modules/). This causes the gateway to start without an active Telegram polling connection, leaving the bot unresponsive, despite the channel appearing as ON / OK in openclaw status. A secondary issue prevents the WebSocket interface from accepting connections while HTTP works normally, making all CLI commands that rely on the gateway RPC (openclaw logs --follow, openclaw gateway probe, openclaw channels status --probe) fail with timeout errors.

Steps to reproduce

Steps to Reproduce

Install OpenClaw 2026.4.24 on Ubuntu with systemd Configure Telegram channel Start gateway: openclaw gateway start Observe repeated ENOTEMPTY errors in logs for bundled channels Observe openclaw gateway probe timing out despite HTTP being reachable Send a message to the Telegram bot — no response

Expected behavior

Expected Behavior

Bundled channels install their dependencies without conflicting with the shared node_modules directory WebSocket interface becomes available as soon as the gateway is ready Telegram polling starts reliably and remains stable systemd does not restart the gateway during normal channel loading

Actual behavior

Issue 1 — ENOTEMPTY cascade on bundled channel startup Severity: High Reproducible: Yes, consistently on every gateway restart Multiple bundled channels fail to install their runtime dependencies because npm cannot rename packages in the shared node_modules directory. The error affects at least:

abort-controller (feishu, matrix, synology-chat, zalouser) form-data (mattermost, telegram, whatsapp, qqbot) image-q (msteams) another-json (nostr) gaxios (googlechat) accepts (twitch) Workaround found: Manually deleting the conflicting packages while the gateway is loading unblocks the startup: bashrm -rf /home/<user>/node_modules/form-data
/home/<user>/node_modules/abort-controller
/home/<user>/node_modules/image-q
/home/<user>/node_modules/another-json
/home/<user>/node_modules/accepts
/home/<user>/node_modules/gaxios This is not a sustainable solution as the issue recurs on every restart. ssue 2 — WebSocket interface unresponsive while HTTP works Severity: High The gateway HTTP server responds correctly (HTTP 200), but the WebSocket handshake never completes — connections time out after the TCP handshake. Observed behavior: curl http://127.0.0.1:18789/ → HTTP 200 OK ✅ curl --Upgrade websocket ... → timeout after 5s ❌ openclaw gateway probe → Connect: failed - timeout ❌ openclaw logs --follow → Gateway not reachable ❌ openclaw channels status --probe → gateway timeout after 30000ms ❌ Impact: All RPC-based CLI commands fail. Real-time log tailing is impossible. Gateway appears unreachable from the CLI perspective even when serving HTTP traffic normally.

Issue 3 — Telegram polling stall (getUpdates stuck) Severity: Medium Appears after: Telegram channel loads successfully but encounters network delays After initial startup, the Telegram polling runner occasionally stalls with getUpdates hanging for over 216 seconds before being forcibly restarted. This leaves the bot unresponsive for several minutes at a time. Log sample: [telegram] Polling stall detected (active getUpdates stuck for 216.41s); forcing restart. [telegram][diag] polling cycle finished reason=polling stall detected error=Network request for 'getUpdates' failed! Telegram polling runner stopped (polling stall detected); restarting in 2.03s. Note: Direct API connectivity is confirmed working: bashcurl https://api.telegram.org/bot<TOKEN>/getMe → {"ok":true, ...}

Issue 4 — systemd restart loop during slow channel startup Severity: Medium When the gateway takes longer than expected to become healthy (due to issues 1 and 2 above), systemd restarts the service before channel loading completes. This creates a restart loop where:

Gateway starts → installs plugin deps (~45-90s) Gateway becomes ready → starts loading channels Channels stall on ENOTEMPTY → gateway never accepts WebSocket connections systemd health check times out → restarts the service Go to step 1

Each restart cycle reinstalls all plugin dependencies from scratch, adding 1-2 minutes per cycle. In testing, the gateway cycled 5+ times before stabilizing. Suggestion: Consider increasing the systemd startup timeout, or delaying the health check to account for channel loading time.

OpenClaw version

2026.4.24

Operating system

Ubuntu Linux 6.17.0-22-generic x64

Install method

npm global

Model

claude-haiku-4-5

Provider / routing chain

openclaw > gateway> telegram

Additional provider/model setup details

Additional Context

The plugin runtime deps directory is: /home/<user>/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-f6f18df79eee/ npm cache used: /home/<user>/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-f6f18df79eee/.openclaw-npm-cache/ The conflict is between openclaw's bundled channel npm installs and packages already present in the user's global node_modules Deleting /home/<user>/node_modules/ entirely and letting openclaw reinstall is the only full workaround, but the packages reappear after the next system npm operation

Report generated after extensive troubleshooting session on 2026-04-25.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response