Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: `openclaw system event` CLI never completes WebSocket challenge-response handshake (macOS, 2026.3.13) [1 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#52837•Fetched 2026-04-08 01:18:40
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
GodCC6GodCC6
Participants
GodCC6GodCC6Hollychou924Hollychou924
Timeline (top)
labeled ×2commented ×1cross-referenced ×1subscribed ×1

openclaw system event --text "..." --mode now connects to the Gateway WebSocket but never responds to the connect challenge, causing handshake timeout and the event is never delivered.

Error Message

Running node v24.12.0 (npm v11.9.0) 🦞 OpenClaw 2026.3.13 (61d171a) ... gateway connect failed: Error: gateway closed (1000): Error: gateway closed (1000 normal closure): no close reason Gateway target: ws://127.0.0.1:18789 Source: local loopback

Root Cause

  • This is not a regression from a previously working version of system event — it appears to be a missing implementation of challenge-response auth in the system event WebSocket client specifically.
  • The cron module works correctly because it runs inside the Gateway process and does not go through the CLI → WebSocket path.
  • openclaw doctor --repair does not fix this (it is a code-level omission, not an environment issue).
  • Distinct from #50380 (Windows, affects all CLI-to-gateway WS operations). This issue is isolated to the system event subcommand on macOS.
  • The gateway received SIGTERM after repeated failed handshake attempts in early testing, suggesting the failure cascade can destabilize the gateway process under certain conditions.

Fix Action

Fix / Workaround

Affected: Any user running openclaw system event on macOS with a local gateway. Severity: High — the system event CLI subcommand is completely non-functional; events are never delivered. Frequency: 100% reproducible (every invocation fails). Consequence: Cannot trigger manual/ad-hoc system notifications via CLI. Workaround is to rely solely on cron jobs (which run inside the Gateway and are unaffected).

Code Example

Running node v24.12.0 (npm v11.9.0)
🦞 OpenClaw 2026.3.13 (61d171a)
...
gateway connect failed: Error: gateway closed (1000):
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback

---

20:28:03 [ws] handshake timeout conn=815c5ed9-45c5-4480-b470-035f430b8263 remote=127.0.0.1
20:28:04 [ws] closed before connect conn=815c5ed9-45c5-4480-b470-035f430b8263 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1000 reason=n/a

---

[ws] closed before connect ... reason=connect challenge timeout
[ws] closed before connect ... reason=invalid request frame

---
RAW_BUFFERClick to expand / collapse

Bug type

Defect / Missing implementation (feature never worked as expected)

Summary

openclaw system event --text "..." --mode now connects to the Gateway WebSocket but never responds to the connect challenge, causing handshake timeout and the event is never delivered.

Steps to reproduce

  1. Start openclaw gateway (confirmed running, cron jobs work normally).
  2. Run: openclaw system event --text "handshake test" --mode now 2>&1
  3. Observe CLI output and gateway logs simultaneously.

Expected behavior

openclaw system event should complete the WebSocket challenge-response authentication and deliver the system event (e.g. trigger a Telegram notification).

Actual behavior

CLI exits with gateway connect failed: Error: gateway closed (1000 normal closure): no close reason. The event is never delivered.

CLI output:

Running node v24.12.0 (npm v11.9.0)
🦞 OpenClaw 2026.3.13 (61d171a)
...
gateway connect failed: Error: gateway closed (1000):
Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback

Gateway logs:

20:28:03 [ws] handshake timeout conn=815c5ed9-45c5-4480-b470-035f430b8263 remote=127.0.0.1
20:28:04 [ws] closed before connect conn=815c5ed9-45c5-4480-b470-035f430b8263 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1000 reason=n/a

Earlier reproduction also produced:

[ws] closed before connect ... reason=connect challenge timeout
[ws] closed before connect ... reason=invalid request frame

The CLI connects to the WebSocket but never responds to the Gateway's connect challenge (nonce). The Gateway times out and closes the connection. On repeated attempts, the CLI eventually sends an invalid request frame instead of answering the challenge.

OpenClaw version

2026.3.13 (61d171a), Node v24.12.0

Operating system

macOS

Install method

No response

Model

N/A (CLI-to-gateway WebSocket bug, not model-dependent)

Provider / routing chain

N/A (CLI-to-gateway WebSocket bug, not model-dependent)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: Any user running openclaw system event on macOS with a local gateway. Severity: High — the system event CLI subcommand is completely non-functional; events are never delivered. Frequency: 100% reproducible (every invocation fails). Consequence: Cannot trigger manual/ad-hoc system notifications via CLI. Workaround is to rely solely on cron jobs (which run inside the Gateway and are unaffected).

Additional information

  • This is not a regression from a previously working version of system event — it appears to be a missing implementation of challenge-response auth in the system event WebSocket client specifically.
  • The cron module works correctly because it runs inside the Gateway process and does not go through the CLI → WebSocket path.
  • openclaw doctor --repair does not fix this (it is a code-level omission, not an environment issue).
  • Distinct from #50380 (Windows, affects all CLI-to-gateway WS operations). This issue is isolated to the system event subcommand on macOS.
  • The gateway received SIGTERM after repeated failed handshake attempts in early testing, suggesting the failure cascade can destabilize the gateway process under certain conditions.

extent analysis

Fix Plan

To fix the issue, we need to implement the challenge-response authentication in the system event WebSocket client. Here are the steps:

  • Modify the openclaw system event command to handle the connect challenge:
    • Listen for the connect_challenge event from the Gateway WebSocket.
    • Respond to the challenge with the correct authentication response.
  • Update the WebSocket client to handle the connect_challenge event and send the authentication response.

Example code:

// Handle connect challenge event
ws.on('connect_challenge', (nonce) => {
  const response = authenticate(nonce); // Implement authentication logic
  ws.send(`connect_response ${response}`);
});

// Implement authentication logic
function authenticate(nonce) {
  // TO DO: Implement authentication logic to respond to the connect challenge
  // For example:
  const secretKey = 'your_secret_key';
  const response = crypto.createHmac('sha256', secretKey).update(nonce).digest('hex');
  return response;
}
  • Ensure the authenticate function is implemented correctly to respond to the connect challenge.

Verification

To verify the fix, run the openclaw system event command and check the Gateway logs for a successful connection and event delivery.

Example verification steps:

  • Run: openclaw system event --text "handshake test" --mode now 2>&1
  • Check the Gateway logs for a successful connection and event delivery:
    • Look for logs indicating a successful WebSocket connection and event delivery.
    • Verify that the event is triggered correctly (e.g., a Telegram notification is sent).

Extra Tips

  • Ensure the authenticate function is implemented correctly to respond to the connect challenge.
  • Test the fix thoroughly to ensure it works correctly in all scenarios.
  • Consider adding additional logging or debugging to help diagnose any issues that may arise.

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

openclaw system event should complete the WebSocket challenge-response authentication and deliver the system event (e.g. trigger a Telegram notification).

#latency issue#model loading#dependency error#configuration error#environment variable

Still need to ship something?

×6

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

Back to top recommendations

TRENDING