Bug type

Behavior bug (incorrect output/state without crash)

Summary

Environment

• OpenClaw version: 2026.3.12 (6472949) (confirmed on session dated 2026-03-12)
• Channel: POPO IM (custom integration via aigateway-xxxxx-com)
• Model: kimi-k2.5
• OS: Linux server （Debian 12）

Description

When an external message arrives while the agent is busy executing a task, OpenClaw queues it as [Queued messages while agent was busy] and inserts it into the
session's parentId chain. After the current task completes and the assistant outputs a final summary (no toolCall), the agent loop does not terminate.
Instead, OpenClaw continues invoking the model, which sees the unhandled Queued user message in context and proceeds to fully replay the previous task — generating
10+ consecutive assistant messages within ~1.5 seconds, all without any real tool execution.

Restarting OpenClaw does not fix the issue. Deleting the session JSONL files and restarting does.

Reproduction Steps

1. Configure an agent with an external IM integration (POPO, Telegram, etc.)
2. Send a message that triggers a long multi-step task (multiple toolCall/toolResult cycles)
3. While the agent is executing, send a new message from the external channel
4. Observe [Queued messages while agent was busy] inserted into the session
5. Wait for the current task to complete (assistant outputs final text-only summary)
6. Observe: the agent does not stop — it immediately continues generating new assistant messages

Expected Behavior

After the assistant outputs a final response with no toolCall, the agent loop should terminate. Queued messages should be handled as a new turn, not as
continuation of the current loop.

Actual Behavior

The agent loop continues. The model is called again with the full context (which includes the Queued user message) and begins replaying the previously completed
task — outputting 10+ consecutive assistant messages at ~150ms intervals, none of which execute any tools.

Session Log Evidence

Analyzed from JSONL session logs (431 lines, session e999671b-...):

The replayed content is byte-for-byte identical to earlier messages in the session:

Line 149 (original): "好的，我来更新配置：1. 每天提醒加入本日天气..."
Line 182 (replay):   "好的，我来更新配置：1. 每天提醒加入本日天气..."  ← identical

Timing of the 11-message replay sequence:

03:10:34.296Z → normal final summary (line 181)
03:10:34.502Z → replay begins (206ms later)
03:10:34.653Z → (151ms)
03:10:34.772Z → (119ms)
...
03:10:35.655Z → ends (11 messages, 1.36 seconds total)

Replay sequence length scales with context size — when context had ~50 messages, sequences were 2–3 messages long; by the time context reached 180 messages,
sequences grew to 11.

Root Cause (Hypothesis)

The agent loop termination condition does not distinguish between:

1. A Queued message already present in historical context (inserted mid-task)
2. A new user message arriving after the current task completed

After the assistant produces a text-only final response, the loop should stop. Instead it appears to scan the full session chain for any unanswered user message —
finds the Queued message — and invokes the model again.

Why Deleting Session Files Fixes It

The corrupted context chain is persisted in the JSONL file. On restart, OpenClaw resumes from the same poisoned context. Deleting the file removes the chain
entirely, so the next session starts clean.

Workaround

Delete session JSONL files and restart. (Restart alone is insufficient.)

Related Issues

• Followup queue delivers same message multiple times when agent is busy #30604 — Followup queue delivers same message multiple times when agent is busy: upstream/related at the queue layer. PR fix: prevent followup queue from delivering same message multiple times (closes #30604) #46170 was opened to fix it but
  closed by the author without merging.
• Bug: /new does not flush queued messages, delivering stale messages to fresh session #35092 — /new does not flush queued messages: corroborates why session deletion is required for recovery.
• [Bug]: Discord collect-mode auto-reply drain causes duplicate message delivery #50892 — Discord collect-mode duplicate delivery: superficially similar but different mechanism; confirmed not the same issue.

The core problem described here — agent loop not terminating after final response when Queued messages exist in context — does not appear to have an existing
tracking issue.

Steps to reproduce

1. Configure an agent with an external IM integration (POPO, Telegram, etc.)
2. Send a message that triggers a long multi-step task (multiple toolCall/toolResult cycles)
3. While the agent is executing, send a new message from the external channel
4. Observe [Queued messages while agent was busy] inserted into the session
5. Wait for the current task to complete (assistant outputs final text-only summary)
6. Observe: the agent does not stop — it immediately continues generating new assistant messages

Expected behavior

After the assistant outputs a final response with no toolCall, the agent loop should terminate. Queued messages should be handled as a new turn, not as
continuation of the current loop.

Actual behavior

The agent loop continues. The model is called again with the full context (which includes the Queued user message) and begins replaying the previously completed
task — outputting 10+ consecutive assistant messages at ~150ms intervals, none of which execute any tools.

OpenClaw version

2026.3.12 (6472949)

Operating system

Debin12

Install method

No response

Model

kimi-k2.5

Provider / routing chain

openclaw -> aigw.xxx.com -> kimi

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response