Summary

The Control UI / WebChat history view truncates assistant messages at 4,000 characters even though WebChat history truncation is configurable. This is too short for the WebChat use case: users often open WebChat specifically instead of a phone/chat app because they want to read larger outputs, reports, summaries, code review findings, etc.

Worse, the truncation marker is silent from the user's point of view: the visible message ends with:

...(truncated)...

and there is no continuation, expand affordance, "show full", or obvious indication that the original assistant output exists elsewhere.

Observed behavior

A long assistant reply sent to WebChat was visible in the UI only up to a short prefix and then ended with:

...(truncated)...

The user did not get the rest of the answer.

Why this is confusing

There is already a config option:

{
  "gateway": {
    "webchat": {
      "chatHistoryMaxChars": 12000
    }
  }
}

The runtime schema documents it as:

gateway.webchat.chatHistoryMaxChars
Max characters per text field in chat.history responses before truncation (default: 12000).

Validation allows up to 500,000 chars.

But the Control UI bundle appears to request a lower hardcoded per-request limit:

Xc = 100
Zc = 4e3

client.request("chat.history", {
  sessionKey: t,
  limit: Xc,
  maxChars: Zc
})

Because chat.history honors the per-request maxChars, this overrides the configurable gateway.webchat.chatHistoryMaxChars value for the normal WebChat/Control UI view.

Relevant installed files from OpenClaw 2026.5.12:

dist/chat-display-projection-*.js
const DEFAULT_CHAT_HISTORY_TEXT_MAX_CHARS = 8e3;

function truncateChatHistoryText(text, maxChars = DEFAULT_CHAT_HISTORY_TEXT_MAX_CHARS) {
  if (text.length <= maxChars) return { text, truncated: false };
  return {
    text: `${text.slice(0, maxChars)}\n...(truncated)...`,
    truncated: true
  };
}

dist/chat-*.js
maxChars: resolveEffectiveChatHistoryMaxChars(cfg, maxChars)

dist/control-ui/assets/index-*.js
client.request("chat.history", { sessionKey: t, limit: Xc, maxChars: Zc })

Expected behavior

The Control UI / WebChat should not hardcode a 4k text-field limit that bypasses the configured WebChat history limit.

Suggested fix options:

1. Prefer existing config:

   • Remove the hardcoded maxChars: 4000 from the Control UI chat.history request.
   • Let the backend use gateway.webchat.chatHistoryMaxChars.

2. Or add a more explicit config if the UI needs a separate budget:

   • gateway.webchat.controlUiHistoryMaxChars
   • default should be much higher than 4k, e.g. 12k or 20k.
   • The frontend should receive that value from the gateway snapshot / hello payload rather than embedding it in the bundled JS.

3. Best UX improvement:

   • If a message is truncated, expose an affordance to fetch/show the full message, or at least split/continue display so the user is not left with a dead ...(truncated)....

Why this matters

WebChat is commonly used as the "large screen" interface. A 4k cap makes it worse than many mobile chat apps for long answers, and the truncation is especially damaging for summaries, research reports, logs, code reviews, and step-by-step troubleshooting output.

Configurable limits should not be silently bypassed by a frontend hardcode.