Skip to content

Telegram-visible message tool sends are hidden as tool cards and elided from later Codex context #83797

@chac4l

Description

@chac4l

Summary

In OpenClaw 2026.5.18 (50a2481), when an assistant replies to a Telegram group/topic by using the dynamic message tool with action: "send", the actual user-visible reply is delivered successfully to Telegram but is not represented as a normal assistant message in the Control UI or in later Codex context projection.

This makes the Telegram conversation and the OpenClaw frontend diverge: Telegram shows the real answer, while the frontend mostly shows a Message tool card plus any intermediate assistant text. On subsequent turns, the assembled context can include only placeholders such as tool call: message [input omitted] and tool result ... [content omitted], so the assistant may not get the content it previously sent to the human.

Repro Shape

  1. Use OpenClaw with Telegram group/topic routing and the OpenAI Codex app-server runtime.
  2. Have the assistant answer visibly by calling the dynamic tool:
message({ action: "send", message: "<actual reply text>" })
  1. Confirm Telegram receives the message successfully.
  2. Open the same session in Control UI chat.
  3. Send a follow-up message in the same Telegram thread.

Observed Behavior

  • Telegram receives the sent text.
  • Control UI shows the send as a Message tool card rather than as the main assistant reply bubble.
  • If the assistant also emitted a short intermediate text message before the tool call, that intermediate text may be the only visible assistant bubble.
  • The next Codex context projection can render the prior visible reply only as tool call: message [input omitted] / tool result ... [content omitted].
  • If the next turn is interrupted while sending via message, the session store can retain status: "running" even when no active task remains.

Expected Behavior

For channel-visible reply tools, especially message(action="send") targeted at the current source conversation:

  • The delivered text should be canonicalized as an assistant message in the session transcript/UI, or otherwise projected as the assistant's visible reply.
  • The Control UI should not hide the human-visible answer only inside a tool card.
  • Later context assembly should preserve the sent text, with normal redaction rules for truly sensitive fields.
  • Aborted turns should clear or terminalize session lifecycle state consistently.

Why This Matters

This creates a high-trust UX problem: the external channel and the Control UI tell different stories about the same conversation, and the next model turn may lose the content that was actually sent to the user.

Notes

The generic tool-payload elision behavior is reasonable for arbitrary tools, but message(action="send") is a special case because the payload is the user-visible assistant reply, not just implementation detail.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions