Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix [Bug]: CLI command to resume conversation from a previous session. [1 participants]

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…
GitHub stats
NousResearch/hermes-agent#11792•Fetched 2026-04-18 05:58:50
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
TanMan-CALTanMan-CAL
Participants
TanMan-CALTanMan-CAL
Timeline (top)
closed ×1labeled ×1

When running a single-shot query with hermes chat --quiet -q "...", Hermes prints a session_id: line but does not save the conversation history to SQLite. As a result, passing that session ID to --resume on the next call starts a completely fresh session with no memory of the prior turn.

Root Cause

When running a single-shot query with hermes chat --quiet -q "...", Hermes prints a session_id: line but does not save the conversation history to SQLite. As a result, passing that session ID to --resume on the next call starts a completely fresh session with no memory of the prior turn.

Code Example

# Turn 1, send a message and capture the session ID
hermes chat --quiet -q "My favourite colour is blue and I hate red."

echo "Session ID: $SESSION_ID"

# Turn 2, resume and ask about the prior turn
hermes chat --quiet --resume "$SESSION_ID" -q "What is my favourite colour?"

---

(clarify timed out after 120s — agent will decide)
I don't have any information about your colour preferences.
session_id: 20260417_162721_1bf485

---

hermes chat --quiet --resume 20260417_162721_1bf485 -q "What did we talk about in this session?"
# Response: "So far we've only exchanged a brief introductory exchange..."

---
RAW_BUFFERClick to expand / collapse

Bug: hermes chat --quiet -q does not persist conversation to SQLite, breaking --resume multi-turn

Summary

When running a single-shot query with hermes chat --quiet -q "...", Hermes prints a session_id: line but does not save the conversation history to SQLite. As a result, passing that session ID to --resume on the next call starts a completely fresh session with no memory of the prior turn.

Steps to Reproduce

# Turn 1, send a message and capture the session ID
hermes chat --quiet -q "My favourite colour is blue and I hate red."

echo "Session ID: $SESSION_ID"

# Turn 2, resume and ask about the prior turn
hermes chat --quiet --resume "$SESSION_ID" -q "What is my favourite colour?"

Expected Behavior

Turn 2 should answer "blue" from the conversation history saved in turn 1.

Actual Behavior

Turn 2 responds as if no prior conversation exists:

(clarify timed out after 120s — agent will decide)
I don't have any information about your colour preferences.
session_id: 20260417_162721_1bf485

Confirmed by asking directly:

hermes chat --quiet --resume 20260417_162721_1bf485 -q "What did we talk about in this session?"
# Response: "So far we've only exchanged a brief introductory exchange..."

Proposed Solution

FIX: hermes chat --quiet -q should flush the full conversation (both the user message and the assistant response) to SQLite before exit, identical to how interactive mode persists sessions. The printed session_id: implies persistence is intended as the write just isn't happening.

Alternatives Considered

No response

Feature Type

New tool

Scope

None

Contribution

  • I'd like to implement this myself and submit a PR

Debug Report (optional)

extent analysis

TL;DR

The issue can be resolved by modifying the hermes chat --quiet -q command to persist the conversation history to SQLite, similar to interactive mode.

Guidance

  • Verify that the conversation history is not being saved to SQLite by checking the database after running hermes chat --quiet -q.
  • Check the code for hermes chat --quiet -q to see if there is a conditional statement that prevents the conversation history from being saved to SQLite.
  • Modify the hermes chat --quiet -q command to flush the full conversation to SQLite before exit, as proposed in the issue.
  • Test the modified command to ensure that the conversation history is being saved correctly and that the --resume option works as expected.

Example

No code snippet is provided as the issue does not include the relevant code.

Notes

The issue implies that the hermes chat --quiet -q command is intended to persist the conversation history to SQLite, but it is not doing so. The proposed solution is to modify the command to flush the full conversation to SQLite before exit.

Recommendation

Apply workaround: Modify the hermes chat --quiet -q command to persist the conversation history to SQLite, as this is the most direct way to resolve the issue and ensure that the --resume option works correctly.

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…
#ssr#conversation history#memory leak#API versioning#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: CLI command to resume conversation from a previous session. [1 participants]