Summary

When TUI (gateway-client) and WhatsApp are both connected to the same agent:main session, replies to TUI-originated messages are also sent to WhatsApp. The expected behavior is that replies should only go to the channel that originated the message, with TUI as the exception (it should always see everything as the control surface).

Steps to reproduce

1. Configure WhatsApp channel with dmPolicy: "allowlist"
2. Connect TUI (openclaw tui) — both share the agent:main session
3. Send a message from TUI
4. Observe the reply appears on both TUI and WhatsApp

Expected behavior

• TUI: always sees all messages and replies (it is the session monitor / control surface)
• WhatsApp: only receives replies when the inbound message originated from WhatsApp
• This is how it worked on prior versions (2026.2.x)

Actual behavior

Replies fan out to all connected surfaces of the main session regardless of which surface originated the message. TUI messages get echoed to WhatsApp unnecessarily.

Precedent

The macOS voice wake routing change (#25440) established this pattern: voice-wake transcripts were pinned to webchat instead of ambiguous last routing. The same origin-pinning logic should apply to TUI vs channel surfaces.

Environment

• OpenClaw version: 2026.3.2
• OS: Ubuntu 24.04 (Docker container)
• Install method: npm (global)
• Channels configured: WhatsApp + TUI (gateway-client)
• Session config: default (dmScope: "main")

Notes

• This may be a regression from 2026.2.x → 2026.3.x
• Related (but different): [Bug]: Multi-channel response routing leaks to wrong channel when messages arrive simultaneously #4530 was about cross-channel routing between different contacts; this is about the same user on multiple surfaces
• session.dmScope: "per-channel-peer" would work around this but breaks the shared session continuity that makes TUI useful as a control surface