Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Control UI/WebChat can replace visible user message with ACP/Codex system output [1 comments, 1 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#55411•Fetched 2026-04-08 01:39:49
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Author
SebastianBaehrSebastianBaehr
Participants
SebastianBaehrSebastianBaehr
Timeline (top)
closed ×1commented ×1locked ×1

In Control UI / WebChat, a normal user message can appear to be replaced or overwritten in the visible chat timeline by ACP/Codex system output from an isolated child run.

This creates a confusing and potentially dangerous UX failure:

  • the user sends a normal message (for example: "wie ist der stand?")
  • instead of seeing that user message reflected normally in the transcript, the chat shows internal Codex/system lines such as planning output, blocker questions, and completion notices
  • at the same time, the parent assistant session may still be unable to read the ACP child session cleanly via normal session tools

So the UI can expose internal runtime content that the assistant itself cannot consistently retrieve through the intended orchestration path.

Root Cause

In Control UI / WebChat, a normal user message can appear to be replaced or overwritten in the visible chat timeline by ACP/Codex system output from an isolated child run.

This creates a confusing and potentially dangerous UX failure:

  • the user sends a normal message (for example: "wie ist der stand?")
  • instead of seeing that user message reflected normally in the transcript, the chat shows internal Codex/system lines such as planning output, blocker questions, and completion notices
  • at the same time, the parent assistant session may still be unable to read the ACP child session cleanly via normal session tools

So the UI can expose internal runtime content that the assistant itself cannot consistently retrieve through the intended orchestration path.

RAW_BUFFERClick to expand / collapse

Summary

In Control UI / WebChat, a normal user message can appear to be replaced or overwritten in the visible chat timeline by ACP/Codex system output from an isolated child run.

This creates a confusing and potentially dangerous UX failure:

  • the user sends a normal message (for example: "wie ist der stand?")
  • instead of seeing that user message reflected normally in the transcript, the chat shows internal Codex/system lines such as planning output, blocker questions, and completion notices
  • at the same time, the parent assistant session may still be unable to read the ACP child session cleanly via normal session tools

So the UI can expose internal runtime content that the assistant itself cannot consistently retrieve through the intended orchestration path.

Environment

  • OpenClaw: observed on 2026-03-27 in local Control UI / WebChat usage
  • Surface: Control UI / WebChat (openclaw-control-ui)
  • Channel: webchat
  • Parent agent: main session
  • Child run: sessions_spawn(runtime: "acp", agentId: "codex", mode: "run", streamTo: "parent")
  • OS: macOS

Steps to reproduce

  1. Open Control UI / WebChat.
  2. In the main chat, ask the assistant to send a coding/planning task to Codex via ACP.
  3. Assistant calls something equivalent to:
    • sessions_spawn(runtime="acp", agentId="codex", mode="run", streamTo="parent", task="...")
  4. Before the orchestration loop is cleanly closed, send another normal user message in the same chat, e.g.:
    • wie ist der stand?
  5. Observe the visible Control UI transcript.

Expected behavior

  • The user's message should appear normally in the chat.
  • Internal ACP/Codex runtime events should not replace, overwrite, or visually take the place of the user's message.
  • If child progress/completion is surfaced, it should appear as correctly typed assistant progress/status updates, scoped to the right session and rendered as distinct messages.
  • The parent assistant should have a consistent way to observe the child run if the UI is also receiving related status output.

Actual behavior

The visible chat showed internal/system Codex output instead of the user's own message, including lines like:

  • codex: zurück auf /, Anzeige für neue und bestehende Nutzer, anschließend npm run typecheck und npm run build.
  • codex: Offene Fragen / Blocker
  • follow-up blocker text about first-name sourcing and landing-page scope
  • codex run completed.

The user message (wie ist der stand?) appeared to have been replaced in the UI by those system/runtime messages.

Meanwhile, the parent assistant session reported that it could not reliably inspect the isolated ACP child session through normal session-history access, which suggests an event-routing / visibility mismatch:

  • UI sees internal runtime output
  • parent orchestration tools do not have equivalent clean access

Why this is bad

  • Internal runtime/system output is leaking into the end-user chat timeline.
  • A user message can appear to disappear or be overwritten.
  • This breaks trust in the transcript.
  • It creates confusion about what the user actually sent versus what the runtime injected.
  • It makes ACP orchestration feel nondeterministic and unsafe.

Suspected area

Likely somewhere in Control UI / WebChat event routing, transcript rendering, or session/event reconciliation for ACP child runs, especially when using streamTo: "parent" and isolated ACP sessions.

Possible contributing factors:

  • internal completion/progress events being rendered directly into chat
  • wrong message typing/provenance mapping in WebChat
  • parent/child session reconciliation mismatch
  • transcript item collision / replacement logic in Control UI
  • session visibility mismatch between UI event stream and sessions_history

Related issues

This seems related to, but not identical with:

  • #44528 — Control UI internal task completion event incorrectly delivered to chat
  • #54690 — ACP streamTo:"parent" completion never delivered cleanly to parent session
  • #54878 — ACP child sessions not readable via sessions_history
  • #55245 — Control UI/WebChat messages intermittently disappear

This issue is specifically about a normal user message appearing to be replaced/overwritten in the visible Control UI transcript by ACP/Codex system output.

extent analysis

Fix Plan

To address the issue of a normal user message being replaced or overwritten in the visible chat timeline by ACP/Codex system output, we need to modify the event routing and transcript rendering logic in Control UI / WebChat. Here are the steps:

  1. Separate User and System Messages: Introduce a new message type to differentiate between user messages and system/runtime messages.
  2. Modify Event Routing: Update the event routing logic to handle system messages differently, ensuring they do not overwrite user messages in the transcript.
  3. Update Transcript Rendering: Modify the transcript rendering logic to display system messages as separate, distinct messages, rather than overwriting user messages.

Example code snippet (in JavaScript):

// Introduce a new message type for system messages
const MESSAGE_TYPE_SYSTEM = 'system';

// Update event routing logic
function handleEvent(event) {
  if (event.type === MESSAGE_TYPE_SYSTEM) {
    // Handle system message separately
    renderSystemMessage(event);
  } else {
    // Handle user message normally
    renderUserMessage(event);
  }
}

// Update transcript rendering logic
function renderSystemMessage(event) {
  const systemMessageElement = document.createElement('div');
  systemMessageElement.classList.add('system-message');
  systemMessageElement.textContent = event.message;
  transcriptContainer.appendChild(systemMessageElement);
}

function renderUserMessage(event) {
  const userMessageElement = document.createElement('div');
  userMessageElement.classList.add('user-message');
  userMessageElement.textContent = event.message;
  transcriptContainer.appendChild(userMessageElement);
}

Verification

To verify the fix, follow these steps:

  1. Open Control UI / WebChat and send a normal user message.
  2. Before the orchestration loop is cleanly closed, send another normal user message.
  3. Observe the visible Control UI transcript.
  4. Verify that the user message is displayed normally and not overwritten by system/runtime messages.

Extra Tips

To prevent similar issues in the future, consider implementing the following:

  • Use a robust message typing system to differentiate between user and system messages.
  • Implement a message queue to handle events and prevent overwriting of user messages.
  • Regularly review and test the event routing and transcript rendering logic to ensure correct behavior.

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 user's message should appear normally in the chat.
  • Internal ACP/Codex runtime events should not replace, overwrite, or visually take the place of the user's message.
  • If child progress/completion is surfaced, it should appear as correctly typed assistant progress/status updates, scoped to the right session and rendered as distinct messages.
  • The parent assistant should have a consistent way to observe the child run if the UI is also receiving related status output.
#database connection#vector store#embedding generation#cache error#pipeline 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