openclaw - 💡(How to fix) Fix Bug Report: Conversation history not passed between runs — manifests differently across channels [2 comments, 3 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After each model run completes (session.ended), the messagesSnapshot from that run is not carried forward into the messages array of the next run. Every new session.started begins with no prior conversation history. The symptom differs by channel:

• Telegram: user messages accumulate across runs (via a separate mechanism), but assistant responses are never included — the model receives only user turns and compensates by re-summarising all prior content in every reply.
• Web dashboard (openclaw-control-ui): nothing accumulates — every run starts with messages: [], making each turn a completely independent conversation.

Both channels share the same root cause: prior messagesSnapshot is not injected into the next run's messages array.

(this report is written by sonnet webUI base on my whole debugging history)

Steps to reproduce

Telegram:

1. Start a new session (/new) in Telegram direct chat
2. Send message 1 (e.g. "What time is it?") → receive normal response
3. Send message 2 (e.g. "What time is it in Phuket?") → response includes content from message 1's answer
4. Send message 3 (e.g. "Explain UTC and GMT") → response includes content from messages 1 and 2
5. Each subsequent turn accumulates all prior answers

Web dashboard:

1. Open a chat session in openclaw-control-ui
2. Send message 1 → receive normal response
3. Send message 2 → model has no memory of message 1
4. Each turn is completely independent

Expected behavior

Each run's messages array should include the full prior conversation:

[user_1, assistant_1, user_2, assistant_2, ..., user_N]

The model answers only the current question, with prior context available but not repeated.

Actual behavior

Telegram — messages array per turn:

Turn 1: []                                              (0 entries)
Turn 2: [user_1, custom, assistant_1+toolResult, user_2, custom]   (4 entries — no assistant reply to turn 1 text)
Turn 3: [..., user_3, custom]                           (6 entries — no assistant reply to turn 2)
Turn 4: [..., user_4, custom]                           (8 entries — no assistant reply to turn 3)

Assistant response text is never appended. Only user and custom (channel metadata) messages accumulate.

Web dashboard — messages array per turn:

Turn 1: []   (0 entries)
Turn 2: []   (0 entries)
Turn 3: []   (0 entries)
Turn 4: []   (0 entries)

No history carried at all. messagesSnapshot per turn is always exactly 3 entries: [user_N, custom, assistant_N] — current turn only.

Token usage anomaly (both channels): input: 10 on every turn from turn 2 onward — abnormally low, consistent with near-zero new tokens being submitted.

OpenClaw version

2026.5.2 (8b2a6e5)

Operating system

macOS

Install method

Homebrew (/opt/homebrew/lib/node_modules/openclaw)

Model

• Telegram session (2026-05-12 21:29–22:56 KST): anthropic/claude-haiku-4-5 - Telegram session (2026-05-13 08:53–08:57 KST): google/gemini-2.5-flash - Web dashboard session (2026-05-13 12:26–12:30 KST): anthropic/claude-haiku-4-5 All three sessions exhibit the same root cause across two different models — confirms this is an OpenClaw session/history management bug, not model-side.

Provider / routing chain

• Anthropic (api-key, anthropic:default) — Telegram and web dashboard - Google (api-key, google:default) — Telegram - Channels: Telegram direct chat, openclaw-control-ui

Additional provider/model setup details

No fallbacks configured. No compaction occurred in any session (compactionCount: 0). Sessions were initiated fresh (/new for Telegram, new chat for web dashboard).

Each run follows the pattern: session.started → prompt.submitted → model.completed → session.ended. This per-prompt start/end cycle appears to be normal OpenClaw behavior. The bug is that history from the previous run's messagesSnapshot is not injected into the next run's messages array.

The custom role message (channel metadata) is injected between every user turn in Telegram. This may interfere with assistant reply insertion logic in that channel's history assembly path.

Logs, screenshots, and evidence

**Telegram session `5b991f02` — session lifecycle and messages array size per turn:**

21:30:22  SESSION.STARTED → prompt.submitted messages=0  → SESSION.ENDED
21:30:47  SESSION.STARTED → prompt.submitted messages=4  → SESSION.ENDED
21:33:00  SESSION.STARTED → prompt.submitted messages=6  → SESSION.ENDED
21:36:01  SESSION.STARTED → prompt.submitted messages=8  → SESSION.ENDED
22:02:02  SESSION.STARTED → prompt.submitted messages=10 → SESSION.ENDED


**Telegram turn 3 — messages array (assistant reply from turn 2 absent):**

[
  {"role": "user",       "content": "Hi what time is it now?"},
  {"role": "custom",     "content": "Conversation info (untrusted metadata)..."},
  {"role": "assistant",  "content": [{"type":"thinking"}, ...]},
  {"role": "toolResult", "content": [...]},
  {"role": "user",       "content": "what time is it now in phuket"},
  {"role": "custom",     "content": "Conversation info (untrusted metadata)..."}
  // ← assistant reply to turn 2 ("phuket is 19:30") is absent
]


**Web dashboard session `559d7c65` — session lifecycle and messages array size per turn:**

12:26:31  SESSION.STARTED → prompt.submitted messages=0  → SESSION.ENDED
12:28:47  SESSION.STARTED → prompt.submitted messages=0  → SESSION.ENDED
12:30:06  SESSION.STARTED → prompt.submitted messages=0  → SESSION.ENDED
12:30:48  SESSION.STARTED → prompt.submitted messages=0  → SESSION.ENDED


**Web dashboard `messagesSnapshot` per turn (always 3 — current turn only):**

Turn 1 snapshot: [user_1, custom, assistant_1]
Turn 2 snapshot: [user_2, custom, assistant_2]   ← no history from turn 1
Turn 3 snapshot: [user_3, custom, assistant_3]   ← no history from turns 1–2
Turn 4 snapshot: [user_4, custom, assistant_4]   ← no history from turns 1–3


**Token usage (both channels, turns 2+):**

input: 10  (abnormally low — near-zero fresh tokens submitted)
cacheRead: 16320  (system prompt served from cache)

Impact and severity

• Affected: All channels tested — Telegram direct chat and web dashboard (openclaw-control-ui)
• Severity: High — multi-turn conversation is functionally broken in both channels
• Frequency: 100% reproducible; occurs from turn 2 onward in every session
• Consequence (Telegram): Model re-summarises all prior answers on every turn, producing an expanding wall of repeated content
• Consequence (Web dashboard): Model has no memory of prior turns; each message is treated as a new conversation

Additional information

The two symptoms are different manifestations of the same root cause: prior run's messagesSnapshot is not passed into the next run's messages array.

The difference between channels suggests the history carry-forward logic has separate code paths per channel type, both of which are broken:

• Telegram path: partially assembles history (user messages only) but drops assistant replies — possibly because the custom role injected after each user message disrupts the assistant reply append point
• Web dashboard path: does not assemble history at all — messages: [] on every run

Possibly related to issue #76888 (orphaned user-message merge), but the symptom here is reproducible without any model errors or fallback events — it occurs on clean, successful runs.