openclaw - 💡(How to fix) Fix [Bug]: Internal media helper text leaks into visible chat/history around media handling/compaction [1 participants]

Summary

Internal OpenClaw media/prompt helper text is leaking into visible conversation content.

Instead of only seeing the user message / attachment / transcript, the chat can show internal lines like:

[media attached: C:\...\file.ogg (audio/ogg; codecs=opus)]
To send an image back, prefer the message tool (media/path/filePath). If you must inline, use MEDIA:https://example.com/image.jpg ...

In the observed case, this also appeared to survive into the post-COMPACTION view/history, which makes it look like prompt-prelude/media-context text is escaping into user-visible conversation state rather than staying internal.

Why this looks like a real bug

The leaked helper string is not user content. It is the internal REPLY_MEDIA_HINT constant in the current installed OpenClaw build:

• dist/get-reply-XW5nFnK2.js
• const REPLY_MEDIA_HINT = "To send an image back, prefer the message tool ..."

That same file shows the hint being prepended when inbound media is present:

• buildInboundMediaNote(ctx)
• mediaReplyHint = mediaNote ? REPLY_MEDIA_HINT : void 0
• then included in queuedBody / prefixedCommandBody

So the symptom is not just normal <media:audio> placeholder behavior. It looks like internal prompt/media-context text is leaking into rendered conversation/history.

Observed behavior

User reported this on Windows while using OpenClaw and shared a screenshot showing:

• raw inbound media envelope text
• internal helper text (To send an image back...)
• this showing up around a COMPACTION boundary rather than staying invisible/internal

Expected behavior

• Internal prompt helper text should never appear in user-visible chat/history
• Media context lines like [media attached: ...] should remain internal unless intentionally surfaced by a specific UI/debug mode
• Compaction/replay/history should not serialize or render internal prompt-prelude content as conversation text

Actual behavior

• The internal media hint leaks into visible chat/history
• The user sees internal attachment/prompt text instead of a clean message/transcript path
• The effect appears especially confusing around compaction/replay

Notes

I do not yet have a minimal clean upstream repro on latest Windows, only:

1. a real Windows user report with screenshot,
2. confirmation that the exact leaked string exists in prompt-prelude code,
3. prior related evidence of raw <media:audio> / [media attached: ...] leakage in session artifacts on another install.

So this may be one of:

• prompt-prelude text leaking into visible history,
• compaction/replay serializing prompt body instead of user message body,
• media-context/debug text being rendered on a path where it should be stripped.

Related issues

Related, but not exact duplicates:

• #15840 [Feature]: Option to suppress <media:audio> placeholder text
• #6869 Audio files (.ogg) incorrectly detected as text/plain, causing garbled output
• #22554 Telegram voice messages not auto-transcribed despite tools.media.audio.enabled config (Windows)
• #65978 Audio transcription skipped on direct delivery to idle agent (WhatsApp)

Those all live in the same family of media/placeholder/transcription problems, but this report is specifically about internal prompt helper text leaking into visible conversation state.

Suggested next check

Trace whether queuedBody / prefixedCommandBody (or their compaction/replay equivalents) can be serialized back into session-visible content when inbound media is present.