Title

[Bug] v2026.4.8 — Bonjour/mDNS service-advertise sidecar pegs 99% CPU in headless Docker (no --network=host), eventually triggers container exit

Body

Summary

Running ghcr.io/openclaw/openclaw:2026.4.8 in a standard Docker container (default bridge network, no --network=host) results in a child openclaw process consuming 99% CPU continuously, attributable to the bonjour/mDNS service-advertise watchdog being unable to successfully announce on the network. After 9–18 minutes the container exits.

OPENCLAW_DISABLE_BONJOUR=1 (discovered by string-grepping /app/dist/) is an effective workaround.

Environment

• Image: ghcr.io/openclaw/openclaw:2026.4.8 (digest sha256:cfd0d7fbd222bf570f9b19293b70d161b046da05a25651c2bef6146935fb9209)
• Host: Linux VPS (Contabo), Docker default bridge network
• Run command: docker run -d --name openclaw-test -p 28789:18789 -v <state>:/home/node/.openclaw ghcr.io/openclaw/openclaw:2026.4.8
• All channels disabled in mounted openclaw.json (whatsapp, telegram, discord)

Reproduction steps

1. Pull ghcr.io/openclaw/openclaw:2026.4.8
2. Boot a container (default bridge network, port-publish 28789:18789, no --network=host)
3. Wait 60s — gateway becomes ready
4. docker top <container> — observe a child openclaw process at constant 99% CPU
5. docker logs <container> — observe repeated bonjour watchdog re-advertise loop
6. After ~9–18 minutes, container exits silently

Symptoms

Process tree (docker top)

PID  PPID  C    CMD
1    0     0    openclaw
15   1     19   openclaw-gateway
104  1     99   openclaw                 ← 99% CPU runaway, no subcommand suffix

Log signature

[bonjour] watchdog detected non-announced service; attempting re-advertise
(gateway fqdn=<container-id> (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
[bonjour] restarting advertiser (service stuck in announcing for 12103ms ...)

These messages repeat indefinitely.

Side effect: CLI subprocess starvation

With bonjour pegging one CPU core, subsequent docker exec invocations of openclaw cron list / openclaw message --help / openclaw channels list enter their own busy-wait loops and never produce output (likely separate issue, see companion report).

Workaround

Set OPENCLAW_DISABLE_BONJOUR=1 in the container environment:

docker run -d \
  -e OPENCLAW_DISABLE_BONJOUR=1 \
  -p 28789:18789 \
  -v <state>:/home/node/.openclaw \
  ghcr.io/openclaw/openclaw:2026.4.8

Confirmed: with this set, the runaway 99% CPU process disappears and the bonjour log spam stops. The env var is referenced inside /app/dist/ but is not documented anywhere I could find.

Suggested fixes

1. Document OPENCLAW_DISABLE_BONJOUR=1 in the gateway environment variables reference
2. Auto-disable bonjour when running headless in a container — detect via cgroup//proc/1/cgroup or fall back to disabling after N consecutive failed announce attempts instead of looping forever
3. Bound the bonjour retry loop with exponential backoff so even when it fails it doesn't peg CPU
4. Default to bonjour: false in containerized images — service discovery via mDNS isn't useful when the container's network namespace is isolated

Impact

This is the root cause of the "container exits after 9–18 min" mystery I was hitting while testing v4.8 in disposable containers. It also makes v4.8 unsuitable for CI/test pipelines that run the gateway in standard Docker without host networking.