Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug] Hub 2026.9.8-1: premature WebSocket closures and lost system.run.prepare result with WSL Gateway

Open
  • Is something wrong?
#1,689 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, docker, linux
Domain
backend, distributed-systems, networking

Research direction

Start in src/OpenClaw.Shared/WebSocketClientBase.cs, the receive loop around line 472 and the premature-close warning near line 555, then the SendRawAsync helper near line 744. Related paths are WindowsNodeClient.cs around lines 630 and 644 and the slow-capability test in tests/OpenClaw.Shared.Tests/WindowsNodeClientTests.cs. Done would mean a role- and connection-generation-labelled diagnostic that separates missed PONG processing from transport loss, which needs wire-level reproduction first.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-maintainer-review clawsweeper:no-new-fix-pr impact:other issue-rating: 🦪 silver shellfish P1

Summary

Windows Hub intermittently loses its Gateway connections, including while the agent is idle. One node-exec request failed during system.run.prepare despite the Hub logging local completion and an ok=True result send attempt. Root cause is unresolved; the report distinguishes observed failures from source-level hypotheses.

Environment

  • Windows 11 Pro, build 26300.
  • Hub 2026.9.8-1, installed product revision 2ba89f377ce8ce3f5ddfc452e4d509329f109114.
  • Installed self-contained runtime configuration: .NET / WindowsDesktop 10.0.12.
  • Gateway 2026.9.9 (bcfc888), Node 24.19.0, Ubuntu-26.04 in WSL2 with mirrored networking.
  • Ordinary Gateway listener is loopback-only. No externally managed reverse proxy targets it. gateway.roles is absent and gateway.trustedProxies is empty.
  • Three Windows nodes exist. The original command explicitly targeted the Hub; later generic node-mode close records cannot all be assigned to it.

Observed reproduction

This is an intermittent live-installation observation, not a deterministic minimal reproduction:

  1. Connect the Windows Hub operator and node roles to the WSL Gateway.
  2. From a Main agent session, request a harmless echo through node exec, explicitly targeting the Hub with a Windows working directory and a 20-second tool timeout.
  3. Observe the request fail after approximately 5.8 seconds with DISCONNECTED: node disconnected (system.run.prepare), without stdout or exit status.
  4. Leave the agent idle. Automatic reconnects and premature closures also occur without another command.

Expected: prepare returns to the Gateway and an ordinary harmless command completes, or transport failure is reported accurately. Actual: result delivery is unconfirmed and sockets reconnect repeatedly.

Sanitized timeline, 2026-10-09 (BST, UTC+1)

Original request:

Time Hub observation
15:53:10.328 Prepare handled locally
15:53:10.332 Invoke-result send logged with ok=True
15:53:10.336 Local prepare invocation completed
15:53:12.458 Connection closed prematurely
15:53:12.459 Node disconnected
15:53:15.998 Node registered again

A later three-minute stock verbose-WebSocket observation, with no command canary, recorded:

Time Connection prefix Client mode Close code Cause Ping write Last pong age (ms) Buffered bytes
16:33:51.942 d0aee6ef cli 1006 heartbeat-timeout completed 44710.8 0
16:34:23.160 8f0379a3 node 1006 heartbeat-timeout completed 39671.8 0

Hub independently logged premature closure at exactly 16:33:51.942. That is strong correlation, not definitive process attribution: the Hub operator declares cli/cli, while its node declares node-host/node. The second record has not been assigned to a particular Windows node. The original prepare failure has no retained matching Gateway close-cause record.

Completed ping writes and zero buffered output do not prove peer receipt. A transient Gateway event-loop delay was observed near the original failure, but later idle disconnects mean it is not established as the sole cause. HTTP health checks returned 200 after restoration; the restored Gateway process stayed active with no automatic restarts, and the Hub process remained alive. Diagnostic logging was restored to normal afterward. These checks do not establish continuous uptime or a functioning node-exec route.

Exact-revision source findings, not a root-cause claim

Related reports and request

This differs from #1190, where MXC executes successfully but exceeds an approximately 30-second RPC limit. This failure happened during prepare, with disconnection after approximately 5.8 seconds and no process-execution receipt. It also differs from #1574, which concerns reconnects during Windows session teardown; no shutdown was in progress here.

Is there a released, supported repair matching this behavior? Otherwise, what bounded role/generation-specific diagnostic would distinguish missed protocol PONG processing from transport loss and attribute operator versus node closures? No permission expansion, timeout workaround, network-mode change, or unmerged patch has been applied. No raw traffic, session content, credentials, or personal paths are included.

Dominant language
C#
Stars
2.1k
Forks
315
Avg merge
2d 7h
Merged PRs (30d)
135

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.