Bug Description

The dashboard webchat WebSocket connection silently drops (close code 1006) during long tool call chains. Messages are buffered server-side and flood in when the user sends a new message (which opens a fresh connection).

Root Cause Analysis

Gateway logs show zero WebSocket ping/pong keepalive frames. During tool calls, no data flows on the WebSocket for 30-60s, causing network intermediaries to treat the connection as idle and kill it.

Evidence from gateway logs:

[ws] webchat disconnected code=1006 reason=n/a conn=<id1>
[ws] webchat disconnected code=1006 reason=n/a conn=<id2>
[ws] webchat disconnected code=1006 reason=n/a conn=<id3>
[ws] webchat disconnected code=1006 reason=n/a conn=<id4>

12 disconnects in 17 minutes, each with a unique connection ID — the client reconnects but keeps getting killed.

Grepping logs for ping, keepalive, or heartbeat returns zero WebSocket-related results, confirming the server does not send WS ping frames.

Environment

• OpenClaw 2026.3.24
• Connection: Tailscale direct WireGuard tunnel (not DERP relay, not Funnel)
• Both machines on same LAN, direct peering confirmed
• OS: Linux server, Windows client
• Browser: Chrome

Steps to Reproduce

1. Open dashboard webchat
2. Send a message that triggers multiple tool calls (e.g., browser automation, exec chains)
3. Wait 30-60s while tools execute
4. Observe: chat stops updating, no new messages appear
5. Send another message
6. All buffered messages flood in at once

Expected Behavior

WebSocket connection should stay alive during tool execution. Server should send periodic ping frames (every 15-30s) to prevent intermediaries from killing idle connections.

Actual Behavior

WebSocket dies silently (code 1006) during idle periods. Messages are persisted but not delivered until a new connection is established.

Suggested Fix

Add server-side WebSocket ping frames at a 15-30s interval on webchat connections. This is standard WebSocket best practice (RFC 6455 §5.5.2) and would prevent any intermediary from treating the connection as idle.

Related Issues

• [Bug]: Regression: async exec approval completion is persisted but not shown live in TUI or Control UI #40063 — Similar symptom (messages not shown live in TUI/Control UI after exec approval)
• [Control UI] Streaming responses create multiple message bubbles instead of updating single bubble #38584 — Control UI streaming creates multiple bubbles (different root cause but same surface area)