openclaw - 💡(How to fix) Fix [UX] WebChat: add a full-message reader for truncated or long messages [1 pull requests]

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…

WebChat should give users an explicit way to read the full content of long or truncated assistant/tool messages without expanding huge text directly in the main chat thread.

Right now long history messages can arrive with ...(truncated)..., and the existing side-panel affordance opens the already-loaded markdown. If the loaded message is truncated, the side panel is truncated too, so it is not a real escape hatch.

Root Cause

  • Only raise maxChars / fix #53242: necessary but incomplete. It reduces premature backend truncation, but long messages can still overwhelm the main thread and still need a comfortable reader.
  • Expand the full message inline: poor default UX for reports, logs, and large tool outputs; it makes the chat harder to scan and can hurt render performance.
  • Store full hidden text in the DOM: avoids an extra fetch but keeps large payloads in memory and defeats the purpose of history projection.
  • Keep truncation as-is: lowest implementation cost, but it is experienced as message loss because users have no path to the missing content.
  • On-demand full-message sidebar: best fit. It preserves the fast bounded chat view while letting users intentionally inspect the full content.

Fix Action

Fixed

RAW_BUFFERClick to expand / collapse

Summary

WebChat should give users an explicit way to read the full content of long or truncated assistant/tool messages without expanding huge text directly in the main chat thread.

Right now long history messages can arrive with ...(truncated)..., and the existing side-panel affordance opens the already-loaded markdown. If the loaded message is truncated, the side panel is truncated too, so it is not a real escape hatch.

Current release behavior

Observed against the v2026.5.19-beta.2 release tree:

  • ui/src/ui/controllers/chat.ts requests chat.history with maxChars: 4_000.
  • src/gateway/chat-display-projection.ts defaults DEFAULT_CHAT_HISTORY_TEXT_MAX_CHARS to 8,000 and inserts ...(truncated)... when text exceeds the projection cap.
  • ui/src/ui/chat/grouped-render.ts renders an assistant-only side-panel button, but it passes the current markdown string directly to the sidebar. If that string was truncated by history projection, the sidebar only shows truncated content.
  • Tool details can open in the side panel, but they also use the currently loaded outputText, which may already be capped by live tool-output limits or history projection after refresh.

Relevant source paths:

  • ui/src/ui/controllers/chat.ts
  • ui/src/ui/chat/grouped-render.ts
  • ui/src/ui/chat/tool-cards.ts
  • ui/src/ui/views/markdown-sidebar.ts
  • src/gateway/chat-display-projection.ts
  • src/gateway/sessions-history-http.ts

Recommended path

Keep the main chat lightweight, but make truncation actionable.

Suggested design:

  1. Detect messages that are long or explicitly truncated.
    • Short term: detect the ...(truncated)... sentinel.
    • Better contract: have history projection attach explicit truncation metadata to the message/content block.
  2. Render a clear Open full message / side-panel button for assistant messages and tool outputs when content is long or truncated.
  3. If the full text is already in client state, open it directly in the sidebar.
  4. If the current message is truncated, fetch the full content on demand by stable session/message identity.
    • This likely needs a small gateway method or HTTP route keyed by sessionKey plus transcript seq/message id, with a high but bounded maxChars.
    • Alternatively, extend /sessions/:sessionKey/history with enough query support to fetch the target message/page at a larger cap.
  5. The sidebar should support rendered markdown plus raw text/code view, copy, and an honest unavailable state if the server cannot return more due to byte caps or missing transcript metadata.
  6. Tool outputs should get the same treatment: compact preview in the main thread, full detail on demand.

Adversarial analysis

  • Only raise maxChars / fix #53242: necessary but incomplete. It reduces premature backend truncation, but long messages can still overwhelm the main thread and still need a comfortable reader.
  • Expand the full message inline: poor default UX for reports, logs, and large tool outputs; it makes the chat harder to scan and can hurt render performance.
  • Store full hidden text in the DOM: avoids an extra fetch but keeps large payloads in memory and defeats the purpose of history projection.
  • Keep truncation as-is: lowest implementation cost, but it is experienced as message loss because users have no path to the missing content.
  • On-demand full-message sidebar: best fit. It preserves the fast bounded chat view while letting users intentionally inspect the full content.

Acceptance criteria

  • A truncated assistant message shows an obvious affordance to open the full content.
  • The side panel does not merely repeat the truncated preview when the server can return more content.
  • Tool outputs can be opened in the same full-detail flow.
  • The default chat history payload size does not increase substantially just to support occasional long-message reads.
  • If full content cannot be returned, the UI explains why instead of silently showing the truncated text.
  • Focused tests cover truncated-message detection, sidebar opening, and the gateway full-message fetch contract or equivalent.

Related issues

  • #53242 tracks premature chat.history truncation and the current Control UI maxChars: 4_000 impact.
  • #47386 tracks reducing tool-output visual noise with collapsible summaries.
  • #82246 tracks configurable tool progress/transcript truncation limits.
  • #82121 tracks leaked truncation sentinels in final replies.
  • #12208 is a related native/mobile large-bubble scrolling request, but this issue is specifically for WebChat/Control UI.

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…

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 [UX] WebChat: add a full-message reader for truncated or long messages [1 pull requests]