openclaw - 💡(How to fix) Fix [Bug]: delivery-mirror assistant messages pollute LLM context causing infinite loop (distinct from #71912, #74034) [1 comments, 2 participants]

Bug type

Behavior bug (infinite loop, context window exhaustion)

Beta release blocker

No

Summary

When delivery-mirror appends assistant messages to the session transcript, buildSessionContext() returns them to the LLM as normal conversation context. The LLM misinterprets these delivery-mirror messages as its own previous output and responds by calling the message tool again, creating an infinite loop that rapidly consumes the context window.

In our case, the Xiaotong (晓桐) agent reached 131K/131K tokens stuck in a loop repeatedly sending the same PDF, requiring a Gateway restart.

Steps to reproduce

1. Configure any agent with delivery-mirror enabled
2. Use the message tool with action=send and a file (e.g., filePath: xxx.pdf)
3. The delivery system appends an assistant message with model: "delivery-mirror", provider: "openclaw" to the session transcript
4. On the next LLM turn, buildSessionContext() includes this delivery-mirror message in the context
5. The LLM sees it as normal conversation context and may call message again
6. Loop continues until context window is exhausted

Expected behavior

delivery-mirror messages should be invisible to the LLM context. They are internal delivery bookkeeping and should not be fed back into the conversation.

Actual behavior

buildSessionContext() in session-manager.js returns ALL messages including delivery-mirror entries. The existing isTranscriptOnlyOpenClawAssistantMessage() filter in pi-embedded-runner-CefZK1Pt.js:1045 correctly identifies these messages but is only used in event handlers (handleMessageEnd, etc.), NOT in the main LLM context assembly pipeline.

Root Cause Analysis

Traced the code path:

1. deliver-CClC7J0O.js:1050-1051 — appendAssistantMessageToSessionTranscript() writes delivery-mirror entries with model: "delivery-mirror"
2. session-manager.js — buildSessionContext() returns ALL messages (line 108+) including these delivery-mirror entries
3. pi-embedded-runner-CefZK1Pt.js:5629 — sanitizeSessionHistory() is called but the filtering doesn't cover all code paths (e.g., the second prompt cycle bypasses full sanitization)
4. pi-embedded-runner-CefZK1Pt.js:1045 — isTranscriptOnlyOpenClawAssistantMessage() exists but is only used for event emission, not context filtering

How this differs from previous issues

• #71912: Root cause was antml: thinking tag regex leak in streaming pipeline — fixed in #72032
• #74034: Root cause was heartbeat + auth fallback cascade generating repeated messages
• This issue: Root cause is delivery-mirror messages being returned by buildSessionContext() as normal LLM context — a separate code path that was not fixed by the above

Temporary Fix Applied

Added forced filtering after sanitizeSessionHistory() in pi-embedded-runner-CefZK1Pt.js:

const filteredPrior = prior.filter((msg) =>
  !(msg?.role === "assistant" && msg?.provider === "openclaw" && msg?.model === "delivery-mirror")
);

This works and stops the loop, confirming the root cause.

Suggested Permanent Fix

1. Filter model: "delivery-mirror" messages at the source — either in buildSessionContext() or ensure sanitizeSessionHistory() catches ALL paths where messages are fed to the LLM
2. Alternatively, use a non-assistant role for delivery-mirror entries so they are never treated as LLM output

Environment

• OpenClaw version: 2026.4.12
• Node.js: v22.22.2
• Platform: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2, x64)
• Model: dashscope/qwen3.6-plus
• Plugin: @tencent-connect/openclaw-qqbot v1.7.0

Impact

• Session token exhaustion (131K tokens in one loop)
• Gateway restart required to clear affected sessions
• Affects any agent using message(action=send) with file delivery