openclaw - 💡(How to fix) Fix [Bug]: 2026.5.2 — Telegram DM session entries never persist to sessions.json; every message is a fresh session

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

sessions.json on disk is byte-identical before, during, and after Telegram DM exchanges; per-message .jsonl transcripts are written but no session-store entry is ever persisted, so every DM is treated as message #1 of a new session.

Root Cause

sessions.json on disk is byte-identical before, during, and after Telegram DM exchanges; per-message .jsonl transcripts are written but no session-store entry is ever persisted, so every DM is treated as message #1 of a new session.

Code Example

Snapshots of sessions.json captured before, during, and after a 2-message Telegram exchange — all 3 byte-identical (116451 bytes, 82 top-level keys, no diffs). Captured by diagnostic shell script (snapshot-sessions-write-test.sh) available on request.

Telegram screenshots showing:
- Working multi-turn behavior on 2026-05-19 17:2019:58 BST (same agent, same install, same Telegram chat, no version change since)
- Broken behavior on 2026-05-20: every message produces "I don't have access to the message history before your current message" or similar variants

Per-message .jsonl transcript files in ~/.openclaw/agents/{agentId}/sessions/ confirm the agent harness IS being invoked with the correct agentId for Telegram inbounds — the harness writes the per-turn transcript but the session-store metadata write to sessions.json never lands.

Daemon log dump available on request (journalctl --user -u openclaw-gateway.service).

Will attach screenshots in a follow-up comment after issue is created.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

sessions.json on disk is byte-identical before, during, and after Telegram DM exchanges; per-message .jsonl transcripts are written but no session-store entry is ever persisted, so every DM is treated as message #1 of a new session.

Steps to reproduce

  1. OpenClaw 2026.5.2 (commit 8b2a6e57) with a Telegram channel configured for any agent. session config at defaults: dmScope=main, scope=per-sender, no reset overrides.
  2. Snapshot ~/.openclaw/agents/{agentId}/sessions/sessions.json (note size + top-level key count).
  3. Send "hi" to the agent's Telegram bot; wait for reply.
  4. Snapshot sessions.json again.
  5. Send "what was my previous message?" to the bot; wait for reply.
  6. Snapshot sessions.json a third time.

Observed: sessions.json size and key count byte-identical across all three snapshots. Two new .jsonl transcript files (one per inbound) appear in the same directory, each containing exactly one user message + one assistant reply. The agent's reply to step 5 confirms no awareness of the step 3 message.

Expected behavior

On 2026-05-19 17:20–19:58 BST, same agent + same Telegram chat + same install (no version change since): the agent successfully responded to follow-up questions referencing prior turns in the same chat. Screenshots of multi-turn conversation available on request. Expected: subsequent inbound messages in the same Telegram thread are appended to the existing session and the agent receives prior turns in its context.

Actual behavior

Each Telegram DM is treated as a fresh session. The agent's reply explicitly states "I don't have access to the message history before your current message" or "This is the first message in our current conversation thread." Empirical confirmation: ~/.openclaw/agents/{agentId}/sessions/sessions.json is byte-identical (file size 116451 bytes, 82 top-level keys) before, during, and after a 2-message Telegram DM exchange. A new .jsonl transcript file containing exactly one user turn + one assistant turn is written per inbound message. sessions.json contains entries for cron jobs (agent:{id}:cron:...) and subagent invocations (agent:{id}:subagent:...) but no agent:{id}:main, agent:{id}:telegram:direct:..., or any other DM-scoped entry.

OpenClaw version

2026.5.2 (commit 8b2a6e57fef6c582ec6d27b85150616f9e3a7ba4, built 2026-05-03)

Operating system

Ubuntu 24.04 LTS (kernel 6.8.0-111-generic)

Install method

npm global via curl -fsSL https://openclaw.ai/install.sh | bash

Model

anthropic/claude-haiku-4-5-20251001 (also verified bug with google/gemini-2.5-flash)

Provider / routing chain

openclaw -> direct anthropic API (and openclaw -> direct google generative AI API for the gemini test)

Additional provider/model setup details

agent (the affected agent in our setup) has:

  • model.primary: anthropic/claude-haiku-4-5-20251001
  • model.fallbacks: [google/gemini-2.5-flash]
  • tools.alsoAllow: [browser, wiki_search, wiki_get, wiki_status, wiki_lint, wiki_apply]
  • tools.profile: coding
  • subagents.allowAgents: [va-preparer, va-qa]
  • subagents.requireAgentId: true

When we swapped primary -> google/gemini-2.5-flash and fallback -> anthropic/claude-haiku-4-5, the bug reproduced identically. Both models invoked the sessions_history tool internally during the 2nd turn; tool returned empty.

We also created a fresh "diag" agent (never renamed, minimal personas, fresh ~/.openclaw/agents/diag/ + ~/.openclaw/workspace/diag/, added to agents.list, routed Bogdan's Telegram peer to it via a high-precedence peer binding). Diag exhibited the same bug — ruling out agent-level config or persona.

Logs, screenshots, and evidence

Snapshots of sessions.json captured before, during, and after a 2-message Telegram exchange — all 3 byte-identical (116451 bytes, 82 top-level keys, no diffs). Captured by diagnostic shell script (snapshot-sessions-write-test.sh) available on request.

Telegram screenshots showing:
- Working multi-turn behavior on 2026-05-19 17:20–19:58 BST (same agent, same install, same Telegram chat, no version change since)
- Broken behavior on 2026-05-20: every message produces "I don't have access to the message history before your current message" or similar variants

Per-message .jsonl transcript files in ~/.openclaw/agents/{agentId}/sessions/ confirm the agent harness IS being invoked with the correct agentId for Telegram inbounds — the harness writes the per-turn transcript but the session-store metadata write to sessions.json never lands.

Daemon log dump available on request (journalctl --user -u openclaw-gateway.service).

Will attach screenshots in a follow-up comment after issue is created.

Impact and severity

  • Affected users/systems/channels: All Telegram DM channels for this OpenClaw install. Cron-triggered and subagent-spawned sessions are unaffected.
  • Severity: Blocks workflow. Agent cannot do multi-turn conversation, follow-up clarification, or iterative refinement via Telegram. Single-shot one-off requests still work.
  • Frequency: Always. 100% reproducible. Every Telegram DM is treated as message #1.
  • Consequence: Telegram chat agent is reduced from "real assistant with context retention" to "single-shot stateless function call." Significant degradation of the primary user-facing channel.

Additional information

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

On 2026-05-19 17:20–19:58 BST, same agent + same Telegram chat + same install (no version change since): the agent successfully responded to follow-up questions referencing prior turns in the same chat. Screenshots of multi-turn conversation available on request. Expected: subsequent inbound messages in the same Telegram thread are appended to the existing session and the agent receives prior turns in its context.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: 2026.5.2 — Telegram DM session entries never persist to sessions.json; every message is a fresh session