Summary

When a chat session triggers one or more context compressions, hermes forks the session into a chain of child sessions (parent_session_id linking each new session to the previous) and resets the SQLite flush cursor. Messages saved in the messages table end up under the latest descendant session id, while the original session id (the one shown in the exit banner) has zero rows.

hermes --resume <original-id> then loads no history and the user sees a blank chat. The conversation data is not actually lost — it's under another session id — but there's no in-product path to discover that.

Environment

• Hermes Agent v0.10.0 (2026.4.16)
• Python 3.11.13
• macOS Darwin 24.6.0 (Apple Silicon)
• MCP servers in use: grab-manager (stdio), chrome-devtools (stdio), jsreverser (stdio), MongoDB (stdio)

Reproduction

1. Start a chat long enough (or with enough tool output, e.g. chrome-devtools DOM snapshots) to trigger the built-in context compression at least once — the TUI prints ⟳ compacting context….
2. After at least one compression, exit hermes (Ctrl+D / /quit).
3. Exit banner prints:

   Resume this session with:
     hermes --resume <ORIGINAL_SESSION_ID>
   Session:  <ORIGINAL_SESSION_ID>
   Duration: 1h 2m 28s
   Messages: 45 (2 user, 42 tool calls)

4. Run hermes --resume <ORIGINAL_SESSION_ID> → chat opens with empty history.

In my repro the session went through 4 compressions, producing 6 linked sessions. Only the 5th (longest-lived) actually received message rows:

SELECT id, parent_session_id, message_count, end_reason
FROM sessions
WHERE started_at > 1777013052 AND started_at < 1777016000
ORDER BY started_at;

20260424_143733_1abb38 | (null)                 | 0   | compression
20260424_144905_134d65 | 20260424_143733_1abb38 | 0   | compression
20260424_145134_bba836 | 20260424_144905_134d65 | 0   | compression
20260424_145312_a3c90c | 20260424_145134_bba836 | 0   | compression
20260424_145830_389a35 | 20260424_145312_a3c90c | 119 | compression
20260424_153153_efc612 | 20260424_145830_389a35 | 0   | compression

Exit banner pointed at 20260424_143733_1abb38 (0 messages). Actual transcript lives at 20260424_145830_389a35. hermes --resume 20260424_145830_389a35 correctly restores the conversation, confirming the data itself is intact.

Root cause (source-level)

1. Compression creates a new session and resets the flush cursor

run_agent.py:7760-7779:

self._session_db.create_session(
    self.session_id,                       # NEW id
    source=...,
    model=self.model,
    parent_session_id=old_session_id,      # old id becomes parent
)
...
self._last_flushed_db_idx = 0              # flush cursor reset

From this point on, every append_message() writes under the new session_id. The old session row stays at message_count = 0 unless messages were already flushed to it before compression fired.

2. get_messages does not follow the parent chain

hermes_state.py:866-884:

def get_messages(self, session_id: str) -> List[Dict[str, Any]]:
    with self._lock:
        cursor = self._conn.execute(
            "SELECT * FROM messages WHERE session_id = ? ORDER BY timestamp, id",
            (session_id,),
        )

Only the exact session_id is queried — there's no WITH RECURSIVE walk over parent_session_id. So resuming the head of the chain returns zero rows even though descendants hold the history.

3. Exit banner shows the original id, not the final descendant

The banner emits the user-facing "original" session id (before any compression). With (1) and (2), this id is the worst possible one to resume from once compression has happened — it's the only guaranteed-empty one in the chain.

Expected behavior

Either:

• (A) --resume <ID> should walk parent_session_id to reassemble the full transcript, or
• (B) The exit banner should print the id of the last descendant that actually holds the messages (the current self.session_id at exit), so the printed command resumes the right session without the user having to query SQLite.

(B) is the smaller/safer fix. (A) additionally unifies the UX so either the original id or any descendant id resumes the full chain.

Actual behavior

• Exit banner: points at the original pre-compression session id.
• hermes --resume <original-id>: loads 0 messages. User perceives "chat history lost".
• Data is still in the DB under a descendant id, but there's no in-product path to discover that.

Suggested fix

Minimal (Option B)

At exit time, use the live self.session_id (after N compressions = last descendant id) in the banner, not the original id.

More complete (A + B)

1. Make Session.get_messages() walk the chain with a recursive CTE, ordered by timestamp:

   WITH RECURSIVE chain(id) AS (
     SELECT id FROM sessions WHERE id = :root
     UNION ALL
     SELECT s.id FROM sessions s JOIN chain c
        ON s.parent_session_id = c.id OR s.id = (SELECT parent_session_id FROM sessions WHERE id = c.id)
   )
   SELECT * FROM messages WHERE session_id IN chain ORDER BY timestamp, id;

2. Collapse a compression chain into a single logical "conversation" in hermes sessions list so users don't see six rows for one chat.
3. Continue printing the latest descendant id in the exit banner for legacy callers.

Related observation (likely separate bug)

On exit Python emits:

Exception ignored in: <function BaseSubprocessTransport.__del__ at 0x...>
Traceback (most recent call last):
  File ".../asyncio/base_subprocess.py", line 126, in __del__
    self.close()
  ...
RuntimeError: Event loop is closed

Stdio-transport MCP subprocesses (chrome-devtools, grab-manager, jsreverser) aren't closed explicitly before the asyncio loop shuts down, so Python falls back to their __del__ finalizer, which races with an already-closed loop. Harmless (Exception ignored), but cosmetically noisy at every exit. Fix: explicit close() / await exit() on every registered MCP ClientSession in the shutdown path before the loop closes.

Workaround for users hitting this today

# Find the session that actually holds the messages:
sqlite3 $HERMES_HOME/state.db \
  "SELECT id, message_count, datetime(started_at,'unixepoch','localtime')
     FROM sessions
    WHERE message_count > 0
    ORDER BY started_at DESC LIMIT 5;"

# Resume the descendant that actually has the data:
hermes --resume <DESCENDANT_ID>