Summary

We observed two user-facing reply integrity issues during Telegram channel conversations using OpenClaw with Codex / OpenAI Responses-style flows:

1. commentary-like internal text can appear in final assistant-visible replies
2. duplicate visible replies can occur when a turn already performed a user-visible tool send

This report is based on:

• transcript evidence
• inspection of compiled dist code paths in the installed OpenClaw runtime

Symptoms

Commentary leak

Users can receive text that looks like internal drafting/commentary, for example:

• Need answer yes can reinstall maybe already exists.

Duplicate replies

A single turn can produce two visible replies instead of one:

• one normal assistant reply
• one additional reply associated with delivery-mirror

This appears to be two separate outbound messages, not one duplicated string.

Evidence

Confirmed by transcript

Session transcript:

• /root/.openclaw/agents/main/sessions/2607bbec-bdf2-4920-ac61-fc8ef586c4cc.jsonl

Findings:

1. commentary-phase text appeared inside assistant-visible content
2. duplicate replies were recorded as two separate assistant messages
3. the second message often appeared as:
   • provider=openclaw
   • model=delivery-mirror

Confirmed by code inspection

In compiled dist code:

Commentary path

• file: dist/auth-profiles-B5ypC5S-.js
• function: buildAssistantMessageFromResponse(response, modelInfo)

item.phase is parsed, but commentary-phase output_text still appears to be collected into final assistant content.

Delivery-mirror path

• file: dist/auth-profiles-B5ypC5S-.js
• functions:
  • appendAssistantMessageToSessionTranscript(params)
  • deliverOutboundPayloads(...)
  • executeSendAction(params)
  • sendMessage$1(params)

delivery-mirror is explicitly generated as an assistant-side transcript message after outbound send success.

Root cause assessment

Confirmed / strongly supported

1. commentary leakage appears to happen in final response assembly
   • buildAssistantMessageFromResponse(...) parses item.phase but still appears to include commentary-phase text in final assistant content
2. duplicate reply behavior involves a distinct delivery-mirror assistant message path
   • this is not just a Telegram rendering artifact

High-probability inference

The duplicate visible reply issue is likely caused by missing turn-level mutual exclusion between:

• user-visible tool send
• delivery-mirror append
• normal final assistant reply delivery

We have not yet fully proven the exact final outbound dispatch function in every case.

Suggested fix directions

1. Commentary leak

In buildAssistantMessageFromResponse(...):

• exclude items where phase === "commentary" from final assistant-visible content

2. Duplicate replies

Introduce turn-level suppression logic:

• if a turn already performed a user-visible tool send
• suppress the normal final assistant reply for that same turn

This would avoid double visible delivery without necessarily removing transcript mirror support.

Notes / impact

This investigation is intentionally conservative:

• transcript evidence is direct
• code-path assessment is based on compiled dist artifacts
• some final-delivery details still need deeper tracing

User impact is significant because these issues affect:

• reply integrity
• trust
• transcript cleanliness
• duplicate visible messages