Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Control UI displays [TUI] evt= debug messages in chat interface [2 pull requests, 2 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#50905•Fetched 2026-04-08 01:06:42
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Author
MarsLobster2MarsLobster2
Participants
fchangefchangeMarsLobster2MarsLobster2
Timeline (top)
cross-referenced ×3commented ×2referenced ×2

Control UI (webchat) displays [TUI] evt=health sk=undefined cur=agent:main:main and [TUI] evt=agent sk=agent:main:main messages in the chat area / status bar. These WebSocket event logs leak into the user-visible interface.

Root Cause

Control UI (webchat) displays [TUI] evt=health sk=undefined cur=agent:main:main and [TUI] evt=agent sk=agent:main:main messages in the chat area / status bar. These WebSocket event logs leak into the user-visible interface.

Fix Action

Fixed

PR fix notes

PR #50929: fix(ui): suppress leaked TUI debug lines in chat

Description (problem / solution / changelog)

Summary

  • Problem: Control UI could render leaked assistant text like [TUI] evt=health ... / [TUI] evt=chat ... inside the chat transcript.
  • Why it matters: these internal debug/event lines are noisy, user-visible, and look like broken chat output.
  • What changed: hide assistant command/debug messages in Control UI chat history and live chat events; add focused regression coverage for command-flagged and leaked [TUI] evt=... payloads.
  • What did NOT change (scope boundary): no gateway protocol changes, no TUI behavior changes, and no transcript persistence changes.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #50905
  • Related #50905

User-visible / Behavior Changes

  • Control UI no longer shows leaked assistant command/debug lines such as [TUI] evt=... in the chat transcript.
  • Existing NO_REPLY filtering remains intact.

Security Impact (required)

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

Repro + Verification

Environment

  • OS: macOS host / Codex workspace
  • Runtime/container: local repo checkout
  • Model/provider: N/A
  • Integration/channel (if any): Control UI / webchat
  • Relevant config (redacted): default main session (agent:main:main)

Steps

  1. Open Control UI and connect to a gateway session.
  2. Receive assistant messages shaped like leaked TUI debug lines (for example [TUI] evt=health ...).
  3. Observe whether they render in the chat transcript/history.

Expected

  • Internal command/debug lines stay hidden from the Control UI chat transcript.

Actual

  • Before this patch they could show up as normal assistant messages.

Evidence

Attach at least one:

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

Human Verification (required)

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

  • Verified scenarios: reviewed both live chat event handling and chat.history filtering paths to ensure leaked assistant command/debug lines are suppressed in both flows.
  • Edge cases checked: preserved NO_REPLY filtering, preserved real assistant text when present, kept filtering limited to assistant command/debug payloads.
  • What you did not verify: could not execute the new scoped Vitest in this container because node_modules is absent and pnpm bootstrap via Corepack failed to fetch pnpm-10.23.0 from the npm registry (ECONNRESET).

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this PR or restore ui/src/ui/controllers/chat.ts to the previous filter behavior.
  • Files/config to restore: ui/src/ui/controllers/chat.ts, ui/src/ui/controllers/chat.test.ts
  • Known bad symptoms reviewers should watch for: legitimate assistant messages being hidden when they intentionally mimic the [TUI] evt=... debug pattern.

Risks and Mitigations

  • Risk: over-filtering a legitimate assistant reply that exactly matches the leaked TUI debug-event shape.
    • Mitigation: keep filtering assistant-only, preserve non-debug text, and cover the intended hidden-message shapes with regression tests.

Changed files

  • ui/src/ui/controllers/chat.test.ts (modified, +115/-0)
  • ui/src/ui/controllers/chat.ts (modified, +55/-13)

PR #4: fix(ui): filter [TUI] debug messages from chat display (#50905)

Description (problem / solution / changelog)

Summary

Fixes #50905 - Control UI displays [TUI] evt= debug messages in chat interface

Changes

  • Add isDebugMessage() function to detect and filter debug messages starting with [TUI]
  • Filter [TUI] prefixed messages from chat history loading
  • Filter debug messages when handling chat events (final, aborted states)

Testing

  • Code change only, follows existing pattern for filtering NO_REPLY messages

Impact

  • Minimal change
  • No breaking changes

Changed files

  • ui/src/ui/controllers/chat.ts (modified, +35/-4)

Code Example

[TUI] evt=health sk=undefined cur=agent:main:main
[TUI] evt=agent sk=agent:main:main cur=agent:main:main
[TUI] evt=chat sk=agent:main:main cur=agent:main:main
RAW_BUFFERClick to expand / collapse

Description

Control UI (webchat) displays [TUI] evt=health sk=undefined cur=agent:main:main and [TUI] evt=agent sk=agent:main:main messages in the chat area / status bar. These WebSocket event logs leak into the user-visible interface.

Steps to Reproduce

  1. Open Control UI in browser (http://localhost:18789)
  2. Have TUI running simultaneously (or even without TUI)
  3. Observe [TUI] evt=... messages appearing at the bottom of the chat interface

Expected Behavior

WebSocket event logs should not be visible in the chat UI.

Environment

  • OpenClaw version: 2026.3.13
  • OS: macOS 26.3.1 (arm64)
  • Browser: Safari/Chrome on Mac

Screenshots

Messages like:

[TUI] evt=health sk=undefined cur=agent:main:main
[TUI] evt=agent sk=agent:main:main cur=agent:main:main
[TUI] evt=chat sk=agent:main:main cur=agent:main:main

appear in the Control UI chat view.

extent analysis

Fix Plan

The fix involves filtering out unwanted WebSocket event logs from being displayed in the Control UI chat area.

To achieve this, we need to modify the code that handles WebSocket messages. Here are the steps:

  • Identify the function responsible for handling WebSocket messages and updating the chat UI.
  • Add a conditional check to filter out messages that start with [TUI] evt=.

Example code snippet:

// Assuming 'handleWebSocketMessage' is the function that updates the chat UI
function handleWebSocketMessage(message) {
  // Check if the message starts with '[TUI] evt='
  if (message.startsWith('[TUI] evt=')) {
    // Ignore the message if it's a WebSocket event log
    return;
  }
  // Update the chat UI with the message
  updateChatUI(message);
}
  • If the above approach is not feasible, an alternative solution is to modify the WebSocket message sender to exclude event logs from being sent to the client.

Verification

To verify that the fix worked:

  • Open the Control UI in the browser and have TUI running simultaneously.
  • Observe the chat interface for any [TUI] evt= messages.
  • If no such messages appear, the fix is successful.

Extra Tips

  • Make sure to test the fix in different environments and browsers to ensure it works consistently.
  • Consider adding a logging mechanism to track ignored WebSocket event logs for debugging purposes.

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#ssr#installation#tensor shape#autograd error#runtime error#dependency conflict#environment setup#docker error#permission error

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 - ✅(Solved) Fix Control UI displays [TUI] evt= debug messages in chat interface [2 pull requests, 2 comments, 2 participants]