openclaw - 💡(How to fix) Fix [Bug]: LLM idle timeout causes duplicate message delivery — previous assistant reply re-sent verbatim [1 participants]

Bug type

Behavior bug (incorrect output delivered to user without crash)

Summary

When the LLM takes longer than idleTimeoutSeconds (default 60s) to produce output, OpenClaw aborts the run and re-delivers the previous assistant reply verbatim as a new Telegram message. The user sees the exact same response twice — once as the original reply, and again as the "response" to their next message.

Reproduction

1. Have a conversation with tool calls that take significant time (e.g. background process polling with process poll --timeout 300000)
2. Send a new user message while the model is processing
3. If the model doesn't produce streaming output within 60s (e.g. waiting for tool results), the run is aborted
4. The previous assistant reply is re-sent to Telegram as a new message

Evidence from transcript

Session transcript shows the sequence clearly:

LINE 150 (04:25:17) assistant: "Here are the results: 5 items processed..." ← correct reply to request A
LINE 152 (04:30:43) user: "now try with different parameters" ← new request B
LINE 154 (04:31:43) custom/openclaw:prompt-error:
  {"error": "LLM idle timeout (60s): no response from model"}
LINE 155 (04:43:19) user: "I noticed you're sending duplicate messages"
LINE 156 (04:43:27) assistant: normal reply to LINE 155

Between LINE 152 and LINE 154, the model was aborted after 60s idle. But the user received LINE 150's content again in Telegram as a response to LINE 152 — the previous reply was re-delivered verbatim.

The duplicate delivery does not appear as a separate assistant message in the transcript — it happens at the delivery/channel layer, not the model layer.

Root cause hypothesis

When idleTimeoutSeconds fires and aborts a run, the outbound message handler may flush or re-send the last buffered/cached assistant text chunk to the channel, effectively duplicating the previous reply.

Key differences from related issues

• Not compaction — session had 0 compactions at time of bug
• Not heartbeat mixing — duplicate was triggered by user message, not heartbeat
• Not Telegram streaming handler — the duplicate is a complete verbatim copy of the previous reply, not a partial chunk

Workaround

Set agents.defaults.llm.idleTimeoutSeconds: 0 to disable the idle timeout entirely.

Environment

• OpenClaw 2026.4.5
• Channel: Telegram (direct chat)
• Model: anthropic/claude-opus-4-6
• Streaming: partial (block streaming enabled)

Related issues

• #37702 (compaction-triggered duplicate — different root cause, same symptom)
• #33592 (Telegram duplicate replies)
• #5806 (session state persists causing repeat messages)