#Bindings not routing WhatsApp groups to secondary agent after restart

1 messages · Page 1 of 1 (latest)

sinful coral
#

Bindings not routing WhatsApp groups to secondary agent after restart

Message:

Hi! I'm running OpenClaw 2026.4.15 with two agents: main and julie. I want to route specific WhatsApp group messages to julie.

Current config (openclaw.json):

{
  "bindings": [
    {
      "type": "route",
      "agentId": "julie",
      "match": {
        "channel": "whatsapp",
        "peer": { "kind": "group", "id": "120363379276115288@g.us" }
      }
    }
  ]
}

Problem: Group messages arrive at the server (visible in web-inbound logs) but are always processed by the main agent — julie never responds. No "Routing bindings" line appears in startup logs.

What I've tried:

  • Old format using accountId field — didn't work
  • Current format using peer.kind=group — still testing
  • Multiple gateway restarts — makes it worse (old sessions stay stuck on main agent)
  • Manually clearing group sessions from main agent's sessions.json

Questions:

  1. What is the correct binding format to route WhatsApp groups to a secondary agent?
  2. Is there a way to reload bindings without restarting the gateway?

Version: 2026.4.15

tribal havenBOT
#

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

lusty onyxBOT
lean widgetBOT
#

Checking the docs and source so I can give you the real schema, not a guess.

#

I checked the current docs + source.

  1. Correct binding format

Your canonical match key is match.channel, not provider. For WhatsApp groups, this is valid:

{
  "bindings": [
    {
      "agentId": "julie",
      "match": {
        "channel": "whatsapp",
        "accountId": "default",
        "peer": { "kind": "group", "id": "120363379276115288@g.us" }
      }
# 
    }
  ]
}

Notes:

  • type: "route" is optional.
  • peer.kind: "group" is correct. The router also treats group and channel as compatible, so that is not the problem.
  • Important gotcha: if you have multiple WhatsApp accounts, omitting accountId only matches the default account. If this group is arriving on another account, it will fall back to main.

So:

  • single WA account: your current shape is basically fine
  • multi-account WA: set the exact accountId, or use "*" if you really want any account
  1. Reload without restart
#

Yes, normally.

With the default config reload behavior, editing openclaw.json should be enough. bindings are not a restart-only setting.

Caveats:

  • if gateway.reload.mode is off, you need a restart
  • if gateway.reload.mode is restart, config changes will restart the gateway
  • in normal hybrid mode, bindings should apply without a manual restart

Also, the missing “Routing bindings” line in startup logs is not a reliable signal. That string comes from the CLI command openclaw agents bindings, not normal boot logs.

  1. Best next checks

Run these:

# 
openclaw agents bindings --json
openclaw gateway status

What I’d look for:

  • does agents bindings show the exact WhatsApp group rule?
  • is the gateway using the config file you edited?
  • is the inbound WhatsApp message on accountId=default or a different account?

One more useful point: old main sessions should not prevent a matching peer binding from routing to julie. Once the binding matches, new inbound should resolve to agent:julie:whatsapp:group:<id>.

Docs:

#

If you paste the output of openclaw agents bindings --json and openclaw gateway status, I can help pinpoint which part is missing.

sinful coral
#

Thanks! Here's the output:

openclaw agents bindings --json → shows all 7 bindings loaded correctly with peer.kind=group format ✅

openclaw gateway status → Runtime: running (pid 358241), RPC probe: ok, config file: ~/.openclaw/openclaw.json

So the bindings ARE loaded. The question now is: why are group messages still being processed by main instead of julie? Is there anything in the inbound routing I should check? Could it be related to accountId not being set in the match?

lean widgetBOT
#

Let me check the WhatsApp inbound path specifically, because at this point it’s probably matching on the runtime envelope, not the config file.

#

Yes, accountId is the first thing I’d check now.

I traced the WhatsApp inbound path, and the router is called with:

  • channel: "whatsapp"
  • accountId: msg.accountId
  • peer: { kind: "group", id: conversationId }

The subtle bit is: routing filters by channel + account before peer matching.

So this binding:

{
  "agentId": "julie",
  "match": {
# 
    "channel": "whatsapp",
    "peer": { "kind": "group", "id": "120363379276115288@g.us" }
  }
}

is effectively default-account only.

If that group is arriving on a non-default WhatsApp account, it will skip this binding and fall back to main.

Best quick test

Temporarily change it to:

# 
{
  "bindings": [
    {
      "agentId": "julie",
      "match": {
        "channel": "whatsapp",
        "accountId": "*",
        "peer": { "kind": "group", "id": "120363379276115288@g.us" }
      }
    }
  ]
}

If that starts routing to julie, you found it. Then replace * with the real account id.

#

If it still goes to main with accountId: "*"

Then I’d check these next:

  1. Another earlier peer binding for that same group among your 7 bindings
    Within the same match tier, first match wins.

  2. Routing debug logs
    Set logging.level: "debug" temporarily, then tail logs. You should see lines like:

  • [routing] resolveAgentRoute: channel=whatsapp accountId=... peer=group:120...@g.us ...
  • [routing] match: matchedBy=... agentId=...

That will tell you exactly whether it is missing on account, peer id, or order.

Also, you should not need to keep deleting main sessions. If routing matches julie, new inbound should use julie’s session key automatically.