openclaw - 💡(How to fix) Fix [Bug]: Web chat live response unconditionally truncated at ~4,000 chars

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Long assistant responses in the WebChat/Control UI are truncated at approximately 4,000 characters during live streaming. The model generates the full response, but the reply/chunking layer slices it before it reaches the frontend. There is no configuration option to override this limit for webchat — the code explicitly bypasses provider-specific config resolution for webchat, always falling back to a hardcoded DEFAULT_CHUNK_LIMIT = 4e3.

Steps to reproduce

1. Send a prompt that produces a long assistant response (>4000 characters), e.g., "Tell me about your web surfing activity from last night"
2. Observe in the Control UI: the response streams fully, then stops at ~4000 characters with ...(truncated)... appended

The rest of the response is silently lost — no indication that more content exists

Expected behavior

The full response should render in WebChat, or if a limit is necessary, it should be configurable via textChunkLimit (like other channels) or a webchat-specific override. At minimum, there should be an option to fetch and display the remainder. What I'm doing now is asking OC to create an HTML file copy of the response that I then view in my web browser - not a pleasant workaround.

Actual behavior

Response is truncated at ~4000 characters with no effective configuration option to increase the limit.

OpenClaw version

2026.5.12

Operating system

Ubuntu 24.04

Install method

npm global

Model

Qwen3.6-35B-A3B

Provider / routing chain

openclaw -> llama.cpp openai-completions API

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Inability to see response text past 4K characters in web chat.

Additional information

The truncation occurs in the reply/chunking layer (chunk-CGVwhsnj.js), not in the model output or the frontend:

const DEFAULT_CHUNK_LIMIT = 4e3;
const DEFAULT_CHUNK_MODE = "length";

function resolveTextChunkLimit(cfg, provider, accountId, opts) {
    const fallback = ...opts?.fallbackLimit... : DEFAULT_CHUNK_LIMIT; // 4000
    const providerOverride = (() => {
        if (!provider || provider === "webchat") return; // ← hardcoded bypass
        return resolveChunkLimitForProvider((cfg?.channels)?.[provider] ?? cfg?.[provider], accountId);
    })();
    if (typeof providerOverride === "number" && providerOverride > 0) return providerOverride;
    return fallback; // always 4000 for webchat
}

function resolveChunkMode(cfg, provider, accountId) {
    if (!provider || provider === "webchat") return DEFAULT_CHUNK_MODE; // same bypass
    return resolveChunkModeForProvider(...) ?? DEFAULT_CHUNK_MODE;
}

Two functions (resolveTextChunkLimit and resolveChunkMode) explicitly check provider === "webchat" and return early, bypassing any config lookup. This means:

Setting channels.webchat.textChunkLimit in config has no effect The fallbackLimit parameter passed by callers (always 4e3 across all channel implementations) is the effective cap No configuration path exists to change this for webchat.

Why Other Channels Work Every other channel passes its own fallbackLimit value:

Telegram: 4e3 (Telegram API limit, appropriate) Discord: DISCORD_TEXT_CHUNK_LIMIT (configurable per account) Signal: 4e3 (Signal API limit, appropriate) Slack: SLACK_TEXT_LIMIT (Slack API limit, appropriate) Mattermost: account.textChunkLimit ?? 4e3 (respects config) Webchat has no upstream API constraint — it's a local browser UI. The 4000-char default is arbitrary and too low for the use case.

Proposed fix:

Remove the webchat bypass in both functions so webchat falls through to config resolution like other channels:

// In resolveTextChunkLimit (~line 42):
if (!provider || provider === "webchat") return;
// → Remove `|| provider === "webchat"` so webchat goes through config lookup

// In resolveChunkMode (~line 59):
if (!provider || provider === "webchat") return DEFAULT_CHUNK_MODE;
// → Same treatment, or set a higher default for webchat

Then either:

1. Let the existing channels.webchat.textChunkLimit config work (minimal change), or
2. Increase the fallback default for webchat specifically (e.g., 16000+) since there's no upstream API constraint

Related Issues #83151 — Closed, but about chat history view truncation (separate code path: chat-display-projection.ts and Control UI frontend request) PR #53243 — Open, attempting to fix chat.history caps; not relevant to live response chunking