openclaw - 💡(How to fix) Fix Bug: Control UI/WebChat hardcodes chat.history maxChars=4000, bypassing configurable webchat history limit [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…

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.

Error Message

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

Root Cause

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.

Fix Action

Fixed

Code Example

...(truncated)...

---

...(truncated)...

---

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

---

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

---

Xc = 100
Zc = 4e3

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

---

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 })
RAW_BUFFERClick to expand / collapse

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.

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

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)....

Still need to ship something?

×6

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

Back to top recommendations

TRENDING