hermes - 💡(How to fix) Fix Bug: session search/browse can hide recently submitted prompt as zero-message session [2 pull requests]

Summary

A user-submitted prompt appeared to be missing from Hermes session history. The session browser/search initially reported the session as having zero messages and an empty preview, causing the agent to conclude the prompt was unrecoverable. Later, a different search path recovered the full user prompt from the same session.

This is unacceptable UX for an agent runtime: submitted user input must be durably persisted before/while execution begins, and recovery tools must not present a persisted prompt as missing.

Environment

• Hermes Agent: v0.15.1 (2026.5.29)
• Source: TUI session
• OS: Windows 10
• Python: 3.11.15
• Session store: SQLite/FTS via Hermes state.db
• Active profile: default

Observed evidence

Affected session:

• Session ID: 20260605_153449_7bf782
• Title: Audit Hermes wrt Codex & Memory
• Source: tui

Initial recovery attempt via session browse returned this session with:

• message_count: 0
• empty preview

That led the agent to report that the exact prompt could not be recovered.

However, hermes sessions list later showed the same session with a preview:

Audit Hermes wrt Codex & Memor   Do another round of audit to see how H   2m ago        20260605_153449_7bf782

And an FTS/session discovery query later recovered the full user prompt, with user message ID 412 and subsequent assistant/tool-call messages.

Actual behavior

Different session recovery paths disagreed:

1. Browse-style session search said the session had zero messages and no preview.
2. CLI session list showed a non-empty preview.
3. FTS discovery recovered the full user prompt and assistant tool calls.

This made a live assistant incorrectly tell the user their prompt was missing/unrecoverable.

Expected behavior

• Once a user submits a prompt, Hermes should durably persist it before model/tool execution begins.
• All session listing/search/browse APIs should agree on whether a session has messages.
• A session with persisted messages must never be exposed as message_count: 0 / empty preview.
• If an interrupted/failed run leaves partial state, recovery UI should still show the submitted user prompt.
• If there is eventual consistency or delayed indexing, APIs should surface that state explicitly instead of reporting zero messages.

Reproduction shape

The exact trigger is not fully isolated yet, but the live sequence was:

1. User submitted a long audit prompt in TUI.
2. Hermes began working and emitted tool calls.
3. User later asked where the prompt went.
4. Agent used session browse/search and saw session 20260605_153449_7bf782 as empty / zero messages.
5. Later, hermes sessions list and FTS discovery found the prompt in the same session.

This suggests a bug in one or more of:

• session browse metadata aggregation,
• message_count/preview computation,
• FTS/index freshness,
• transaction ordering between session rows and messages,
• TUI session finalization/interrupt handling,
• or session_search browse mode reading a stale/incomplete source compared with CLI list/discovery.

Impact

High. Losing or appearing to lose user input breaks trust and can cause duplicated work. For long prompts, the user may not be able to reconstruct the exact request.

Suggested fixes / checks

• Add an invariant test: any session surfaced by browse with an ID must have message_count/preview consistent with direct message table counts and CLI sessions list.
• Add an integration test for interrupted/rapidly followed TUI prompts: user message must exist before assistant/tool calls begin.
• Ensure browse mode and discovery mode use the same canonical session/message source or share consistency checks.
• If session title generation happens before message persistence, make message persistence the first durable write after submit.
• Add a warning/diagnostic if a session has assistant/tool-call rows but browse reports zero user messages.

Privacy

No secrets or credentials are included in this report. The recovered prompt was task text only.