openclaw - 💡(How to fix) Fix [Bug]: Windows gateway listens but local health/status time out after Telegram polling stall (v2026.5.20) [1 pull requests]

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…

Error Message

telegram setMyCommands(all_group_chats) failed: Network request for 'setMyCommands' failed! Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed! fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout) telegram deleteMyCommands(all_group_chats) failed: Network request for 'deleteMyCommands' failed! telegram sendChatAction failed: Network request for 'sendChatAction' failed!

Fix Action

Fixed

Code Example

%APPDATA%\npm\openclaw.cmd gateway install --force --port 18789

---

%APPDATA%\npm\openclaw.cmd gateway restart

---

%APPDATA%\npm\openclaw.cmd gateway status

---

Invoke-WebRequest -UseBasicParsing http://127.0.0.1:18789/health -TimeoutSec 8

---

Runtime: running (pid 2772, Startup-folder login item installed; listener detected on port 18789.)
Listening: 127.0.0.1:18789
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
  timeout
Port 18789 is already in use.
- pid 2772: "C:\Program Files\nodejs\node.exe" ... openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)

---

HEALTH_ERR The operation has timed out.

---

LocalAddress  : 127.0.0.1
LocalPort     : 18789
State         : Listen
OwningProcess : 2772

---

http server listening (10 plugins: browser, canvas, codex, device-pair, duckduckgo, file-transfer, memory-core, phone-control, talk-voice, telegram; 14.8s)
gateway ready
heartbeat: started
[default] starting provider (@...bot)

---

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=157s eventLoopDelayP99Ms=136902.1 eventLoopDelayMaxMs=136902.1 eventLoopUtilization=0.999 cpuCoreRatio=1.019 active=1 waiting=0 queued=0 ... work=[active=agent:main:telegram:direct:<redacted>(processing,q=1,age=140s)]
stuck session: sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> state=processing age=140s queueDepth=1 reason=queued_work_without_active_run classification=stale_session_state recovery=checking
stuck session recovery: sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> age=140s action=release_lane aborted=false drained=true released=0
stuck session recovery outcome: status=released action=release_lane sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> lane=session:agent:main:telegram:direct:<redacted> released=0
[telegram] Polling stall detected (active getUpdates stuck for 139.83s); forcing restart. [diag inFlight=1 outcome=started startedAt=<redacted> finishedAt=n/a durationMs=n/a offset=<redacted>]
[telegram][diag] isolated polling ingress finished reason=polling stall detected inFlight=1 outcome=started startedAt=<redacted> finishedAt=<redacted> durationMs=30176 offset=<redacted>
[telegram][diag] closing stale transport before rebuild
[telegram][diag] rebuilding transport for next polling cycle
closed before connect conn=<redacted> peer=127.0.0.1:<port>->127.0.0.1:18789 remote=127.0.0.1 host=127.0.0.1:18789 code=1006 reason=n/a

---

telegram setMyCommands(all_group_chats) failed: Network request for 'setMyCommands' failed!
Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed!
fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout)
telegram deleteMyCommands(all_group_chats) failed: Network request for 'deleteMyCommands' failed!
telegram sendChatAction failed: Network request for 'sendChatAction' failed!

---

Delivery suppressed by sourceReplyDeliveryMode: message_tool_only for session agent:main:telegram:direct:<redacted> — agent will still process the message

---

{
  "messages": {
    "visibleReplies": "automatic"
  }
}
RAW_BUFFERClick to expand / collapse

Bug Description

On Windows, OpenClaw Gateway starts and binds to 127.0.0.1:18789, but then blocks hard enough that local health/status probes time out. Telegram long polling also stalls and repeatedly forces transport rebuilds. The gateway process remains present/listening, so operator-facing status looks like "running", but it is not actually responsive.

This was observed while debugging a user report that "OpenClaw does not stay on for long" and Telegram "can barely pick up" messages. Hermes on the same machine remains up.

Environment

  • OpenClaw: 2026.5.20 from npm package openclaw
  • Runtime: Node 24.15.0
  • OS: Windows host (win32 in logs), machine also accessed from WSL for diagnostics
  • Gateway command: C:\Program Files\nodejs\node.exe C:\Users\Omaano\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
  • Gateway bind: loopback 127.0.0.1:18789
  • Channel involved: Telegram bot account, direct chat

Steps / Commands Tried

  1. Installed/reinstalled gateway service:
    %APPDATA%\npm\openclaw.cmd gateway install --force --port 18789
  2. Restarted gateway:
    %APPDATA%\npm\openclaw.cmd gateway restart
  3. Checked gateway status:
    %APPDATA%\npm\openclaw.cmd gateway status
  4. Checked HTTP health:
    Invoke-WebRequest -UseBasicParsing http://127.0.0.1:18789/health -TimeoutSec 8

Expected Behavior

  • gateway status should complete and report the gateway as reachable once the process is listening.
  • http://127.0.0.1:18789/health should return quickly.
  • Telegram polling should not block the gateway/event loop for >2 minutes; if Telegram networking is degraded, it should fail/retry without starving local status/health probes or session lanes.

Actual Behavior

The gateway process is listening, but probes time out:

Runtime: running (pid 2772, Startup-folder login item installed; listener detected on port 18789.)
Listening: 127.0.0.1:18789
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
  timeout
Port 18789 is already in use.
- pid 2772: "C:\Program Files\nodejs\node.exe" ... openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)

Health probe also times out:

HEALTH_ERR The operation has timed out.

TCP state still shows the process listening:

LocalAddress  : 127.0.0.1
LocalPort     : 18789
State         : Listen
OwningProcess : 2772

Relevant Log Excerpts

Startup succeeds:

http server listening (10 plugins: browser, canvas, codex, device-pair, duckduckgo, file-transfer, memory-core, phone-control, talk-voice, telegram; 14.8s)
gateway ready
heartbeat: started
[default] starting provider (@...bot)

Then the event loop appears starved while a Telegram direct session is processing:

liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=157s eventLoopDelayP99Ms=136902.1 eventLoopDelayMaxMs=136902.1 eventLoopUtilization=0.999 cpuCoreRatio=1.019 active=1 waiting=0 queued=0 ... work=[active=agent:main:telegram:direct:<redacted>(processing,q=1,age=140s)]
stuck session: sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> state=processing age=140s queueDepth=1 reason=queued_work_without_active_run classification=stale_session_state recovery=checking
stuck session recovery: sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> age=140s action=release_lane aborted=false drained=true released=0
stuck session recovery outcome: status=released action=release_lane sessionId=unknown sessionKey=agent:main:telegram:direct:<redacted> lane=session:agent:main:telegram:direct:<redacted> released=0
[telegram] Polling stall detected (active getUpdates stuck for 139.83s); forcing restart. [diag inFlight=1 outcome=started startedAt=<redacted> finishedAt=n/a durationMs=n/a offset=<redacted>]
[telegram][diag] isolated polling ingress finished reason=polling stall detected inFlight=1 outcome=started startedAt=<redacted> finishedAt=<redacted> durationMs=30176 offset=<redacted>
[telegram][diag] closing stale transport before rebuild
[telegram][diag] rebuilding transport for next polling cycle
closed before connect conn=<redacted> peer=127.0.0.1:<port>->127.0.0.1:18789 remote=127.0.0.1 host=127.0.0.1:18789 code=1006 reason=n/a

Earlier in the same run, Telegram/network operations timed out:

telegram setMyCommands(all_group_chats) failed: Network request for 'setMyCommands' failed!
Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed!
fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=request-timeout)
telegram deleteMyCommands(all_group_chats) failed: Network request for 'deleteMyCommands' failed!
telegram sendChatAction failed: Network request for 'sendChatAction' failed!

There was also a local config issue causing silent replies in direct Telegram DMs:

Delivery suppressed by sourceReplyDeliveryMode: message_tool_only for session agent:main:telegram:direct:<redacted> — agent will still process the message

I locally worked around that by setting:

{
  "messages": {
    "visibleReplies": "automatic"
  }
}

That explains missing visible replies, but it does not explain why a listening gateway times out on local health/status or why Telegram polling stalls coincide with event-loop starvation.

Notes

  • Sensitive config values, tokens, chat IDs, offsets, and connection IDs are redacted above.
  • This may be related to existing status-hang/event-loop-starvation reports, but this repro is on 2026.5.20 with Telegram polling stalls and a listener that remains bound while local probes time out.

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…

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 - 💡(How to fix) Fix [Bug]: Windows gateway listens but local health/status time out after Telegram polling stall (v2026.5.20) [1 pull requests]