Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix WS handshake blocked during channel startup — WebUI inaccessible after gateway restart [2 comments, 3 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#73250•Fetched 2026-04-29 06:21:49
View on GitHub
Comments
2
Participants
3
Timeline
4
Reactions
0
Author
ChrisCarlCaoChrisCarlCao
Participants
ChrisCarlCaoChrisCarlCaosktbrdsktbrdsteipetesteipete
Timeline (top)
commented ×2closed ×1cross-referenced ×1

After upgrading to OpenClaw 2026.4.26, openclaw gateway restart leaves the WebUI (Control UI) inaccessible for approximately 60 seconds. The HTTP server starts in ~8s, but WebSocket connections are blocked until all channels (especially Feishu bots) finish their probe sequences. Browsers that attempt to connect during this window see handshake timeout errors.

Error Message

Error log during the blocking window:

Root Cause

Impact

  • WebUI appears broken after openclaw gateway restart for ~60 seconds
  • openclaw gateway run (foreground) works because users naturally wait for startup
  • The issue is more severe with multiple Feishu bot accounts (each adds ~30s probe timeout)

Fix Action

Workaround

Wait ~60 seconds after openclaw gateway restart before refreshing the browser.

Code Example

11:55:26 starting
11:55:34 HTTP server ready (7.8s) — page loads but WS fails
11:55:34 starting channels and sidecars...
11:55:51 primary: bot open_id resolved (17s)
11:55:51 ⚠️ WS handshake timeout — browser connection dropped
11:55:56 gateway ready (30s total)
11:56:20 robot_elon_musk + robot_larkcli: bot open_id resolved (46s)
11:56:25 WS client ready (59s total) — browser can now connect

---

[ws] handshake timeout conn=... peer=127.0.0.1:...
[ws] closed before connect conn=... code=1000 reason=n/a
RAW_BUFFERClick to expand / collapse

Bug: WS handshake blocked during channel startup

Summary

After upgrading to OpenClaw 2026.4.26, openclaw gateway restart leaves the WebUI (Control UI) inaccessible for approximately 60 seconds. The HTTP server starts in ~8s, but WebSocket connections are blocked until all channels (especially Feishu bots) finish their probe sequences. Browsers that attempt to connect during this window see handshake timeout errors.

Previous behavior

In earlier versions, WS handshake was independent of channel initialization. The browser could connect to the Control UI immediately after the HTTP server was ready. Channels would come online asynchronously.

Current behavior (2026.4.26)

11:55:26 starting
11:55:34 HTTP server ready (7.8s) — page loads but WS fails
11:55:34 starting channels and sidecars...
11:55:51 primary: bot open_id resolved (17s)
11:55:51 ⚠️ WS handshake timeout — browser connection dropped
11:55:56 gateway ready (30s total)
11:56:20 robot_elon_musk + robot_larkcli: bot open_id resolved (46s)
11:56:25 WS client ready (59s total) — browser can now connect

Error log during the blocking window:

[ws] handshake timeout conn=... peer=127.0.0.1:...
[ws] closed before connect conn=... code=1000 reason=n/a

Impact

  • WebUI appears broken after openclaw gateway restart for ~60 seconds
  • openclaw gateway run (foreground) works because users naturally wait for startup
  • The issue is more severe with multiple Feishu bot accounts (each adds ~30s probe timeout)

Environment

  • OpenClaw: 2026.4.26 (be8c246)
  • macOS (arm64), LaunchAgent service
  • 3 Feishu accounts: primary, robot_elon_musk, robot_larkcli
  • probeTimeout set to 10s (was default 30s) — reduces but doesn't fix the issue

Workaround

Wait ~60 seconds after openclaw gateway restart before refreshing the browser.

Suggested fix

Decouple WS handshake from channel readiness. The HTTP server should accept WS connections immediately and queue channel-related operations, rather than blocking the entire WS lifecycle on channel probes.

extent analysis

TL;DR

Decoupling the WebSocket handshake from channel readiness is likely to fix the issue, allowing the HTTP server to accept WS connections immediately.

Guidance

  • Review the OpenClaw 2026.4.26 code changes to identify what introduced the dependency between WS handshake and channel initialization.
  • Verify that the probeTimeout setting is being applied correctly, as reducing it to 10s should have some impact on the blocking window.
  • Consider implementing a queueing mechanism for channel-related operations, allowing the WS handshake to complete independently.
  • Test the workaround of waiting ~60 seconds after openclaw gateway restart to confirm its effectiveness.

Example

No code snippet is provided, as the issue description does not include specific code references.

Notes

The suggested fix requires changes to the OpenClaw codebase, which may not be feasible for all users. The workaround of waiting ~60 seconds may not be suitable for all environments.

Recommendation

Apply the workaround of waiting ~60 seconds after openclaw gateway restart until a fix is available, as it is a relatively simple and low-risk solution.

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…
#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING