Summary
@kapso/openclaw-whatsapp claims the generic whatsapp: and wa: outbound target prefixes (in addition to kapso: / kapso-whatsapp:). When the plugin runs in the same OpenClaw gateway as the stock Baileys whatsapp channel — a common multi-agent setup where one agent is on Kapso Cloud API and another stays on the Baileys whatsapp channel — the kapso channel hijacks all WhatsApp outbound, including replies whose inbound arrived on the Baileys whatsapp channel.
There is no config option to scope which prefixes the channel owns, so the two channels cannot coexist in one process.
Environment
@kapso/openclaw-whatsapp 0.1.4- OpenClaw 2026.6.10
- One gateway process, multiple agents. Agent A →
kapso-whatsapp (Cloud API number). Agent B (main) → stock whatsapp (Baileys) number. Bindings route inbound per channel/account correctly.
Observed behavior
After enabling kapso-whatsapp:
- A customer messages Agent B's Baileys number. Inbound routes correctly to Agent B (session
agent:main:whatsapp:direct:...), and the Baileys line even shows "typing…".
- But Agent B's reply is sent through Kapso (Agent A's Cloud API number) instead of back over Baileys. The customer receives the answer from the wrong number/identity.
- Replies to recipients who have no open 24-hour window on the Kapso number then fail with Meta error 131047 ("re-engagement / non-template outside 24h window") and pile up in the outbound queue.
Net effect: enabling the plugin silently breaks outbound for every other WhatsApp agent in the same gateway.
Root cause
dist/constants.js → TARGET_PREFIXES includes "whatsapp:" and "wa:" alongside "kapso:" / "kapso-whatsapp:", and dist/channel.js registers the channel with targetPrefixes: TARGET_PREFIXES. So the kapso channel claims the generic WhatsApp outbound namespace and wins resolution over the Baileys whatsapp channel.
We checked openclaw.plugin.json (configSchema / channelConfigs.kapso-whatsapp.schema) — there is no option to restrict the claimed prefixes.
Request
Add a config flag so the plugin can be scoped to own only kapso: / kapso-whatsapp: and leave whatsapp: / wa: to the stock Baileys channel — e.g.:
(or an explicit targetPrefixes array). With that, a Kapso Cloud API agent and a Baileys whatsapp agent could coexist in one multi-agent gateway, which is the intended topology for teams running several agents on one OpenClaw instance.
Related (can split into a separate issue if preferred)
The webhook is processed synchronously — the agent turn (LLM call) runs inside the webhook request. With Kapso's fixed 10s webhook timeout, real LLM turns routinely exceed it → response_body: "execution expired" → retries/duplicates, and risk of the 85%/15min auto-pause taking the channel offline. Kapso's own docs recommend "return 200 within 10s, process asynchronously." Consider an async ACK (return 200/202 immediately, enqueue the turn) + idempotency by wamid in the plugin.
Happy to provide logs/config (scrubbed) on request.
Summary
@kapso/openclaw-whatsappclaims the genericwhatsapp:andwa:outbound target prefixes (in addition tokapso:/kapso-whatsapp:). When the plugin runs in the same OpenClaw gateway as the stock Baileyswhatsappchannel — a common multi-agent setup where one agent is on Kapso Cloud API and another stays on the Baileyswhatsappchannel — the kapso channel hijacks all WhatsApp outbound, including replies whose inbound arrived on the Baileyswhatsappchannel.There is no config option to scope which prefixes the channel owns, so the two channels cannot coexist in one process.
Environment
@kapso/openclaw-whatsapp0.1.4kapso-whatsapp(Cloud API number). Agent B (main) → stockwhatsapp(Baileys) number. Bindings route inbound per channel/account correctly.Observed behavior
After enabling
kapso-whatsapp:agent:main:whatsapp:direct:...), and the Baileys line even shows "typing…".Net effect: enabling the plugin silently breaks outbound for every other WhatsApp agent in the same gateway.
Root cause
dist/constants.js→TARGET_PREFIXESincludes"whatsapp:"and"wa:"alongside"kapso:"/"kapso-whatsapp:", anddist/channel.jsregisters the channel withtargetPrefixes: TARGET_PREFIXES. So the kapso channel claims the generic WhatsApp outbound namespace and wins resolution over the Baileyswhatsappchannel.We checked
openclaw.plugin.json(configSchema/channelConfigs.kapso-whatsapp.schema) — there is no option to restrict the claimed prefixes.Request
Add a config flag so the plugin can be scoped to own only
kapso:/kapso-whatsapp:and leavewhatsapp:/wa:to the stock Baileys channel — e.g.:(or an explicit
targetPrefixesarray). With that, a Kapso Cloud API agent and a Baileyswhatsappagent could coexist in one multi-agent gateway, which is the intended topology for teams running several agents on one OpenClaw instance.Related (can split into a separate issue if preferred)
The webhook is processed synchronously — the agent turn (LLM call) runs inside the webhook request. With Kapso's fixed 10s webhook timeout, real LLM turns routinely exceed it →
response_body: "execution expired"→ retries/duplicates, and risk of the 85%/15min auto-pause taking the channel offline. Kapso's own docs recommend "return 200 within 10s, process asynchronously." Consider an async ACK (return 200/202 immediately, enqueue the turn) + idempotency bywamidin the plugin.Happy to provide logs/config (scrubbed) on request.