Fixes #6602

Problem

When bindings are added or changed in openclaw.json while the gateway is running, the config watcher detects the change and logs "config change applied (dynamic reads: bindings)" — but messages continue routing to the old/default agent until the gateway is fully restarted.

This affects all channels (WhatsApp, Telegram, Discord) that use multi-agent routing via bindings.

Related issues: #9351 (Telegram accountId routing — different root cause but same file touched), #9198 (Google Chat DM routing — likely same stale-config pattern but extension channel not covered here)

Root Cause (3 layers)

config-reload.ts classifies bindings as kind: "none", meaning "this section is dynamically read per-request, no reload action needed." That assumption would be correct if channel monitors re-read config per-message — but they don't. They call loadConfig() once at startup and capture it in a closure.

Layer 1 — Incorrect assumption: config-reload.ts:72 — { prefix: "bindings", kind: "none" } assumes bindings are read dynamically. They aren't.

Layer 2 — Config captured once at startup:

Layer 3 — Routing uses stale snapshot: resolveAgentRoute({ cfg: params.cfg, ... }) in each channel's message handler uses the startup-time config, never seeing new bindings.

Fix

loadConfig() in config/io.ts already has a 200ms TTL cache (DEFAULT_CONFIG_CACHE_MS = 200). It was designed for per-request dynamic reads with minimal disk I/O.

This PR changes the resolveAgentRoute() call in each channel to use loadConfig() instead of the captured startup config:

// Before:
const route = resolveAgentRoute({ cfg: params.cfg, channel: "whatsapp", ... });

// After:
// Fresh config for bindings lookup; other routing inputs are payload-derived.
const route = resolveAgentRoute({ cfg: loadConfig(), channel: "whatsapp", ... });

After this change, the kind: "none" classification for bindings becomes correct — routing truly reads config dynamically now.

Files Changed

Mixed-config-source tradeoff

After this change, handler functions still receive cfg via params for non-routing purposes (channel config, media limits, mention patterns). Only resolveAgentRoute() reads fresh config. Each call site is annotated with an inline comment explaining this is intentional:

// Fresh config for bindings lookup; other routing inputs are payload-derived.
const route = resolveAgentRoute({ cfg: loadConfig(), ... });

The other routing inputs (account ID, chat type, peer ID) come from the message payload, not config. A broader "fresh config everywhere" refactor could follow separately if runtime changes to non-binding config become a real requirement.

Why this is safe

• Performance: 200ms cache means at most 5 disk reads/second. JSON5 parse is <1ms for typical configs.
• Thread safety: Node.js is single-threaded; loadConfig() reads synchronously.
• Corrupted config: loadConfig() returns last cached valid config on parse failure.
• 200ms staleness: After writing a new binding, routing may use old bindings for up to 200ms. This is acceptable — the alternative (gateway restart) causes 2-5s of downtime.
• Backward compatible: No new APIs, no config changes required.

Test plan

• pnpm lint — 0 warnings, 0 errors
• pnpm build — clean
• pnpm test — 961 test files, 6510 tests passed, 0 failures
• Manual: start gateway, add binding at runtime, verify routing picks it up without restart

AI Disclosure

This PR was prepared with assistance from Claude Opus 4.6. The bug analysis, code tracing, and fix were developed collaboratively. I understand the code and the fix. Lightly tested (automated tests pass; manual runtime testing not yet performed).

Greptile Overview

Greptile Summary

This PR fixes stale multi-agent routing by switching channel message handlers (web/WhatsApp, Telegram, Discord) to call loadConfig() at the resolveAgentRoute() call site instead of using the startup-time config snapshot. The change leverages the existing TTL cache in loadConfig() so updated bindings in openclaw.json take effect without restarting the gateway, while leaving other handler logic on the originally provided cfg.

It also updates a Discord monitor test to mock loadConfig() so binding-based routing can be exercised under the new behavior.

Confidence Score: 4/5

• This PR is likely safe to merge after addressing one test robustness issue around the new loadConfig() behavior.
• The production changes are narrowly scoped (only routing config source changes, leveraging existing cached loadConfig()), but the updated Discord test introduces a default loadConfigMock value of {} that can make config-dependent behavior inconsistent unless each test explicitly sets the mock return to the intended config.
• src/discord/monitor.tool-result.accepts-guild-messages-mentionpatterns-match.test.ts