Helps with speed and Gateway connection | Friends of the Crustacean 🦞🤝 | Page 1

versed gale Apr 23, 2026, 10:42 AM

#

OpenClaw 2026.4.15 (041266a)
Windows
npm global install

I need help me some openclaw speed and connection issue with whatsapp.

Issue:

Startup openclaw takes a long time. even replying from chat also take a very long time.
Whatsapp disconnection too frequent and high chance of openclaw dint catch the messages.

Model using:
https://api.z.ai/api/coding/paas/v4
z.ai/
glm-4.7 and glm-5.1

18:34:59 [gateway] loading configuration…
18:34:59 Config warnings:\n- plugins.entries.minimax-portal-auth: plugin not found: minimax-portal-auth (stale config entry ignored; remove it from plugins config)
18:35:00 [gateway] resolving authentication…
18:35:00 [gateway] starting...
18:35:56 [gateway] starting HTTP server...
18:35:56 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\Wapapapow.openclaw\canvas)
18:35:56 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:35:57 [gateway] agent model: zai/glm-5.1
18:35:57 [gateway] ready (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, whatsapp; 56.9s)
18:35:57 [gateway] log file: \tmp\openclaw\openclaw-2026-04-23.log
18:35:58 [gateway] starting channels and sidecars...
18:35:59 [hooks] loaded 4 internal hook handlers

quick cryptBOT Apr 23, 2026, 10:42 AM

#

proven craneBOT Apr 23, 2026, 10:42 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

versed gale Apr 23, 2026, 10:42 AM

#

18:36:02 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=Kanorin-SatanicDevice (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
18:37:20 [bonjour] restarting advertiser (service stuck in announcing for 77807ms (gateway fqdn=Kanorin-SatanicDevice (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
18:38:37 [bonjour] restarting advertiser (service stuck in announcing for 16843ms (gateway fqdn=Kanorin-SatanicDevice (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
18:38:42 [whatsapp] [default] starting provider (+60126231162)
18:38:43 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=Kanorin-SatanicDevice (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=unannounced)
18:38:43 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw\workspace)
18:38:43 (node:137664) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use node --trace-deprecation ... to show where the warning was created)
18:38:43 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
18:38:43 [heartbeat] started
18:38:47 [plugins] embedded acpx runtime backend ready
18:39:44 [bonjour] restarting advertiser (service stuck in announcing for 61422ms (gateway fqdn=Kanorin-SatanicDevice (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
18:39:52 [whatsapp] Listening for personal WhatsApp inbound messages.

thick surgeBOT Apr 23, 2026, 10:47 AM

#

A few things stand out.

56.9s startup is genuinely slow, but your log also shows the gateway says ready before starting channels and sidecars..., so WhatsApp may still be coming up after that. In other words, “gateway ready” does not mean “WhatsApp fully healthy” yet.
This warning should be cleaned up:
plugins.entries.minimax-portal-auth: plugin not found: minimax-portal-auth
It is probably not the whole cause, but remove that stale plugin entry from your config.
Yes, model choice can absolutely be part of the chat slowness.
Z.AI / GLM is not the lowest-latency path, and GLM-4.x enables thinking by default unless you turn it off. Even on glm-5.1, I would still A/B test with thinking off.
For WhatsApp, “missed messages” is often one of these:
- reconnect instability
- pairing/access policy blocking messages
- group rules like requireMention
- extra history/context making each reply slower

#

Please run these and paste the output:

openclaw status
openclaw gateway status
openclaw doctor
openclaw channels status --probe

Then tail logs and wait for one bad WhatsApp disconnect/reconnect cycle:

openclaw logs --follow

If you see disconnected (1008): pairing required, run:

#

openclaw pairing list whatsapp
openclaw pairing approve whatsapp <CODE>

Quick things I’d test right now:

In chat: /think off or /reasoning off
Optionally: /fast on
Reduce WhatsApp context injection:
- channels.whatsapp.historyLimit
- messages.groupChat.historyLimit
- setting either to 0 disables that injected history
Check WhatsApp policy settings:
- dmPolicy
- allowFrom
- groupPolicy

#

groupAllowFrom
- requireMention

Also, if this Windows machine sleeps, changes network a lot, or is not always on, that alone can cause frequent WhatsApp reconnects. A VPS or dedicated always-on box is usually much more stable for WhatsApp.

Docs:

Paste the 4 command outputs plus a short reconnect log snippet, and I can narrow it down pretty fast.

#

This log is much more revealing.

The big takeaway:

56.9s is only gateway core ready
WhatsApp is not actually ready until
18:39:52 [whatsapp] Listening for personal WhatsApp inbound messages.

So your real cold start here is closer to 4m53s, which is definitely too slow.

What this snippet suggests:

Bonjour/mDNS is flapping
You have repeated:
- watchdog detected non-announced service
- restarting advertiser
- service stuck in announcing

#

That usually points to local mDNS/discovery trouble. If you do not need LAN auto-discovery for nodes/devices, I’d temporarily disable it and retest startup:

{
  discovery: {
    mdns: { mode: "off" },
  },
}

or set:

OPENCLAW_DISABLE_BONJOUR=1

If startup improves a lot, you found one blocker.

#

The model is probably not the main startup cause
glm-4.7 / glm-5.1 can absolutely make reply generation slower, but they do not explain why WhatsApp itself only starts listening almost 5 minutes after launch.
This looks more like slow sidecar/channel bring-up
Notice how late these happen:
- 18:38:42 [whatsapp] [default] starting provider
- 18:38:43 [browser/server] ...
- 18:38:47 [plugins] embedded acpx runtime backend ready
So the pain is mostly in startup sequencing, not just model latency.
DEP0190 is just a deprecation warning, not the main problem.

Also still do these cleanup/tests:

remove the stale minimax-portal-auth plugin entry
test /think off or /reasoning off

#

test /fast on
reduce:
- channels.whatsapp.historyLimit
- messages.groupChat.historyLimit
- set to 0 if you want to fully disable injected history

Please paste these next:

openclaw status --all
openclaw doctor
openclaw channels status --probe

And for the disconnect problem, I still need the actual WhatsApp failure lines from:

#

openclaw logs --follow

Specifically, the lines around:

disconnected
reconnecting
pairing required
max attempts
lastError

If you want, I can also help you trim this into a “fast startup” config next. Docs for the relevant bits:

versed gale Apr 23, 2026, 10:54 AM

#

on claudecode, paired with z.ai glm 4.7 and 5.1 works fine. no issue. fast. only slow in openclaw.
Paring is fine. no issue. already paired. i even disconnected and paired agained.

Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-23.log
Command: C:\Program Files\nodejs\node.exe C:\Users\Wapapapow\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
Service file: ~.openclaw\gateway.cmd
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~.openclaw\openclaw.json
Config (service): ~.openclaw\openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (last run 267009, last run time 23/4/2026 6:50:12 PM)
RPC probe: ok

thick surgeBOT Apr 23, 2026, 10:56 AM

#

That helps a lot.

If the same Z.AI models are fast in Claude Code, I would not blame Z.AI first. At this point the bottleneck looks mostly OpenClaw-side, not provider-side.

Your logs already show that:

gateway says ready at 18:35:57
WhatsApp only becomes usable at 18:39:52

So the slow part is mostly startup / plugin / channel overhead, not just model latency.

Also, pairing being fine is good, but it means re-pairing is probably not the fix here.

What I’d test next, in this order:

1) Disable Bonjour/mDNS, just as an A/B test

Your logs show it repeatedly getting stuck.

#

If you do not need LAN discovery for nodes/devices, set:

{
  discovery: {
    mdns: { mode: "off" },
  },
}

or use OPENCLAW_DISABLE_BONJOUR=1

That should tell us quickly whether bonjour churn is a real startup blocker.

2) Turn off extra per-message overhead

OpenClaw adds more than Claude Code does: WhatsApp history injection, tool schema, memory, hooks, etc.

#

Temporarily test:

{
  agents: {
    defaults: {
      thinkingDefault: "off",
    },
  },
  channels: {
    whatsapp: {
      historyLimit: 0,
    },
  },
  messages: {
    groupChat: {

#

      historyLimit: 0,
    },
  },
}

Or in chat, at least try:

/think off
/fast on

3) Clean up unused plugins

You currently load:

#

acpx
browser
device-pair
memory-core
phone-control
talk-voice
whatsapp

If you mainly want WhatsApp only, I’d temporarily disable anything you don’t actually use and compare startup again.

4) Remove the stale plugin entry

Definitely remove:

plugins.entries.minimax-portal-auth

#

That warning is probably not the main cause, but stale config is never helping.

What I still need from you:

openclaw channels status --probe

That one is important, because it should show whether WhatsApp is healthy, reconnecting, or carrying a lastError.

And for the disconnect issue, please paste the actual WhatsApp lines around a failure from:

openclaw logs --follow

#

I’m looking specifically for lines containing:

[whatsapp]
disconnected
reconnecting
lastError
pairing required
max attempts

One more useful detail: is this machine a desktop that stays awake, or a laptop that sleeps / switches networks? That matters a lot for WhatsApp stability.

If you want, next reply I can give you a minimal low-latency OpenClaw config for “Windows + WhatsApp + Z.AI only”.

versed gale Apr 23, 2026, 11:00 AM

#

18:54:07 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
18:54:08 [plugins] embedded acpx runtime backend ready
18:54:15 [ws] ⇄ res ✓ channels.status 890ms conn=540d8bb2…3230 id=0559e120…5477
18:54:27 [ws] ⇄ res ✓ doctor.memory.status 11763ms conn=721eed6c…e2d3 id=136f5a88…2df0
18:56:14 [whatsapp] Inbound message +xxxx-> +xxxx(direct, 68 chars)
18:56:14 [whatsapp] Inbound message +xxxx-> +xxxx(direct, 69 chars)
18:57:24 [whatsapp] Web connection closed (status 428). Retry 1/12 in 2.18s… (status=428 Precondition Required Connection Terminated)

Gateway reachable.

WhatsApp default: enabled, configured, linked, running, connected, in:3m ago, out:1m ago, dm:allowlist, allow:+60126231162

10:56:14+00:00 info gateway/channels/whatsapp/inbound {"subsystem":"gateway/channels/whatsapp/inbound"} Inbound message +xxxx-> +xxxx(direct, 69 chars)
10:57:24+00:00 info web-reconnect {"module":"web-reconnect","runId":"dea4d7f6-d60d-487a-94a8-1355e55d0b3d"} {"connectionId":"0d7b6dcb-1b5e-4c9e-a5db-9e8bdb9e7278","status":428,"loggedOut":false,"reconnectAttempts":1,"error":"status=428 Precondition Required Connection Terminated"} web reconnect: connection closed
10:57:24+00:00 info web-reconnect {"module":"web-reconnect","runId":"dea4d7f6-d60d-487a-94a8-1355e55d0b3d"} {"connectionId":"0d7b6dcb-1b5e-4c9e-a5db-9e8bdb9e7278","status":428,"reconnectAttempts":1,"maxAttempts":12,"delayMs":2184} web reconnect: scheduling retry
10:57:24+00:00 error gateway/channels/whatsapp {"subsystem":"gateway/channels/whatsapp"} WhatsApp Web connection closed (status 428). Retry 1/12 in 2.18s… (status=428 Precondition Required Connection Terminated)

thick surgeBOT Apr 23, 2026, 11:03 AM

#

Nice, this narrows it down a lot.

At this point I’d split it like this:

1) Slow replies / startup

This is not mainly Z.AI, since the same models are fast in Claude Code.

Your slow path is mostly OpenClaw overhead:

extra plugins
WhatsApp channel startup
history injection
thinking/tool context
bonjour churn

2) WhatsApp disconnects

Now we have the real error:

#

WhatsApp Web connection closed (status 428). Retry 1/12 in 2.18s…
(status=428 Precondition Required Connection Terminated)

That means:

not pairing failure
not allowlist failure
not model failure

It is the WhatsApp Web socket/session getting terminated, then OpenClaw tries to reconnect.

Two important things jump out:

A. Your reconnect policy is capped

The log says Retry 1/12, so you are not using the default unlimited retries.

#

I would change that first:

{
  web: {
    reconnect: {
      initialMs: 2000,
      maxMs: 120000,
      factor: 1.4,
      jitter: 0.2,
      maxAttempts: 0, // unlimited
    },
  },
}

If it stays at 12, once it burns through those attempts, missed messages become much more likely.

#

B. Disable Bonjour on this box

Your gateway is loopback-only:

Gateway: bind=loopback (127.0.0.1)

So mDNS/Bonjour is basically not helping you here, and your earlier logs showed it flapping. I’d turn it off:

{
  discovery: {
    mdns: { mode: "off" },
  },
}

#

That is a very reasonable test on this setup.

Minimal low-latency config tests I’d do

{
  discovery: {
    mdns: { mode: "off" },
  },

  agents: {
    defaults: {
      thinkingDefault: "off",
    },

#

  },

  channels: {
    whatsapp: {
      historyLimit: 0,
    },
  },

  messages: {
    groupChat: {
      historyLimit: 0,
    },
  },

  web: {

#

    reconnect: {
      initialMs: 2000,
      maxMs: 120000,
      factor: 1.4,
      jitter: 0.2,
      maxAttempts: 0,
    },
  },
}

Also:

remove the stale minimax-portal-auth plugin entry
if you do not use browser, acpx, phone-control, talk-voice, disable them temporarily and compare startup time
in chat, test /think off and /fast on

#

What I think is most likely

Reply slowness: OpenClaw context + thinking + plugin overhead
Missed WhatsApp messages: repeated 428 reconnect churn, plus your retry cap of 12

If you apply the 3 biggest changes first:

discovery.mdns.mode: "off"
web.reconnect.maxAttempts: 0
historyLimit: 0 + thinking off

…you should get a much cleaner signal fast.

If 428 still happens every few minutes after that, I’d start suspecting a genuine WhatsApp/Baileys-side instability and then it may be GitHub-issue territory: https://github.com/openclaw/openclaw/issues

Docs:

#

If you want, paste your sanitized web.reconnect + discovery config section next, and I’ll sanity-check it.

versed gale Apr 23, 2026, 11:07 AM

#

okay let me fix some part while i tell you more. the reconnect part.

While i was using, it constantly disconnected and reconnect. it even happens like 3-5 times in a minutes

Failed to connect > then reconnect > success > immediately disconnected again.

thick surgeBOT Apr 23, 2026, 11:09 AM

#

Yeah, 3 to 5 disconnects per minute is absolutely not normal, and yes, that can definitely make OpenClaw miss messages.

At that rate, I’d stop looking at the model. This is almost certainly WhatsApp transport/session churn.

What I’d prioritize right now:

Set reconnects to unlimited
Your log showed Retry 1/12, so don’t let it give up.
```
{
  web: {
    reconnect: {
      maxAttempts: 0,
    },
  },
```

#

Disable Bonjour/mDNS
Your gateway is loopback-only, and bonjour was already flapping.
```
{
  discovery: {
    mdns: { mode: "off" },
  },
}
```
Test on the most boring network possible
For one test run:

#

no VPN
- no proxy
- no network switching
- machine stays awake
- phone stays online normally

Do not judge it from one reconnect
After changing config, let it run 5 to 10 minutes and see if the 428 loop is gone.

Also, the pattern you described:

reconnect succeeds, then immediately disconnects again

…really does sound like the session is being killed repeatedly, not just a slow model or prompt issue.

If you can, send 20 to 30 lines around one full bad cycle after your config changes, especially lines containing:

[whatsapp]

#

status 428
reconnecting
connected
lastError

If it’s still doing the same 428 Precondition Required Connection Terminated loop after:

mdns: off
maxAttempts: 0
stable network / no VPN

then I’d start treating it as a likely OpenClaw WhatsApp/Baileys bug and point you to file it here: https://github.com/openclaw/openclaw/issues

If you want, once you paste your updated config snippet, I’ll check it before you restart.

versed gale Apr 23, 2026, 11:11 AM

#

19:05:44 [gateway] loading configuration…
19:05:45 [gateway] resolving authentication…
19:05:45 [gateway] starting...
19:06:29 [gateway] starting HTTP server...
19:06:29 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\Wapapapow.openclaw\canvas)
19:06:29 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
19:06:30 [gateway] agent model: zai/glm-5.1
19:06:30 [gateway] ready (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, whatsapp; 44.1s)
19:06:30 [gateway] log file: \tmp\openclaw\openclaw-2026-04-23.log
19:06:30 [gateway] starting channels and sidecars...
19:06:31 [hooks] loaded 4 internal hook handlers
19:09:14 [whatsapp] [default] starting provider (+60126231162)
19:09:14 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw\workspace)
19:09:14 (node:120448) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
(Use node --trace-deprecation ... to show where the warning was created)
19:09:14 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
19:09:14 [heartbeat] started
19:09:16 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
19:09:17 [plugins] embedded acpx runtime backend ready

still took a long time to pass. but faster than just now

mdns: off
maxAttempts: 0
stable network / no VPN
Lan - 500mbps stable/novpns

i will start the testing on message. then i will get back to you

thick surgeBOT Apr 23, 2026, 11:12 AM

#

That’s useful, nice catch.

So far it looks like:

mDNS off helped a bit
unlimited reconnects are set
network is probably not the problem

Your numbers now are roughly:

19:05:44 startup begins
19:06:30 gateway ready
19:09:16 WhatsApp listening

So total cold start is still about 3m32s, and the biggest remaining gap is:

gateway ready → whatsapp starting provider = about 2m44s

#

That strongly suggests the remaining delay is in sidecar / plugin startup, not the model, not pairing, and probably not network.

So yes, this is better, but still too slow.

For now I’d do exactly what you said, don’t change more variables yet, and just test the message reconnect behavior.

When you come back, the two key results I care about are:

Did the 3 to 5 disconnects/minute improve?
Did replies get any faster after the reconnect changes?

If disconnects improve but startup is still awful, the next isolation step is:

temporarily disable unused plugins/sidecars, especially if you don’t use:
- browser
- acpx
- phone-control
- talk-voice

#

device-pair

If that drops startup a lot, we found the blocker.

If the startup still sits around 3+ minutes even after trimming unused pieces, I’d start treating that as likely bug territory and point it to GitHub: https://github.com/openclaw/openclaw/issues

Go ahead with the message test, and send the next log chunk when it flakes.

versed gale Apr 23, 2026, 4:44 PM

#

21:41:51 [whatsapp] Web connection closed (status 408). Retry 1/∞ in 2.17s… (status=408 Request Time-out Connection was lost)
21:41:54 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
21:46:30 [whatsapp] Web connection closed (status 408). Retry 1/∞ in 2.14s… (status=408 Request Time-out Connection was lost)
21:46:34 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
21:54:37 [whatsapp] Web connection closed (status 428). Retry 1/∞ in 2.07s… (status=428 Precondition Required Connection Terminated)
[session-write-lock] releasing lock held for 191457ms (max=15000ms): C:\Users\Wapapapow.openclaw\agents\main\sessions\sessions.json.lock
21:54:55 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
22:09:42 [whatsapp] Web connection closed (status 428). Retry 1/∞ in 2.16s… (status=428 Precondition Required Connection Terminated)
22:10:08 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
22:28:02 [whatsapp] Web connection closed (status 428). Retry 1/∞ in 2.21s… (status=428 Precondition Required Connection Terminated)
22:29:20 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: disconnected)
22:29:21 [whatsapp] [default] starting provider (+60126231162)
22:29:24 [whatsapp] Listening for personal WhatsApp inbound messages.

#

23:00:04 [whatsapp] No messages received in 30m - restarting connection
23:00:04 [whatsapp] Web connection closed (status 499). Retry 1/∞ in 2.23s… (status=499)
23:03:13 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: disconnected)
23:03:25 [whatsapp] [default] channel stop exceeded 5000ms after abort; continuing shutdown
23:03:35 [whatsapp] Listening for personal WhatsApp inbound messages.
Ctrl+C to stop.
23:03:35 [whatsapp] Failed hydrating participating groups on connect: 1006
23:05:23 [cron:28301bd9-8059-44b5-b4b7-7cd247a34a14] transient direct announce delivery failure, retrying 2/4 in 5s: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.

00:37:05 [tools] message failed: Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default. raw_params={"action":"send","channel":"whatsapp","message": "xxxxx"}

thick surgeBOT Apr 23, 2026, 4:46 PM

#

This is actually pretty good data.

What improved

Your reconnect storm is much better than before. It is no longer 3 to 5 times per minute. So:

mdns: off helped
maxAttempts: 0 helped
stable LAN / no VPN helped

What is still wrong

You still have periodic WhatsApp drops:

408 Request Time-out Connection was lost
428 Precondition Required Connection Terminated

So the WhatsApp socket is still unstable, just less unstable now.

#

The most interesting new clue

This line really matters:

[session-write-lock] releasing lock held for 191457ms (max=15000ms): C:\Users\Wapapapow\.openclaw\agents\main\sessions\sessions.json.lock

That is a lock held for 191 seconds, with a normal max of 15 seconds.

I’m pretty confident this can contribute to the “OpenClaw feels slow / stuck” part, because it means session state writes were blocked for a very long time.

So at this point I think you may have two overlapping issues:

WhatsApp Web transport churn (408 / 428)
Session lock / session store slowness on Windows

#

Next thing I would do

Run this once:

openclaw doctor --fix

That is the right built-in tool for stale session lock cleanup and general state repair.
Docs: https://docs.openclaw.ai/gateway/doctor

Then check whether that lock warning keeps happening. If you want to search the log in PowerShell:

Select-String -Path \tmp\openclaw\openclaw-2026-04-23.log -Pattern "session-write-lock","sessions.json.lock"

#

If you see that warning repeatedly, I would treat it as strong bug evidence.

My current read

Startup slowness: still too slow, likely sidecar/plugin/session-store related
Reply slowness: likely worsened by the long sessions.json.lock
WhatsApp reliability: improved, but still flaky enough to be a real issue

Honestly, with:

mdns: off
maxAttempts: 0
stable LAN / no VPN
and still getting 408/428 plus a 191s session lock hold

…I’m leaning toward GitHub issue territory now.

#

If you want, I can help you draft a clean bug report with the exact evidence to paste here:
https://github.com/openclaw/openclaw/issues

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

#

Yeah, this is enough to call bug territory now.

These lines are the smoking gun:

No messages received in 30m - restarting connection
Web connection closed (status 499)
health-monitor: restarting (reason: disconnected)
channel stop exceeded 5000ms after abort; continuing shutdown
Failed hydrating participating groups on connect: 1006
No active WhatsApp Web listener

That means the WhatsApp listener is stalling / dying, then recovery is incomplete for a while, which is exactly why messages and sends fail.

Also, the “link WhatsApp again” text is just the generic fallback error. In your case, I would not keep re-linking, because the account is clearly able to reconnect sometimes. The real problem is the listener lifecycle, not initial pairing.

My conclusion

#

You’ve already ruled out the obvious stuff:

pairing/access issue, no
VPN/network instability, probably no
mDNS discovery weirdness, reduced but not root cause
retry limit too low, fixed
Z.AI model speed, not the root cause

At this point I’d file a GitHub issue with the evidence.

Suggested issue title

WhatsApp listener repeatedly disconnects / stalls on Windows, causing "No active WhatsApp Web listener", 408/428/499 closes, slow startup

Suggested body

Version: OpenClaw 2026.4.15 (041266a)
OS: Windows
Install: npm global install

#

Gateway: loopback only, scheduled task
Provider: Z.AI (glm-4.7, glm-5.1)
Changes already tested:
- discovery.mdns.mode: "off"
- web.reconnect.maxAttempts: 0
- stable LAN, no VPN
- re-paired WhatsApp already
Observed startup delay:
- gateway ready in ~44s to ~57s
- WhatsApp listener usable only after ~3.5 to ~5 minutes total
Observed runtime failures:
- 408 Request Time-out Connection was lost
- 428 Precondition Required Connection Terminated
- 499 after No messages received in 30m - restarting connection
- Failed hydrating participating groups on connect: 1006
- No active WhatsApp Web listener
- cron / message sends fail while listener is down

#

Additional suspicious log:
- [session-write-lock] releasing lock held for 191457ms (max=15000ms): ...sessions.json.lock

Issue link: https://github.com/openclaw/openclaw/issues

If you want, I can turn all your pasted logs into a clean, ready-to-submit GitHub issue body in one message.

versed gale Apr 23, 2026, 4:51 PM

#

Sure do, just to be clear, the doctor fix I don't know run how many times already haha... Nothing works. Actually this issue persist for a long time. The session lock issue, I have no idea. I literally just startup the openclaw with comma d bellow
openclaw gateway stop
Openclaw gateway restart/start

Whatsapp I will submit a bug request but this session log?
Btw, my openclaw is at c:\users\wapapapow
But pointed workspace is
F:\openclaw\workspace
Well I don't think it does anything just to let you know.

thick surgeBOT Apr 23, 2026, 4:52 PM

#

Yep, the session lock is worth reporting too.

And the reason doctor --fix didn’t help actually makes sense:

doctor --fix cleans up stale dead lock files
your log shows a lock that was actively held by a live process for 191457ms, then released

So this is not just stale lock cleanup, it looks more like a runtime/session-persistence problem.

Also, C:\Users\Wapapapow\.openclaw for state + F:\openclaw\workspace for workspace is not inherently wrong. I’d include it as context, but I would not assume that alone is the bug.

My recommendation

File 2 separate issues:

WhatsApp listener instability
Session lock / slow startup / slow replies on Windows

#

That’ll make it much easier for maintainers to track.

Issue 1, WhatsApp listener instability

Title

WhatsApp listener repeatedly disconnects/stalls on Windows, causing "No active WhatsApp Web listener" and missed messages

Body

### Environment
- OpenClaw version: `2026.4.15 (041266a)`
- OS: Windows

#

- Install method: npm global install
- Gateway service: Scheduled Task
- State dir: `C:\Users\Wapapapow\.openclaw`
- Workspace: `F:\openclaw\workspace`
- Gateway bind: loopback (`127.0.0.1:18789`)
- Model/provider in use: Z.AI (`glm-4.7`, `glm-5.1`)

### Problem
WhatsApp disconnects and reconnects frequently, and OpenClaw often misses messages or cannot send because the WhatsApp listener is not active.

### What I already tested
- Re-paired WhatsApp multiple times
- Set `discovery.mdns.mode: "off"`
- Set `web.reconnect.maxAttempts: 0`
- Stable LAN, no VPN

#

- `openclaw doctor --fix` many times
- Same Z.AI models are fast in Claude Code, so the provider itself does not seem to be the root cause

### Symptoms
- Frequent reconnects
- Missed inbound messages
- Outbound send failures
- Cron/message delivery failures with:
  - `No active WhatsApp Web listener (account: default)`

### Relevant logs
```text
21:41:51 [whatsapp] Web connection closed (status 408). Retry 1/∞ in 2.17s… (status=408 Request Time-out Connection was lost)
21:41:54 [whatsapp] Listening for personal WhatsApp inbound messages.

21:54:37 [whatsapp] Web connection closed (status 428). Retry 1/∞ in 2.07s… (status=428 Precondition Required Connection Terminated)

#

21:54:55 [whatsapp] Listening for personal WhatsApp inbound messages.

22:28:02 [whatsapp] Web connection closed (status 428). Retry 1/∞ in 2.21s… (status=428 Precondition Required Connection Terminated)
22:29:20 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: disconnected)
22:29:21 [whatsapp] [default] starting provider (+60126231162)
22:29:24 [whatsapp] Listening for personal WhatsApp inbound messages.

23:00:04 [whatsapp] No messages received in 30m - restarting connection
23:00:04 [whatsapp] Web connection closed (status 499). Retry 1/∞ in 2.23s… (status=499)
23:03:13 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: disconnected)
23:03:25 [whatsapp] [default] channel stop exceeded 5000ms after abort; continuing shutdown
23:03:35 [whatsapp] Listening for personal WhatsApp inbound messages.
23:03:35 [whatsapp] Failed hydrating participating groups on connect: 1006

23:05:23 [cron:28301bd9-8059-44b5-b4b7-7cd247a34a14] transient direct announce delivery failure, retrying 2/4 in 5s: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.

00:37:05 [tools] message failed: Error: No active WhatsApp Web listener (account: default). Start the gateway, then link WhatsApp with: openclaw channels login --channel whatsapp --account default.

#


### Notes
The generic “link WhatsApp again” suggestion does not seem to be the actual fix here, because the account is already linked and the listener sometimes reconnects successfully before dying again.

Issue 2, session lock / slow startup / slow replies

Title

Windows startup and reply latency, session lock held for 191s on sessions.json.lock

Body

#

### Environment
- OpenClaw version: `2026.4.15 (041266a)`
- OS: Windows
- Install method: npm global install
- Gateway service: Scheduled Task
- State dir: `C:\Users\Wapapapow\.openclaw`
- Workspace: `F:\openclaw\workspace`

### Problem
OpenClaw startup is very slow, replies are also slow, and I saw a session write lock being held far longer than expected.

### Observed startup timing
Example startup:

```text
19:05:44 [gateway] loading configuration…

#

19:05:45 [gateway] resolving authentication…
19:05:45 [gateway] starting...
19:06:29 [gateway] starting HTTP server...
19:06:30 [gateway] ready (7 plugins: acpx, browser, device-pair, memory-core, phone-control, talk-voice, whatsapp; 44.1s)
19:06:30 [gateway] starting channels and sidecars...
19:09:14 [whatsapp] [default] starting provider (+60126231162)
19:09:16 [whatsapp] Listening for personal WhatsApp inbound messages.


So even after config cleanup/tests, total usable startup is still about **3m32s**.

Earlier runs were worse, around **4m53s** total.

### Relevant lock warning
```text
[session-write-lock] releasing lock held for 191457ms (max=15000ms): C:\Users\Wapapapow\.openclaw\agents\main\sessions\sessions.json.lock

#


### Notes
- I have already run `openclaw doctor --fix` many times
- That did not solve the issue
- This does not look like only a stale dead lock file, because the warning says the lock was actively held and then released
- Same model/provider works fast in Claude Code, so the slowdown appears to be OpenClaw-side rather than provider-side

### Extra context
There is also a stale config warning on startup:
```text
plugins.entries.minimax-portal-auth: plugin not found: minimax-portal-auth (stale config entry ignored; remove it from plugins config)

I can remove that, but it does not seem to explain the long startup or long-held session lock.

#Helps with speed and Gateway connection

1) Disable Bonjour/mDNS, just as an A/B test

2) Turn off extra per-message overhead

3) Clean up unused plugins

4) Remove the stale plugin entry

1) Slow replies / startup

2) WhatsApp disconnects

A. Your reconnect policy is capped

B. Disable Bonjour on this box

Minimal low-latency config tests I’d do

What I think is most likely

What improved

What is still wrong

The most interesting new clue

Next thing I would do

My current read

My conclusion

Suggested issue title

Suggested body

My recommendation

Issue 1, WhatsApp listener instability

Issue 2, session lock / slow startup / slow replies