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

[danpolasek]

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)

[clawsweeper]

Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Current main now preserves targetless successful message.send replies that finish with silent NO_REPLY by projecting them back into chat history, and the TUI already reloads history when a local run ends without a displayable final message. This addresses the reported v2026.5.20 silent TUI path without undoing message-tool-only duplicate-send suppression.

I found the merged PR that appears to have closed this: #84268: [codex] Fix chat history for message-tool replies.

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review details

Best possible solution:

Close this as fixed on main and let any broader live-final or route-boundary polish continue in its own PR if maintainers still want it.

Do we have a high-confidence way to reproduce the issue?

Yes for the affected release path by source inspection: message-tool-only turns could finish without buffered assistant text, and current main now has the mirror plus TUI history-refresh path that removes the same silent-output condition.

Is this the best way to solve the issue?

Yes: preserving the message-tool reply through chat history keeps duplicate external delivery suppression intact while making the local TUI display the reply after an empty final.

Security review:

Security review: This is a non-security issue review; no PR diff is being merged in this decision.

What I checked:

• Current source mirrors message-tool visible replies: mirrorMessageToolVisibleReplies records pending message tool sends, marks matching successful tool results, and flushes a normal assistant mirror when the assistant completes with a silent control reply. (src/gateway/chat-display-projection.ts:771, 743caedb052a)
• Current TUI refreshes history for empty local finals: When a local TUI run finalizes with no message, the handler calls maybeRefreshHistoryForRun(... allowLocalWithoutDisplayableFinal: true) before dropping the placeholder, so the projected history mirror can be displayed. (src/tui/tui-event-handlers.ts:439, 743caedb052a)
• Regression coverage for the fixed history path: Gateway history tests assert that a current-session message tool send followed by NO_REPLY projects the reply text, while explicitly routed sends and dry-runs are not mirrored. (src/gateway/server.chat.gateway-server-chat.test.ts:698, 743caedb052a)
• Regression coverage for live history append state: Session history state tests assert that an inline tool call, matching tool result, and silent NO_REPLY append emit a message-tool mirror for live history consumers. (src/gateway/session-history-state.test.ts:105, 743caedb052a)
• Fix provenance: Commit 87b2046575700e411f258fd95201cd53d5e9df10 changed chat-display-projection, session-history-state, and gateway chat tests with the subject fix(gateway): preserve message-tool replies in chat history. (src/gateway/chat-display-projection.ts:771, 87b204657570)
• Merged PR provenance: GitHub reports [codex] Fix chat history for message-tool replies #84268 merged at 2026-05-22T17:18:19Z with merge commit 87b2046575700e411f258fd95201cd53d5e9df10. (87b204657570)

Likely related people:

• 100yenadmin: Authored the merged chat-history projection fix that preserves message-tool replies in current main. (role: recent fix author; confidence: high; commits: 87b204657570; files: src/gateway/chat-display-projection.ts, src/gateway/session-history-state.ts, src/gateway/server.chat.gateway-server-chat.test.ts)
• steipete: Recent path history and PR discussion show Peter Steinberger hardening gateway/session-history behavior and posting maintainer proof for the merged fix. (role: recent area contributor and merger/proof owner; confidence: high; commits: d9c6c5f600ca, 4f4d10863916; files: src/gateway/chat-display-projection.ts, src/gateway/session-history-state.ts)
• RomneyDa: Recently maintained the TUI event handler path that performs the empty-final history refresh used by this fix. (role: recent TUI handler contributor; confidence: medium; commits: b741ddb66f5e, 5f373ae4d3db; files: src/tui/tui-event-handlers.ts)
• zhangguiping-xydt: Recent current-main history touched message-tool send normalization next to the internal source-reply result path. (role: adjacent message-tool contributor; confidence: low; commits: 63545693a0fa; files: src/infra/outbound/message-action-runner.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 743caedb052a; fix evidence: merged PR #84268, commit 87b204657570, main fix timestamp 2026-05-22T17:18:18Z.