Bug type

Behavior bug (incorrect output/state without crash)

Summary

When connecting to OpenClaw via Control UI (webchat), inbound messages are incorrectly tagged with channel: "imessage" instead of channel: "webchat" in the inbound metadata. This causes webchat sessions to share the same session key as iMessage sessions when using dmScope: "per-channel-peer", resulting in cross-channel message synchronization that should not occur.

This appears to be related to #25050, which describes the same issue but with WhatsApp instead of iMessage.

Steps to reproduce

1. Configure OpenClaw with iMessage channel enabled
2. Ensure session.dmScope is set to "per-channel-peer"
3. Open Control UI (webchat) dashboard
4. Send a message via webchat
5. Observe the inbound metadata context

Expected behavior

Webchat messages should have:

{
  "channel": "webchat",
  "provider": "webchat",
  "surface": "webchat",
  "chat_id": "..."
}

Session key should be: agent:main:webchat:direct:{peerId}

Actual behavior

Webchat messages incorrectly show:

{
  "channel": "imessage",
  "provider": "webchat",
  "surface": "webchat",
  "chat_id": "+86198****8586"
}

Session key becomes: agent:main:imessage:direct:+86198****8586

This causes webchat and iMessage to share the same session, resulting in:

• Messages sent from webchat appearing in iMessage
• Session history being shared between channels
• Cross-channel message synchronization that violates per-channel-peer isolation

OpenClaw version

2026.3.2

Operating system

macOS 15.7.3 (arm64)**

Install method

npm global

Logs, screenshots, and evidence

Inbound metadata shows incorrect channel:

{
  "schema": "openclaw.inbound_meta.v1",
  "chat_id": "+86198****8586",
  "account_id": "default",
  "channel": "imessage",
  "provider": "webchat",
  "surface": "webchat",
  "chat_type": "direct"
}


Note that `channel` is "imessage" but `provider` and `surface` are "webchat".

Impact and severity

Affected users/systems/channels: Users with iMessage (or other external channels) configured who use Control UI/webchat

Severity: Medium (unexpected cross-channel message synchronization)

Frequency: Always reproducible when dmScope: "per-channel-peer" is configured

Consequence:

• Webchat and iMessage sessions are incorrectly merged
• Messages sent from webchat appear in iMessage
• Session history is shared between channels
• Violates expected per-channel-peer isolation behavior

Additional information

Root Cause Analysis

Looking at the session key generation logic in session-key.js:

if (dmScope === "per-channel-peer" && peerId) {
  const channel = (params.channel ?? "").trim().toLowerCase() || "unknown";
  return `agent:${normalizeAgentId(params.agentId)}:${channel}:direct:${peerId}`;
}

When channel is incorrectly set to "imessage" for webchat messages, both webchat and iMessage generate the same session key:

• agent:main:imessage:direct:+8619829648586

Workaround

Change session.dmScope to "per-peer", which creates session keys without the channel component:

{
  "session": {
    "dmScope": "per-peer"
  }
}

This allows webchat and iMessage to share a session intentionally, but is not ideal for users who want true per-channel isolation.

Related Issues

• System prompt incorrectly sets channel=whatsapp for webchat sessions #25050 - System prompt incorrectly sets channel=whatsapp for webchat sessions (same bug, different channel)
• [Bug] Webchat stream corrupts after receiving messages via BlueBubbles channel #20942 - Webchat stream corrupts after receiving messages via BlueBubbles channel
• [Bug]: Multi-channel response routing leaks to wrong channel when messages arrive simultaneously #4530 - Multi-channel response routing leaks to wrong channel

Suggested Fix

The Control UI/webchat message router should explicitly set channel: "webchat" in the inbound metadata, rather than inheriting or defaulting to another configured channel's identifier.

Additional Context

This bug appears to occur when only one external channel (iMessage) is configured. It seems the webchat provider may be incorrectly defaulting to or inheriting the channel identifier from the configured external channel instead of using its own webchat identifier.