Skip to content

[Bug]: Windows gateway listens but local health/status time out after Telegram polling stall (v2026.5.20) #86031

Open
#108874
Open
[Bug]: Windows gateway listens but local health/status time out after Telegram polling stall (v2026.5.20)#86031
#108874
Labels
P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.staleMarked as stale due to inactivity

Description

@rkotchamp
rkotchamp
opened on May 24, 2026

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions