openclaw - 💡(How to fix) Fix [Regression 2026.5.20] TUI responses invisible for agents configured with Signal (message-tool-only turns now silenced by #84289)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Root cause (traced from session log)

Fix Action

Workaround

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

Code Example

{
  "channel": "webchat",
  "sourceReplyDeliveryMode": "message_tool_only",
  "sourceReplySink": "internal-ui"
}
RAW_BUFFERClick to expand / collapse

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

  • #36431 — TUI routed as webchat (closed as not planned — accepted limitation, but this regression makes it load-bearing)
  • #7010 — NO_REPLY in TUI/Web when agent uses message tool (closed)
  • #37647 — TUI doesn't display assistant replies (closed)

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Regression 2026.5.20] TUI responses invisible for agents configured with Signal (message-tool-only turns now silenced by #84289)