Bug Description

User-reported behavior: after hermes update / gateway restart, an existing Telegram conversation (especially a forum topic/thread) can behave like /new on the next message — prior conversational context is no longer reflected in responses.

I have not reproduced this end-to-end locally during the issue filing step, but I checked the current docs/source/config and the observed behavior appears inconsistent with intended design.

Why this looks wrong

Official docs/source currently say/implement the opposite:

• docs: Sessions persist across messages until they reset. The agent remembers your conversation context.
• docs: gateway sessions are keyed by deterministic message-source keys
• docs: /restart is described as a gateway operation, not a conversation reset
• source: SessionStore loads ~/.hermes/sessions/sessions.json on startup and reuses the existing session when reset policy does not fire
• source: load_transcript(session_id) reloads transcript history from SQLite / JSONL

So a restart causing /new-like amnesia in the same Telegram thread/topic looks like a bug, or at least an edge case not covered by current docs.

Environment

• Hermes Agent: current upstream main docs/source checked at issue filing time
• Platform: Telegram gateway
• Chat type: Telegram group topic / thread (likely forum topic style routing)
• User config:

session_reset:
  mode: none

That is important because this does not look like expected auto-reset behavior.

Expected Behavior

After hermes update or gateway restart:

1. active in-flight work may be interrupted/drained (separate concern)
2. but the next message in the same Telegram chat/topic should continue with the same stored transcript/session context
3. it should not feel equivalent to /new unless an explicit reset command or reset policy fired

Actual Behavior

User reports that after update + gateway restart, the Telegram conversation in the same topic feels fresh / context is gone, like /new was used.

Notes / possibly related but not duplicate

I searched the repo and found nearby work, but nothing that looked like this exact Telegram post-restart context-loss report:

• PR fix(session): persist auto-reset state across gateway restarts #2550 — fix(session): persist auto-reset state across gateway restarts
• PR fix: improve gateway restart resilience and WSL stability #8213 — fix: improve gateway restart resilience and WSL stability
• PR fix: queue busy gateway messages and preserve auto-reset continuity #8544 — fix: queue busy gateway messages and preserve auto-reset continuity
• Issue _session_expiry_watcher re-flushes expired sessions on every gateway restart #2506 — _session_expiry_watcher re-flushes expired sessions on every gateway restart
• Issue [Bug]: Feishu WebSocket sessions not closed on gateway restart — zombie sessions accumulate in DB #9090 — Feishu sessions not closed on gateway restart

These suggest restart/session continuity has had edge cases before, but I didn't find a direct duplicate for Telegram topic context acting like /new after restart.

Suspected areas to inspect

• Telegram topic/thread routing → stable session key reuse after process restart
• transcript reload path after restart (load_transcript)
• any divergence between persisted sessions.json mapping and the history actually supplied to the next agent turn
• update/restart paths where session metadata survives but usable conversation history does not

Reproduction idea

1. Start gateway
2. Use Hermes in a Telegram topic/thread long enough to establish context
3. Confirm session_reset.mode: none
4. Restart gateway (or run hermes update)
5. Send a follow-up in the same topic
6. Observe whether the reply still uses earlier context or behaves like /new

Question

Is post-restart Telegram context continuity supposed to be guaranteed here? If yes, this likely needs a bugfix or at least docs clarifying any current limitation.