Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating from 2026.4.22 to 2026.4.26, doctor --fix successfully installs bundled plugin deps in 9s but the gateway startup degrades from ~1 minute to ~14.5 minutes, Telegram polling stalls for 138+ seconds, and cron.status takes 118 seconds. Rolling back to 2026.4.22 immediately restores full functionality.

Steps to reproduce

1. Start from working OpenClaw 2026.4.22 on Windows 11 (global npm, Telegram channel configured and functional)
2. openclaw gateway stop
3. npm i -g openclaw@latest (installs 2026.4.26, commit be8c246)
4. openclaw doctor --fix → installs 12 bundled plugin deps in 9s into ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-<hash>/node_modules/
5. openclaw gateway start
6. Observe startup timeline and Telegram behavior

Expected behavior

• Gateway starts in ~1 minute (same as 2026.4.22)
• Telegram channel connects and responds normally within ~1 minute
• Webchat UI responds within seconds
• No polling stalls or stuck sessions
• cron.status responds in under 1 second

Actual behavior

• Gateway takes ~14.5 minutes to become usable
• Telegram polling stalls for 138+ seconds, then fails with network errors
• Stuck sessions with age=200+ seconds
• cron.status takes 118,859ms (nearly 2 minutes)
• Webchat unresponsive for 6+ minutes
• Bundled deps installed to ~/.openclaw/plugin-runtime-deps/ instead of package node_modules
• Multiple versioned runtime-deps roots accumulating on disk

OpenClaw version

2026.4.26 (be8c246) — regression from 2026.4.22 (00bd2cf)

Operating system

Windows 11

Install method

npm global (npm i -g openclaw@latest)

Model

moonshot/kimi-k2.6

Provider / routing chain

openclaw gateway -> moonshot API (direct)

Additional provider/model setup details

Node.js v25.9.0, Telegram channel configured with working bot token (functional on 2026.4.22)

Logs, screenshots, and evidence

**Startup timeline:**

| Time | Event |
|------|-------|
| `09:49:44` | Gateway starts |
| `09:49:58` | HTTP server listening (12s — fine) |
| `09:52:17` | Browser/server ready (**2m 19s** after HTTP ready) |
| `09:52:57` | OpenRouter + LiteLLM pricing fetch timeout (60s each) |
| `09:53:02` | Telegram provider starts, gateway ready |
| `09:53:33` | `chat.history` and `models.list` respond (29s response time) |
| `09:58:01` | `cron.status` responds after **118,859ms** (nearly 2 minutes) |
| `09:58:00` | Stuck session: `agent:main:main state=processing age=208s` |
| `10:01:50` | Telegram polling stall: `getUpdates stuck for 138.5s`, forced restart |
| `10:04:20` | **First `sendMessage ok`** — Telegram finally responds |

**Total time from gateway start to first Telegram response: ~14 minutes 36 seconds.**

On `2026.4.22` the same setup responds in **under 1 minute**.

**Key log excerpts:**

[telegram] Polling stall detected (active getUpdates stuck for 138.5s); forcing restart.
[telegram] polling cycle finished ... outcome=error ... error=Network request for 'getUpdates' failed!
[telegram] polling runner stopped (polling stall detected); restarting in 2.37s.
[ws] ⇄ res ✓ cron.status 118859ms
[diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=208s queueDepth=1
[agent/embedded] session file repaired: dropped 1 blank user message(s)
[telegram] sendMessage ok chat=8681671742 message=5568

Impact and severity

• Affected: any Windows user who updates via global npm
• Severity: complete loss of Telegram channel for 14+ minutes; gateway effectively unusable during startup; stuck sessions prevent normal operation
• Frequency: reproduced on 2026.4.24, 2026.4.25, and 2026.4.26
• Consequence: forced rollback to 2026.4.22; 2026.4.26 is unusable on this setup despite the bundled deps fix

Additional information

Last known good version: 2026.4.22 (00bd2cf) — 1 min startup, Telegram fully functional, webchat responds in seconds.

First known bad version: 2026.4.24 (bundled deps missing + performance regression), still broken in 2026.4.25 and 2026.4.26.

Additional finding — deps install location:

doctor --fix installs bundled plugin deps into:

C:\Users\<user>\.openclaw\plugin-runtime-deps\openclaw-2026.4.26-<hash>\node_modules\

...rather than the package's own node_modules. This is a new install path not present in 2026.4.22, and it's unclear whether this path is correctly resolved at runtime under all conditions (global npm install on Windows).

Multiple versioned runtime-deps roots are accumulating on disk:

• openclaw-2026.4.24-...
• openclaw-2026.4.25-...
• openclaw-2026.4.26-...
• openclaw-unknown-... (artifact from manual workaround attempt)

This is a follow-up to #72967 which was closed as "fixed in 2026.4.26". The bundled deps repair works, but the runtime performance regression persists.