Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Webchat: internal runtime tokens (NO_REPLY, cron status lines) flicker visibly before sanitization [1 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#75643•Fetched 2026-05-02 05:32:23
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
2
Author
typosiron-pngtyposiron-png
Participants
clawsweeper[bot]clawsweeper[bot]typosiron-pngtyposiron-png
Timeline (top)
closed ×1commented ×1

In webchat (control-ui) sessions, internal runtime tokens stream into the rendered conversation as they arrive, then get stripped at end-of-message by the normalizer. Result: brief but visible flicker of internal text that shouldn't be user-facing at all.

Two related leaks observed:

Root Cause

In webchat (control-ui) sessions, internal runtime tokens stream into the rendered conversation as they arrive, then get stripped at end-of-message by the normalizer. Result: brief but visible flicker of internal text that shouldn't be user-facing at all.

Two related leaks observed:

Fix Action

Workaround

Agents avoid emitting NO_REPLY when the outbound surface is webchat. Cron meta-lines have no easy agent-side mitigation.

RAW_BUFFERClick to expand / collapse

Webchat: internal runtime tokens (NO_REPLY, cron status lines) flicker visibly before sanitization

Summary

In webchat (control-ui) sessions, internal runtime tokens stream into the rendered conversation as they arrive, then get stripped at end-of-message by the normalizer. Result: brief but visible flicker of internal text that shouldn't be user-facing at all.

Two related leaks observed:

Leak 1 — Silent reply token (NO_REPLY)

normalizeReplyPayload (dist/normalize-reply-Ya8zMI2I.js) correctly detects the silent-reply token and emits a silent skip / empty payload — but only at end-of-message. Webchat streams characters as they arrive, so the user sees N → NO → NO_ → NO_REPLY flash and disappear.

Repro:

  1. Webchat direct session.
  2. Trigger a flow where the agent replies with exactly NO_REPLY (cron heartbeat poll, fallback-override-check, inter-session relay, etc.).
  3. Observe a 'N' (or partial token) flashing then vanishing in the conversation pane.

Leak 2 — Cron / runtime status lines

When agent-to-agent or cron messages route to a webchat-attached session, internal status strings such as Agent-to-agent announce step. arrive as standalone messages and render in the conversation as if they were assistant turns. The user can't tell whether they're addressed to them or are internal metadata.

Repro:

  1. Configure a cron that emits multi-step output (e.g. handoff-notifier with delivery: announce + telegram) but where the receiving session is webchat-attached.
  2. Observe a meta-line like Agent-to-agent announce step. rendered to the user.

Expected

Internal tokens / runtime status lines never paint to user-facing surfaces. Either:

  • Renderer buffers leading chars (≥ max silent-token length) before flushing, OR
  • Stream pipeline detects silent / status tokens at chunk boundaries and short-circuits before paint, OR
  • Pre-stream check on the whole message replaces stream with empty/skip, OR
  • Cron status lines are emitted on a separate metadata channel (not the user transcript stream).

Actual

Tokens stream char-by-char and paint, then get erased on finalize. Cron meta-lines paint as full assistant turns.

Affected

  • Webchat (control-ui) direct sessions
  • Likely any other surface that renders pre-finalize stream chunks
  • Particularly visible when crons + inter-session messages funnel through a webchat-attached main session

Workaround

Agents avoid emitting NO_REPLY when the outbound surface is webchat. Cron meta-lines have no easy agent-side mitigation.

Env

  • OpenClaw 2026.4.26 (build 2026042690)
  • Node v22.22.2, Darwin 25.4.0 arm64
  • Channel: webchat

extent analysis

TL;DR

Implement a buffering mechanism to delay rendering of messages in the webchat conversation until the full message is received and sanitized.

Guidance

  • Identify the maximum length of silent tokens (e.g., NO_REPLY) to determine the minimum buffer size required to prevent flickering.
  • Modify the normalizeReplyPayload function to buffer incoming characters until a complete message is received or a timeout occurs, ensuring that internal tokens are not rendered to the user.
  • Consider implementing a separate metadata channel for cron status lines to prevent them from being rendered as user-facing messages.
  • Review the webchat rendering pipeline to determine if there are any existing mechanisms that can be leveraged to delay rendering of messages until they are fully sanitized.

Example

// Pseudocode example of buffering mechanism
const buffer = '';
const maxTokenLength = 'NO_REPLY'.length;

// On each character received
function onCharReceived(char) {
  buffer += char;
  if (buffer.length >= maxTokenLength) {
    // Sanitize and render the buffered message
    const sanitizedMessage = sanitizeMessage(buffer);
    renderMessage(sanitizedMessage);
    buffer = '';
  }
}

Notes

The proposed solution assumes that the webchat conversation rendering is done in a way that allows for buffering and sanitization of incoming messages. Additional modifications may be required to integrate this solution with the existing rendering pipeline.

Recommendation

Apply a workaround by implementing a buffering mechanism to delay rendering of messages until they are fully sanitized, as this approach can be implemented without requiring significant changes to the underlying infrastructure.

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…
#API rate limit#retriever error#indexing error#inference speed#output truncation

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 Webchat: internal runtime tokens (NO_REPLY, cron status lines) flicker visibly before sanitization [1 comments, 2 participants]