Description

When /new (or /reset) is issued while messages are queued (agent busy), the queued messages survive the session reset and are delivered as the first input to the new session. This causes the agent to respond to questions from the previous conversation context, appearing to hallucinate.

Steps to Reproduce

1. Send a message to an agent while it is busy processing another request
2. Message gets queued (visible as [Queued messages while agent was busy] header)
3. Before the agent processes the queued message, send /new to reset the session
4. The queued message from the old session is delivered as the first message in the new session
5. Agent responds to the old question with no context of why it was asked

Expected Behavior

/new should flush/discard any pending queued messages for that session, similar to how /stop "clears queued followups for that session" (per docs).

Alternatively, if preserving queued messages is intentional, they should be clearly marked as originating from a previous session so the agent can handle them appropriately.

Actual Behavior

Queued messages are delivered to the new session with the [Queued messages while agent was busy] header but no indication they are from a prior session. The agent treats them as new conversation input.

Impact

• Agent appears to hallucinate topics the user never raised in the current session
• User wastes time debugging apparent memory contamination
• Particularly confusing for agents with session-startup sequences that run before processing the stale message

Environment

• OpenClaw 2026.3.2
• Channel: Telegram (forum topics)
• Queue mode: collect (default)

Workaround

Send /stop before /new to clear the queue first. This is not obvious to users.

Suggested Fix

The /new handler should call the same queue-clearing logic that /stop uses before minting the new session ID.