Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: openclaw gateway restart takes extremely long on Windows [2 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#74272•Fetched 2026-04-30 06:26:14
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
2
Author
zym951223zym951223
Participants
clawsweeper[bot]clawsweeper[bot]zym951223zym951223
Timeline (top)
commented ×2cross-referenced ×2labeled ×2closed ×1

Description The openclaw gateway restart command takes an extremely long time to complete on Windows. The gateway process itself starts successfully (plugins load, channels connect), but the restart command keeps hanging and does not return.

Gateway logs The gateway logs show repeated WebSocket health-check connection failures: 18:04:10 [ws] closed before connect conn=5275a172-e973-47ac-b31e-29da361f9e0c peer=127.0.0.1:64039->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:11 [ws] closed before connect conn=8a51638b-90d2-4e6d-bb8d-dba8cd7d6d45 peer=127.0.0.1:64041->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:13 [ws] closed before connect conn=c33a32a6-a52c-47fb-b856-276672fb6411 peer=127.0.0.1:64043->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed

Port status (netstat -ano | findstr 18789) Port 18789 is correctly in LISTENING state (PID 40616), but there are 100+ connections stuck in TIME_WAIT, suggesting the health-check probe repeatedly connects and gets immediately rejected: TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 40616 TCP 127.0.0.1:18789 127.0.0.1:62272 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62303 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62377 TIME_WAIT 0 ... (100+ TIME_WAIT entries) TCP [::1]:18789 [::]:0 LISTENING 40616

Analysis The gateway WebSocket server on port 18789 is listening and the gateway is fully functional (plugins loaded, channels connected). However, the restart command's health-check WebSocket connections are being closed with code=1008 (Policy Violation), causing the health check to never pass. This results in the restart command hanging indefinitely until the health-check timeout is reached. The issue does not occur on macOS — gateway restart completes within seconds.

Environment OS: Windows 10/11 OpenClaw: 4.25 (2026.4.26, build be8c246)

Root Cause

Description The openclaw gateway restart command takes an extremely long time to complete on Windows. The gateway process itself starts successfully (plugins load, channels connect), but the restart command keeps hanging and does not return.

Gateway logs The gateway logs show repeated WebSocket health-check connection failures: 18:04:10 [ws] closed before connect conn=5275a172-e973-47ac-b31e-29da361f9e0c peer=127.0.0.1:64039->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:11 [ws] closed before connect conn=8a51638b-90d2-4e6d-bb8d-dba8cd7d6d45 peer=127.0.0.1:64041->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:13 [ws] closed before connect conn=c33a32a6-a52c-47fb-b856-276672fb6411 peer=127.0.0.1:64043->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed

Port status (netstat -ano | findstr 18789) Port 18789 is correctly in LISTENING state (PID 40616), but there are 100+ connections stuck in TIME_WAIT, suggesting the health-check probe repeatedly connects and gets immediately rejected: TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 40616 TCP 127.0.0.1:18789 127.0.0.1:62272 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62303 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62377 TIME_WAIT 0 ... (100+ TIME_WAIT entries) TCP [::1]:18789 [::]:0 LISTENING 40616

Analysis The gateway WebSocket server on port 18789 is listening and the gateway is fully functional (plugins loaded, channels connected). However, the restart command's health-check WebSocket connections are being closed with code=1008 (Policy Violation), causing the health check to never pass. This results in the restart command hanging indefinitely until the health-check timeout is reached. The issue does not occur on macOS — gateway restart completes within seconds.

Environment OS: Windows 10/11 OpenClaw: 4.25 (2026.4.26, build be8c246)

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Description The openclaw gateway restart command takes an extremely long time to complete on Windows. The gateway process itself starts successfully (plugins load, channels connect), but the restart command keeps hanging and does not return.

Gateway logs The gateway logs show repeated WebSocket health-check connection failures: 18:04:10 [ws] closed before connect conn=5275a172-e973-47ac-b31e-29da361f9e0c peer=127.0.0.1:64039->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:11 [ws] closed before connect conn=8a51638b-90d2-4e6d-bb8d-dba8cd7d6d45 peer=127.0.0.1:64041->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed 18:04:13 [ws] closed before connect conn=c33a32a6-a52c-47fb-b856-276672fb6411 peer=127.0.0.1:64043->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed

Port status (netstat -ano | findstr 18789) Port 18789 is correctly in LISTENING state (PID 40616), but there are 100+ connections stuck in TIME_WAIT, suggesting the health-check probe repeatedly connects and gets immediately rejected: TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 40616 TCP 127.0.0.1:18789 127.0.0.1:62272 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62303 TIME_WAIT 0 TCP 127.0.0.1:18789 127.0.0.1:62377 TIME_WAIT 0 ... (100+ TIME_WAIT entries) TCP [::1]:18789 [::]:0 LISTENING 40616

Analysis The gateway WebSocket server on port 18789 is listening and the gateway is fully functional (plugins loaded, channels connected). However, the restart command's health-check WebSocket connections are being closed with code=1008 (Policy Violation), causing the health check to never pass. This results in the restart command hanging indefinitely until the health-check timeout is reached. The issue does not occur on macOS — gateway restart completes within seconds.

Environment OS: Windows 10/11 OpenClaw: 4.25 (2026.4.26, build be8c246)

Steps to reproduce

1 update to 2026.4.26 2 openclaw gateway restart

Expected behavior

The issue does not occur on macOS — gateway restart completes within seconds.

Actual behavior

openclaw gateway restart takes extremely long on Windows

OpenClaw version

2026.4.26

Operating system

win11

Install method

No response

Model

glm

Provider / routing chain

openclaw gateway restart

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The openclaw gateway restart command hangs due to repeated WebSocket health-check connection failures on Windows, likely caused by a policy violation.

Guidance

  • Investigate the WebSocket health-check policy configuration to identify the cause of the policy violation (code=1008).
  • Verify that the gateway WebSocket server on port 18789 is correctly configured and listening.
  • Check the Windows firewall or security settings to ensure they are not blocking the WebSocket connections.
  • Consider increasing the health-check timeout to mitigate the issue, but this may not resolve the underlying cause.

Example

No code snippet is provided as the issue is related to configuration and policy settings.

Notes

The issue is specific to Windows 10/11 and does not occur on macOS, suggesting a platform-specific configuration or compatibility issue.

Recommendation

Apply a workaround by increasing the health-check timeout or investigating the WebSocket health-check policy configuration to resolve the policy violation, as the root cause is likely related to the policy settings.

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…

FAQ

Expected behavior

The issue does not occur on macOS — gateway restart completes within seconds.

#SSR setup#ISR setup#authentication setup#request error#file not found

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING