Summary

On a current OpenClaw stable install, embedded session websocket streaming repeatedly fails with HTTP 500 during connection setup, but the client falls back to HTTP and continues functioning.

Core gateway behavior, channel delivery, and watcher processes remain operational.

Observed behavior

Repeated log warnings of the form:

[ws-stream] WebSocket connect failed for session=<redacted>; falling back to HTTP. error=Error: Unexpected server response: 500

After fallback:

• normal assistant behavior continues
• message delivery still succeeds
• Gmail watcher still starts and runs
• gateway status remains healthy

Impact

• No obvious outage of core assistant functionality
• Likely degraded embedded-session streaming behavior
• Repeated warning noise in logs
• Suggests websocket transport path is broken while HTTP fallback still works

Environment

• OpenClaw stable 2026.3.28
• macOS 15.5
• Node 22.22.1
• local loopback gateway
• LaunchAgent-managed gateway service

What was ruled out

• not a general gateway outage
• not an auth failure
• not an iMessage failure
• not a Gmail watcher failure
• not limited to a single stale session after restart

Why that matters

Before restart, all websocket failures were tied to one embedded session id. After a clean gateway restart, websocket failures reappeared with a new session id as well.

That suggests this is not only stale in-memory state from one bad session.

Expected behavior

Embedded session websocket streaming should connect successfully without returning HTTP 500.

Actual behavior

Websocket setup returns HTTP 500, then the client falls back to HTTP and continues.

Possible areas to inspect

• embedded ws-stream route / upgrade handler regression
• mismatch between embedded session stream client and gateway websocket endpoint
• websocket auth / handshake path returning 500 while HTTP fallback path still works
• session replay / embedded session state handling after restart or update