Summary

When agent A sends an inter-session message to agent B via sessions_send, the message arrives in B's session tagged as channel=webchat. OpenClaw then updates B's session lastRoute to webchat. B's next reply to a Discord user is routed to the webchat UI instead of Discord, making it invisible on mobile.

Steps to reproduce

1. Agent A (e.g. Omega) has an active Discord channel session (agent:omega:discord:channel:XYZ)
2. Agent B (e.g. Swiv) has an active Discord channel session (agent:swiv:discord:channel:XYZ)
3. Agent A calls sessions_send(sessionKey: "agent:swiv:discord:channel:XYZ", message: "...")
4. Agent B processes the inter-agent message
5. Agent B replies to a user who messaged via Discord
6. B's reply appears in webchat UI only — not delivered to Discord

Expected behavior

Inter-session messages should NOT update the receiving session's lastRoute. The session's reply channel should remain pinned to wherever the last external user message came from (Discord in this case).

Actual behavior

lastRoute is overwritten to webchat on every inter-session message. All subsequent replies route to webchat until the next external Discord message resets it.

Impact

• In multi-agent fleet setups with heavy inter-agent communication, JP's Discord/mobile experience is broken repeatedly throughout the day
• Every sessions_send from another agent poisons the reply route
• Compounds with cron jobs that fire inter-agent alerts — each alert resets lastRoute to webchat
• No config workaround exists — session.dmScope: main + allowFrom pinning doesn't apply to Discord channel sessions

Suggested fix

Option A (preferred): Inter-session messages (those arriving via sessions_send) should never update lastRoute. Only external user messages from actual channels should update it.

Option B: sessions_send carries an optional preserveRoute: true flag.

Option C: Per-agent config: session.pinRoute: "discord" that locks lastRoute to a specific channel.

Workaround (current)

Using [[reply_to_current]] tag in replies forces reply to the triggering Discord message. This helps but doesn't work for standalone replies after processing inter-agent content.

Setup

• Multi-agent fleet (5 agents), all with dedicated Discord channel sessions
• Heavy inter-agent communication via sessions_send throughout the day
• OpenClaw gateway on macOS, Discord channel
• Confirmed consistent reproduction across multiple agents (Omega, Swiv, Forge)