fix(webchat): suppress NO_REPLY control token in chat UI by liuxiaopai-ai · Pull Request #32045 · openclaw/openclaw

liuxiaopai-ai · 2026-03-02T18:42:54Z

Summary

Describe the problem and fix in 2–5 bullets:

Problem: Control UI chat history/event handling can surface assistant messages whose text is exactly NO_REPLY, leaking a silent control token into visible chat.
Why it matters: users see confusing ghost assistant replies during housekeeping turns (for example compaction/memory flush), even though these turns are meant to stay silent.
What changed: add controller-side filtering for silent assistant payloads in both history load (chat.history) and live chat events (delta/final/aborted fallback paths).
What did NOT change (scope boundary): gateway-side token semantics, core auto-reply token behavior, and non-UI delivery channels.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes [Bug]: Webchat renders NO_REPLY as visible “NO” (silent token leak) #32015

User-visible / Behavior Changes

Control UI no longer renders assistant messages that are exact NO_REPLY control tokens when loading chat history or processing live chat events.

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: macOS
Runtime/container: Node 22 + pnpm
Model/provider: N/A
Integration/channel (if any): Control UI / webchat
Relevant config (redacted): local gateway + chat history/event flow

Steps

Load Control UI chat history containing assistant messages with exact text NO_REPLY.
Observe live chat.event flows where assistant delta/final/aborted fallback can carry NO_REPLY text.
Validate rendered message history and stream state after this PR.

Expected

NO_REPLY control-token messages are not visible in chat history.
Live stream state does not adopt exact NO_REPLY token text.

Actual

Before fix: NO_REPLY could appear as a visible assistant message.
After fix: silent token payloads are filtered at controller boundaries.

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Validation run on this branch:

pnpm --dir ui exec vitest run src/ui/controllers/chat.test.ts --config vitest.config.ts
pnpm lint ui/src/ui/controllers/chat.ts ui/src/ui/controllers/chat.test.ts CHANGELOG.md
pnpm tsgo
pnpm exec oxfmt --check ui/src/ui/controllers/chat.ts ui/src/ui/controllers/chat.test.ts CHANGELOG.md

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: NO_REPLY filtering on history load; NO_REPLY ignored on live delta; NO_REPLY final/aborted fallback payloads are not appended.
Edge cases checked: non-assistant messages remain untouched; normal assistant replies continue to append normally.
What you did not verify: full end-to-end browser interaction against a running gateway in this iteration.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly: revert this PR commit.
Files/config to restore: ui/src/ui/controllers/chat.ts, ui/src/ui/controllers/chat.test.ts, CHANGELOG.md.
Known bad symptoms reviewers should watch for: legitimate assistant replies being suppressed when they are not exact control tokens.

Risks and Mitigations

Risk: over-filtering could suppress legitimate assistant content.
- Mitigation: filter condition is strict exact-token match with surrounding whitespace only; coverage added for normal message paths.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 260cd5982d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-02T18:46:02Z

ui/src/ui/controllers/chat.ts

+      if (finalMessage && !isSilentAssistantMessage(finalMessage)) {
        state.chatMessages = [...state.chatMessages, finalMessage];
        return null;
      }


Return null for silent final events from other runs

In the cross-run branch (payload.runId !== state.chatRunId), a final assistant message that is filtered as NO_REPLY now falls through to return "final" instead of returning null. That return value is treated as a terminal event by handleTerminalChatEvent (in ui/src/ui/app-gateway.ts), which always calls resetToolStream and flushChatQueueForEvent, so background housekeeping finals can clear tool-stream UI for an unrelated active run. Since non-silent cross-run finals already return null, silent filtered finals should follow the same non-terminal path.

Useful? React with 👍 / 👎.

greptile-apps · 2026-03-02T18:48:48Z

Greptile Summary

Fixes the visibility of NO_REPLY control tokens in the webchat UI by adding strict filtering at three key boundaries: chat history loading, live delta streaming, and final/aborted event handling.

Key changes:

Added isSilentReplyTokenText() helper using strict regex match /^\s*NO_REPLY\s*$/ to identify exact control tokens
Added isSilentAssistantMessage() to check if assistant messages contain only the silent token
Applied filtering in loadChatHistory() to exclude NO_REPLY messages from historical data
Updated handleChatEvent() to suppress NO_REPLY in delta updates, final payloads, and aborted fallbacks
Comprehensive test coverage added for all filtering scenarios

Implementation quality:

The regex pattern matches the proven approach used in backend code (src/auto-reply/tokens.ts:isSilentReplyText)
Filtering is appropriately strict (exact match only) to avoid suppressing legitimate messages containing NO_REPLY as part of substantive content
Test coverage validates both filtering behavior and that normal messages continue to work correctly

Confidence Score: 5/5

This PR is safe to merge with minimal risk - it's a focused bug fix with narrow scope and comprehensive test coverage
Score reflects several positive factors: (1) well-defined problem with clear fix scope, (2) filtering logic mirrors proven backend implementation, (3) strict regex prevents false positives, (4) comprehensive test coverage validates all code paths, (5) no changes to gateway semantics or external interfaces, (6) backward compatible with existing chat flows
No files require special attention

_{Last reviewed commit: 260cd59}

Takhoffman · 2026-03-02T22:39:46Z

Closing as superseded by #32183, which is now merged and covers the NO_REPLY history/UI guardrails with regression tests.

fix(webchat): suppress NO_REPLY chat history rendering

260cd59

openclaw-barnacle bot added app: web-ui App: web-ui size: S experienced-contributor labels Mar 2, 2026

chatgpt-codex-connector bot reviewed Mar 2, 2026

View reviewed changes

BunsDev self-assigned this Mar 2, 2026

ademczuk mentioned this pull request Mar 2, 2026

fix(webchat): suppress NO_REPLY token in chat transcript rendering #32183

Merged

5 tasks

Takhoffman closed this Mar 2, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(webchat): suppress NO_REPLY control token in chat UI#32045

fix(webchat): suppress NO_REPLY control token in chat UI#32045
liuxiaopai-ai wants to merge 1 commit intoopenclaw:mainfrom
liuxiaopai-ai:codex/webchat-silent-no-reply-32015

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

chatgpt-codex-connector bot left a comment

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Uh oh!

greptile-apps bot commented Mar 2, 2026

Uh oh!

Takhoffman commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

liuxiaopai-ai commented Mar 2, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot commented Mar 2, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

Takhoffman commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants