Environment

• OpenClaw version: 2026.5.20 (e510042)
• OS: Linux (Ubuntu, x86_64)
• Node: v22.x
• Channel: Signal (primary) + TUI (openclaw tui) for local operator use
• Agent model: openai/gpt-5.4-mini

What happened

After upgrading to 2026.5.20, the TUI (openclaw tui) stopped displaying agent responses entirely. The agent responds correctly via Signal and responses are visible in the Gateway dashboard (webchat), but the TUI terminal shows nothing.

Root cause (traced from session log)

The agent's system prompt instructs it to always deliver replies via the message tool — this is required for Signal delivery. When a TUI session fires, the gateway correctly identifies the session as webchat-origin but still sets:

{
  "channel": "webchat",
  "sourceReplyDeliveryMode": "message_tool_only",
  "sourceReplySink": "internal-ui"
}

The agent calls message({action:"send", message:"..."}) → tool succeeds → turn ends (per fix #84289) → TUI receives nothing.

Why this is a regression from 2026.5.18

In 2026.5.18, after a successful message.send, the agent turn continued and generated trailing text. That trailing text was still visible in the TUI terminal even though the message_tool_only mode was active. It wasn't clean, but TUI was usable.

Fix #84289 ("stop message-tool-only turns after a successful source-channel message send") was the right fix for Signal/WhatsApp to prevent duplicate sends — but it also eliminated the only visible output path for TUI in this setup.

Why the agent can't adapt

The agent has no way to detect TUI vs Signal at runtime. Both sessions appear as channel: webchat in the tool result. The message tool is unconditionally required for Signal, so removing it from the system prompt would break Signal delivery.

Impact

Any setup where:

1. Agent is configured with Signal (or another channel that requires message.send)
2. Operator also uses openclaw tui locally for the same agent/session

→ TUI is completely silent after 2026.5.20.

Expected behavior

TUI should display the content sent via message.send when the session origin is webchat/TUI, even in message_tool_only mode. The simplest fix would be to mirror the message.send payload back to the TUI stream when sourceReplySink is internal-ui, rather than silencing it.

Workaround

None found. Rollback to 2026.5.18 restores TUI visibility (at the cost of the cleaner turn-stop behavior).

Related issues

• Bug: TUI messages routed as 'webchat' instead of 'tui' - replies not delivered to TUI in real-time #36431 — TUI routed as webchat (closed as not planned — accepted limitation, but this regression makes it load-bearing)
• WhatsApp replies show in WhatsApp but display NO_REPLY in TUI/Web when AI uses message tool #7010 — NO_REPLY in TUI/Web when agent uses message tool (closed)
• [Bug]: TUI doesn't display assistant replies, but webchat works fine #37647 — TUI doesn't display assistant replies (closed)