Summary

OpenClaw can still leak internal commentary / tool-call trace text into Telegram user-visible messages in 2026.3.13 when using openai-codex/gpt-5.4.

The leaked text includes:

• raw tool-call-like JSON arguments
• internal routing fragments like to=functions.exec / to=functions.process
• internal-looking labels like analysis / wait
• random multilingual garbage tokens such as 久久免费, 大香蕉, 平台主管

This looks very similar to earlier issues in the same family, but with a few important differences:

• reproduced on Telegram DM, not just Discord / Feishu / Olvid
• reproduced on current OpenClaw 2026.3.13
• reproduced with openai-codex/gpt-5.4, not just older Codex variants
• local transcript evidence shows the leaked string is already stored as assistant text with phase: "commentary", next to a valid structured tool call

Steps to reproduce

1. Use OpenClaw in a Telegram direct chat
2. Use openai-codex/gpt-5.4 as the runtime model
3. Trigger a multi-step task involving long-running local tools, e.g.
   • exec to download media / prepare files
   • background exec
   • repeated process poll
4. Wait for the task to run through several tool rounds
5. Observe that an occasional malformed internal-looking message can be sent to Telegram before the final answer

In the observed case, this happened during a local transcription workflow (download media → extract audio → run local MLX Whisper → poll background process).

Expected behavior

Only intentional user-facing natural language should reach Telegram.

The following should never be visible to the user:

• commentary-only text
• raw tool-call traces
• to=functions.*
• analysis / wait
• malformed / garbage multilingual tokens

Actual behavior

Telegram received malformed internal-looking messages such as:

{"action":"poll","sessionId":"glow-mist","timeout":30000} to=functions.process 久久免费热在线精品functions.process კომენტary to=functions.process ,大香蕉analysis to=functions.process wait

Other similar leaked messages also included:

• to=functions.exec plus mixed-script garbage between tool-routing fragments
• another process poll leak with 平台总代理 and a different random multilingual token before analysis
• raw JSON tool arguments appearing as plain text immediately before a valid structured toolCall

Key evidence

The important part is that the malformed string was already present in the assistant message content, not in the tool result.

A simplified structure from the local transcript looked like this:

{
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "{\"action\":\"poll\",\"sessionId\":\"glow-mist\",\"timeout\":30000} to=functions.process 久久免费热在线精品functions.process კომენტary to=functions.process ,大香蕉analysis to=functions.process wait",
      "textSignature": "{\"v\":1,\"id\":\"...\",\"phase\":\"commentary\"}"
    },
    {
      "type": "toolCall",
      "name": "process",
      "arguments": {
        "action": "poll",
        "sessionId": "glow-mist",
        "timeout": 30000
      }
    }
  ]
}

Additional observations:

• the adjacent toolCall is valid and structured normally
• surrounding toolResult entries were clean
• the first malformed text blocks appeared before any suspicious tool output that could explain them
• the garbage tokens did not appear to come from the media being processed or the tool outputs themselves

Root cause hypothesis

This looks like two problems compounding:

1. Model/output-side failure

   • during tool-calling, the model sometimes emits malformed commentary text instead of staying purely in structured tool-call mode
   • the malformed commentary text can contain raw tool-call transcript fragments plus random multilingual junk tokens

2. OpenClaw delivery/sanitization failure

   • OpenClaw stores that malformed text as assistant text / phase: "commentary"
   • that commentary text is later forwarded to Telegram instead of being suppressed or sanitized

So this looks less like a compromised tool and more like:

• malformed model tool-call/commentary output
• plus a runtime/outbound filtering gap

Why this report may still be useful even if related issues exist

This report adds:

• Telegram confirmation for the same bug family
• 2026.3.13 confirmation that the issue is still present
• gpt-5.4 / Codex runtime confirmation
• direct evidence that the leaked payload is stored as assistant commentary text before delivery

Related issues

This seems related to:

• [Bug]: Codex subagent emits raw function-call syntax and hallucinated tokens to user chat #30441 — Codex subagent emits raw function-call syntax and hallucinated tokens to user chat
• [Bug]: Telegram stream + reasoning leaks toolUse intermediate status text into user-visible replies (regression) #24376 — Telegram stream + reasoning leaks toolUse intermediate status text into user-visible replies
• Text between tool calls leaks to messaging channels #25592 — Text between tool calls leaks to messaging channels
• Bug: Internal tool-call trace leaked into user-visible chat message (Olvid group) #30704 — Internal tool-call trace leaked into user-visible chat message
• [Bug]: OpenClaw may leak internal tool-call/commentary payload into user-visible Feishu DM messages #41435 — Internal tool-call/commentary payload leaked into user-visible Feishu DM messages
• Discord leaks internal tool-call traces (NO_REPLY, commentary, to=functions) to channel #44905 — Discord leaks internal tool-call traces (commentary, to=functions.*, raw JSON)
• [Bug]: Model does "tool calling narrations" since 2026.3.7 #45271 — Model does tool-calling narrations since 2026.3.7

If maintainers think this is a duplicate, happy to close it in favor of the best canonical issue.

Environment

• OpenClaw: 2026.3.13
• OS: macOS arm64
• Channel: Telegram DM
• Runtime model: openai-codex/gpt-5.4
• Trigger pattern: multi-step tool workflow with long-running exec + repeated process poll

(Deliberately omitting any personal paths, chat IDs, usernames, or private transcript locations from this public report.)