openclaw - 💡(How to fix) Fix [Bug]: Embedded runtime hangs after `embedded run start`, agent never produces reply (WhatsApp channel) [2 comments, 3 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Summary

Inbound WhatsApp messages are received and trigger the agent loop, but the embedded runtime hangs after embedded run start and never produces a reply. WhatsApp Web connection eventually drops with status 408 due to inactivity.

Environment

• OpenClaw: 2026.4.26 (be8c246) — also reproduced on 2026.4.25 (aa36ee6)
• OS: Windows 11
• Node: 24.15.0
• Channel: WhatsApp (Baileys 7.0.0-rc.9)
• Provider: OpenRouter
• Model: moonshotai/kimi-k2-0905

Steps to reproduce

1. Fresh npm install -g openclaw@latest
2. Complete onboarding with OpenRouter + WhatsApp personal channel
3. Pair WhatsApp via dashboard QR code (succeeds)
4. Send a WhatsApp message from external number to paired number

Expected

Agent processes message and replies via WhatsApp.

Actual

• Inbound message received and logged correctly
• Agent harness selects (provider=openrouter modelId=moonshotai/kimi-k2-0905)
• [agent/embedded] embedded run start is logged
• Then ~3 minutes of silence
• WA Web connection drops: Web connection closed (status 408). Retry 1/12... Request Time-out Connection was lost
• Session state stuck processing indefinitely; subsequent messages queue behind it

Verified NOT the cause

• Direct OpenRouter call to kimi-k2-0905 returns in ~1.8s (tested via curl/Invoke-WebRequest)
• Network stable: ping 1.1.1.1 0% loss avg 21ms, ping web.whatsapp.com 0% loss avg 39ms
• Sessions cleaned via openclaw sessions cleanup --enforce --fix-missing (entries: 0)
• openclaw doctor --fix run, all warnings resolved
• Reproduced on fresh install with new pairing
• WhatsApp pairing/linking confirmed healthy in dashboard (Linked/Running/Connected = Yes)

Relevant log excerpt

Steps to reproduce

1. Fresh npm install -g openclaw@latest on Windows 11 with Node 24.15.0
2. Complete onboarding: OpenRouter API key, model moonshotai/kimi-k2-0905, WhatsApp personal channel
3. Pair WhatsApp via dashboard "Show QR" → scan from phone (Settings → Linked Devices → Link a Device)
4. Wait for [whatsapp] Listening for personal WhatsApp inbound messages log line
5. Send any WhatsApp message from a different number to the paired number
6. Observe that no reply is ever sent

Expected behavior

After receiving an inbound WhatsApp message, the agent processes it via the configured model (moonshotai/kimi-k2-0905) and replies in the same WhatsApp thread within seconds.

Actual behavior

Inbound message is received and logged correctly. Agent harness selects, then [agent/embedded] embedded run start is logged. After that, the embedded run produces no further output. After ~3 minutes, WhatsApp Web drops with Web connection closed (status 408). Retry 1/12... Request Time-out Connection was lost. Session enters and remains in state=processing (observed via [diagnostic] stuck session: ... state=processing age=873s queueDepth=1). No reply is ever delivered. Subsequent messages queue behind the stuck session. The same pattern reproduces on every inbound message, across fresh installs and clean session state.

OpenClaw version

2026.4.26 (be8c246) — also reproduced on 2026.4.25 (aa36ee6)

Operating system

Windows 11

Install method

npm global

Model

moonshotai/kimi-k2-0905

Provider / routing chain

openclaw -> openrouter -> moonshotai/kimi-k2-0905

Additional provider/model setup details

• Node 24.15.0
• WhatsApp channel via bundled Baileys 7.0.0-rc.9
• Personal phone setup, allowlist DM policy
• Direct OpenRouter call to same model returns in ~1.8s (verified via Invoke-WebRequest)
• Bonjour mDNS disabled via OPENCLAW_DISABLE_BONJOUR=1 (no effect on this issue)

Logs, screenshots, and evidence

[agents/harness] agent harness selected (provider=openrouter modelId=moonshotai/kimi-k2-0905 selectedHarnessId=pi)
[agent/embedded] embedded run start: runId=8e729dbf-1caa-4ea8-93b1-4a68d1082436 sessionId=5454a0e0-91e9-49f2-a84f-607b6d000fc9 provider=openrouter model=moonshotai/kimi-k2-0905 thinking=off messageChannel=whatsapp
[plugins] [hooks] running before_agent_reply (1 handlers, first-claim wins)
[whatsapp] Web connection closed (status 408). Retry 1/12 in 2.45s... (status=408 Request Time-out Connection was lost)
[diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:whatsapp:direct:+61413954311 state=processing age=230s queueDepth=1
[codex/catalog] codex model discovery failed; using fallback catalog

Direct OpenRouter call to kimi-k2-0905 (verified outside OpenClaw): ~1.79s response time.
Network: ping 1.1.1.1 0% loss avg 21ms, ping web.whatsapp.com 0% loss avg 39ms.

Impact and severity

Affected: WhatsApp channel users on 2026.4.26 (also 2026.4.25) Severity: High — agent never replies to any inbound WhatsApp message, blocking the entire channel Frequency: Always (every inbound message reproduces, across fresh installs and clean session state) Consequence: Missed messages, inbound queue grows indefinitely, WhatsApp Web session drops with 408 timeout, eventually dashboard shows the channel as unhealthy

Additional information

• Reproduced on 2026.4.25 (aa36ee6) and 2026.4.26 (be8c246). No prior known-good version since this is initial setup.
• Web dashboard chat at localhost:18789 works correctly (the embedded runtime appears to fail specifically on the WhatsApp channel pipeline, or on non-dashboard message dispatch).
• Direct OpenRouter API call to moonshotai/kimi-k2-0905 from the same machine returns in ~1.79s.
• Network: ping 1.1.1.1 0% loss avg 21ms, ping web.whatsapp.com 0% loss avg 39ms.
• openclaw doctor --fix and openclaw sessions cleanup --enforce --fix-missing both run cleanly. Sessions are empty before reproduction.
• Bonjour mDNS repeatedly fails to advertise, eventually disabling itself; setting OPENCLAW_DISABLE_BONJOUR=1 does not change this issue.
• [codex/catalog] codex model discovery failed; using fallback catalog warning is present in all logs but presumably unrelated.