Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: when TTS on, TTS audio base64 data is not cleaned from session,triggering context window expansion [4 comments, 4 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#70179•Fetched 2026-04-23 07:28:13
View on GitHub
Comments
4
Participants
4
Timeline
9
Reactions
0
Author
SandmarSandmar
Participants
jimdawdy-hubjimdawdy-hubrafiki270rafiki270SandmarSandmarsteipetesteipete
Timeline (top)
commented ×4cross-referenced ×2labeled ×2closed ×1

Description When TTSis enabled, generated audio is embedded as base64 in the assistant message content array. However, in the sanitizeChatHistoryContentBlock cleaning function, only image type base64 data gets cleaned up, but audio type is left untouched.

This causes the full base64 audio data to remain in the session transcripts indefinitely. As more TTS responses are generated, the session file grows larger and larger, consuming significant amounts of context window space.

Root Cause In the sanitizeChatHistoryContentBlock function: image type uses structure: { type: "image", data: "base64..." } → code correctly cleans up entry.data audio type uses structure: { type: "audio", source: { type: "base64", media_type: "audio/mp3", data: "base64..." } } → base64 is stored at entry.source.data, which is not handled by the existing cleanup logic

// Existing code only handles images if ((typeof entry.type === "string" ? entry.type : "") === "image" && typeof entry.data === "string") { const bytes = Buffer.byteLength(entry.data, "utf8"); delete entry.data; entry.omitted = true; entry.bytes = bytes; changed = true; } // Missing handling for audio

<img width="1153" height="67" alt="Image" src="https://github.com/user-attachments/assets/7c61f0ad-dc27-4317-8e61-0a87114a2c09" />

Root Cause

Root Cause In the sanitizeChatHistoryContentBlock function: image type uses structure: { type: "image", data: "base64..." } → code correctly cleans up entry.data audio type uses structure: { type: "audio", source: { type: "base64", media_type: "audio/mp3", data: "base64..." } } → base64 is stored at entry.source.data, which is not handled by the existing cleanup logic

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Description When TTSis enabled, generated audio is embedded as base64 in the assistant message content array. However, in the sanitizeChatHistoryContentBlock cleaning function, only image type base64 data gets cleaned up, but audio type is left untouched.

This causes the full base64 audio data to remain in the session transcripts indefinitely. As more TTS responses are generated, the session file grows larger and larger, consuming significant amounts of context window space.

Root Cause In the sanitizeChatHistoryContentBlock function: image type uses structure: { type: "image", data: "base64..." } → code correctly cleans up entry.data audio type uses structure: { type: "audio", source: { type: "base64", media_type: "audio/mp3", data: "base64..." } } → base64 is stored at entry.source.data, which is not handled by the existing cleanup logic

// Existing code only handles images if ((typeof entry.type === "string" ? entry.type : "") === "image" && typeof entry.data === "string") { const bytes = Buffer.byteLength(entry.data, "utf8"); delete entry.data; entry.omitted = true; entry.bytes = bytes; changed = true; } // Missing handling for audio

<img width="1153" height="67" alt="Image" src="https://github.com/user-attachments/assets/7c61f0ad-dc27-4317-8e61-0a87114a2c09" />

Steps to reproduce

1.Enable TTS with /tts on 2.Have the assistant generate responses with speech audio 3.Inspect the session file ~/.openclaw/agents/main/sessions/<session-id>.jsonl 4.Observe that full base64 audio data is preserved in the source.data field of audio blocks, never cleaned

Expected behavior

TTS audio base64 data clean from session

Actual behavior

TTS audio base64 data is not cleaned from session

OpenClaw version

2026.4.15

Operating system

Windows 11

Install method

No response

Model

minimax

Provider / routing chain

openclaw-minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The most likely fix is to update the sanitizeChatHistoryContentBlock function to handle audio type base64 data by cleaning up entry.source.data in addition to entry.data.

Guidance

  • Identify the sanitizeChatHistoryContentBlock function and update the existing cleanup logic to handle audio type base64 data.
  • Add a conditional statement to check for entry.type === "audio" and entry.source.type === "base64", then clean up entry.source.data accordingly.
  • Verify the fix by enabling TTS, generating responses with speech audio, and inspecting the session file to ensure that the full base64 audio data is no longer preserved.
  • Consider adding logging or debugging statements to monitor the cleanup process and ensure that the fix is working as expected.

Example

if ((typeof entry.type === "string" ? entry.type : "") === "image" && typeof entry.data === "string") {
    // existing image cleanup logic
} else if (entry.type === "audio" && entry.source && entry.source.type === "base64" && typeof entry.source.data === "string") {
    const bytes = Buffer.byteLength(entry.source.data, "utf8");
    delete entry.source.data;
    entry.omitted = true;
    entry.bytes = bytes;
    changed = true;
}

Notes

The provided code snippet only handles the cleanup of image type base64 data, and the audio type base64 data is stored in a different structure. The fix should account for this difference and update the cleanup logic accordingly.

Recommendation

Apply the workaround by updating the sanitizeChatHistoryContentBlock function to handle audio type base64 data, as this will fix the issue without requiring an upgrade to a fixed version.

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

TTS audio base64 data clean from session

#training loop#device allocation#model download#tokenizer error#prompt formatting

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING