#Windows 10 Crash Loop on 2026.4.26: CIAO PROBING CANCELLED & Port 18789 Deadlock
1 messages · Page 1 of 1 (latest)
- Environment
OS: Windows 10.0.26200 (x64)
Node Version: 24.14.0
OpenClaw Version: 2026.4.26 (build be8c246)
Location: Petaling Jaya, Malaysia (DNS/Network context).
- The Primary Crash (The "Bonjour" Loop)
The gateway crashes consistently about 20–30 seconds after startup.
Error: [openclaw] Unhandled promise rejection: CIAO PROBING CANCELLED
Context: The bonjour plugin gets stuck in a "probing" state for ~22,000ms before triggering the unhandled rejection and writing a stability bundle.
- The Configuration Wall
Attempting to disable Bonjour via the config results in a validation error:
Command: openclaw config set plugins.bonjour.enabled false
Error: Config validation failed: plugins: Unrecognized key: "bonjour"
Observation: It seems the schema in .26 has changed or moved the plugin keys.
- Current State: The "Ghost" Gateway
Because of the crashes, the system is now in a deadlock:
Port Conflict: Port 18789 is frequently hogged by "zombie" Node processes (e.g., PID 57384), preventing clean restarts.
Gateway Status: Returns unreachable (timeout) even when the service is marked as "running".
Telegram: The channel is enabled in config but does not appear in the active Channels table, and no pairing code is generated upon messaging the bot.
That signature points at Bonjour/mDNS first, and possibly a duplicate gateway on port 18789 second.
A quick sanity check: CIAO PROBING CANCELLED was explicitly fixed in 2026.4.25, and 2026.4.26 is the Apr 28 latest release, so if this is still happening on true 2026.4.26, we need logs to tell whether it’s a mixed install/stale service or a regression. (github.com)
Please paste:
openclaw --version
openclaw status --all
openclaw gateway status
netstat -ano | findstr :18789
openclaw logs --follow
Let logs --follow run until one crash, then Ctrl+C and paste the tail.
If you’re blocked and don’t need LAN/iOS auto-discovery, try this temporary workaround:
openclaw config set discovery.mdns.mode off
openclaw gateway restart
discovery.mdns.mode supports minimal | full | off, and Bonjour can also be disabled with OPENCLAW_DISABLE_BONJOUR=1. (github.com)
Also: if netstat shows two LISTENING PIDs on 18789, that matches the known Windows duplicate-gateway pattern; post the output before killing anything so we can pick the right process. (github.com)
Yep — your diagnosis is solid. Two corrections / next steps:
plugins.bonjour.enabledis not a valid config path.
Use the plugin command instead:
openclaw plugins disable bonjour
Equivalent config shape is:
{
plugins: {
entries: {
bonjour: { enabled: false }
}
}
}
Docs: https://docs.openclaw.ai/gateway/bonjour
- Clean the ghost gateway before restarting:
openclaw gateway stop
netstat -ano | findstr :18789
tasklist /FI "PID eq 57384"
If that PID is clearly the stale node.exe / OpenClaw gateway process:
taskkill /PID 57384 /F
Then:
openclaw plugins disable bonjour
openclaw gateway start
openclaw gateway status
openclaw channels status --probe
Telegram not showing is probably downstream: the gateway is crashing before channel startup/pairing, so fix the Bonjour crash + port ghost first.
If it still crashes after Bonjour is disabled, please file a GitHub issue with the stability bundle + openclaw status --all + log tail: https://github.com/openclaw/openclaw/issues. This looks like a real Windows/ciao regression path despite the 2026.4.25 fix.
Service: Scheduled Task (registered)
File logs: \tmp\openclaw\openclaw-2026-04-29.log
Command: C:\Program Files\nodejs\node.exe C:\Users\limpr\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 29/04/2026 17:20:23)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown
Port 18789 is already in use.
- pid 51920: "C:\Program Files\nodejs\node.exe" C:\Users\limpr\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
TCP 127.0.0.1:18789 0.0.0.0:0 LISTENING 51920
TCP 127.0.0.1:18789 127.0.0.1:51878 CLOSE_WAIT 51920
TCP 127.0.0.1:51878 127.0.0.1:18789 FIN_WAIT_2 24104
TCP [::1]:18789 [::]:0 LISTENING 51920
🦞 OpenClaw 2026.4.26 (be8c246) — If it works, it's automation; if it breaks, it's a "learning opportunity."
Gateway not reachable. Is it running and accessible?
this is after logs- follow
That output means the gateway process is listening, but it’s not servicing the WebSocket probe. So this isn’t just “port occupied” anymore — PID 51920 is likely wedged after bind.
Do this in order:
openclaw gateway stop
taskkill /PID 51920 /F
Then disable Bonjour using the valid path/command:
openclaw plugins disable bonjour
Verify it stuck:
openclaw config get plugins.entries.bonjour.enabled
Then start clean:
openclaw gateway start
openclaw gateway status
openclaw channels status --probe
If it still says “running” but probe times out, please paste the actual tail of this file, not just gateway status:
Get-Content \tmp\openclaw\openclaw-2026-04-29.log -Tail 120
The CLOSE_WAIT line is a big hint: something accepted a connection on 18789 but didn’t complete the protocol. Telegram won’t show/pair until the gateway is responsive, so ignore Telegram for now — first goal is getting Connectivity probe: ok.
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
🦞 OpenClaw 2026.4.26 (be8c246) — Pairing codes exist because even bots believe in consent—and good security hygiene.
|
o
Gateway not reachable: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\limpr.openclaw\openclaw.json
Bind: loopback
Possible causes:
- Gateway not yet ready to accept connections (retry after a moment)
- TLS mismatch (connecting with ws:// to a wss:// gateway, or vice versa)
- Gateway crashed or was terminated unexpectedly
Runopenclaw doctorfor diagnostics.
Gateway not reachable; showing config-only status.
Config: C:\Users\limpr.openclaw\openclaw.json
Mode: local
Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
1006 abnormal closure is progress: the CLI can reach something on 18789, but the gateway closes/dies before completing the handshake.
At this point we need the crash line. Please run:
Get-Content C:\tmp\openclaw\openclaw-2026-04-29.log -Tail 160
Also, let’s bypass the Scheduled Task once and run foreground with Bonjour force-disabled:
openclaw gateway stop
netstat -ano | findstr :18789
If a PID is still listening, kill only that PID:
taskkill /PID <PID> /F
Then:
$env:OPENCLAW_DISABLE_BONJOUR="1"
openclaw gateway --port 18789
Leave that terminal open. If it stays running, open a second terminal and run:
openclaw gateway status