Problem
The WhatsApp bridge's createWaSocket function calls makeWASocket() with only { authDir } — no socket-level timing or transport config is forwarded from OpenClaw's user-facing configuration. This means all Baileys socket defaults are hardcoded with no escape hatch:
| Setting |
Default |
Effect |
defaultQueryTimeoutMs |
60,000ms |
Query response timeout — if WhatsApp doesn't respond in 60s, Baileys tears down the connection |
keepAliveIntervalMs |
30,000ms |
WebSocket ping interval |
connectTimeoutMs |
20,000ms |
Connection establishment timeout |
agent |
undefined |
HTTP/SOCKS proxy for outbound requests |
When WhatsApp's server is slow to respond (high load, latency spikes), Baileys' own 60-second defaultQueryTimeoutMs fires, killing the connection. This triggers a reconnect. If the server is still slow, the new connection times out again — a persistent flapping loop. This has been observed to last 60–90 minutes, eventually triggering WhatsApp's server-side rate limiting.
The reconnect backoff config (web.reconnect) can mitigate the symptom (aggressive retry compounding the problem), but cannot prevent the initial disconnect from firing in the first place.
Evidence
Users experiencing ~80 minutes of connection flapping (disconnect/reconnect every ~60 seconds) with authAgeMs: 60000 on every reconnect cycle. Flapping self-resolves after WhatsApp server recovers.
Related Issues
This is the same architectural gap as the following previously-reported issues, just for different Baileys parameters:
Proposed Fix
The root fix: createWaSocket should forward an arbitrary socketConfig object from OpenClaw config to makeWASocket(). This solves the timeout issue, the proxy issue, and any future Baileys parameter needs in one change.
{
"web": {
"socketConfig": {
"defaultQueryTimeoutMs": 120000,
"keepAliveIntervalMs": 30000,
"connectTimeoutMs": 30000,
"agent": { "hostname": "proxy.example.com", "port": 8080 }
}
}
}Minimum viable change: bump defaultQueryTimeoutMs to 90–120s to give WhatsApp adequate headroom before Baileys kills connections. Proxy support would unblock corporate/network-restricted deployments.
The implementation is a single-line change to where makeWASocket is called — extract socketConfig from config and spread it into the makeWASocket options object alongside the existing auth, version, and logger fields.
Notes
- Distinct from
web.reconnect which controls reconnect behavior but not the initial disconnect trigger
web.heartbeatSeconds (OpenClaw-level, distinct from Baileys keepAliveIntervalMs) can already be configured; this issue is about Baileys-level socket config- The backoff config (
initialMs, factor, maxMs) is a useful complement but not a substitute for this fix
Problem
The WhatsApp bridge's
createWaSocketfunction callsmakeWASocket()with only{ authDir }— no socket-level timing or transport config is forwarded from OpenClaw's user-facing configuration. This means all Baileys socket defaults are hardcoded with no escape hatch:defaultQueryTimeoutMskeepAliveIntervalMsconnectTimeoutMsagentWhen WhatsApp's server is slow to respond (high load, latency spikes), Baileys' own 60-second
defaultQueryTimeoutMsfires, killing the connection. This triggers a reconnect. If the server is still slow, the new connection times out again — a persistent flapping loop. This has been observed to last 60–90 minutes, eventually triggering WhatsApp's server-side rate limiting.The reconnect backoff config (
web.reconnect) can mitigate the symptom (aggressive retry compounding the problem), but cannot prevent the initial disconnect from firing in the first place.Evidence
Users experiencing ~80 minutes of connection flapping (disconnect/reconnect every ~60 seconds) with
authAgeMs: 60000on every reconnect cycle. Flapping self-resolves after WhatsApp server recovers.Related Issues
This is the same architectural gap as the following previously-reported issues, just for different Baileys parameters:
createWaSocketdoesn't forwardagenttomakeWASocket; marked CLOSEDmakeWASocketpassthrough gap, proxy variant; still OPENdefaultQueryTimeoutMs: undefinedduring pairing to prevent premature timeout; the community has already identifieddefaultQueryTimeoutMsas a source of connection failuresProposed Fix
The root fix:
createWaSocketshould forward an arbitrarysocketConfigobject from OpenClaw config tomakeWASocket(). This solves the timeout issue, the proxy issue, and any future Baileys parameter needs in one change.{ "web": { "socketConfig": { "defaultQueryTimeoutMs": 120000, "keepAliveIntervalMs": 30000, "connectTimeoutMs": 30000, "agent": { "hostname": "proxy.example.com", "port": 8080 } } } }Minimum viable change: bump
defaultQueryTimeoutMsto 90–120s to give WhatsApp adequate headroom before Baileys kills connections. Proxy support would unblock corporate/network-restricted deployments.The implementation is a single-line change to where
makeWASocketis called — extractsocketConfigfrom config and spread it into themakeWASocketoptions object alongside the existingauth,version, andloggerfields.Notes
web.reconnectwhich controls reconnect behavior but not the initial disconnect triggerweb.heartbeatSeconds(OpenClaw-level, distinct from BaileyskeepAliveIntervalMs) can already be configured; this issue is about Baileys-level socket configinitialMs,factor,maxMs) is a useful complement but not a substitute for this fix