Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: Session loaded with --session not marked as active in Gateway sessions.json [1 pull requests, 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#14501•Fetched 2026-04-24 06:16:52
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
yishengmoliyishengmoli
Participants
yishengmoliyishengmoli
Timeline (top)
labeled ×4cross-referenced ×1

Root Cause

The CLI uses NoGatewayAIAgent (direct API calls without going through Gateway), so when a session is loaded via --session, the Gateway's sessions.json is never updated with the new process_id or last_active timestamp. The session appears inactive in the Web UI despite being actively used.

Fix Action

Fixed

PR fix notes

PR #14516: fix(session): mark resumed CLI sessions active before next message

Description (problem / solution / changelog)

Summary

  • route --session resume through SessionDB.reopen_session() instead of an ad-hoc SQL update
  • persist an explicit last_active_at timestamp for resumed sessions
  • use that timestamp when computing rich session activity so the Web UI marks resumed sessions as live before the next user message

Root cause

hermes --session <id> reopened the session by only clearing ended_at/end_reason. For sessions with existing history, list_sessions_rich() derived last_active from the latest message timestamp, which stayed stale until the next turn. That made resumed CLI sessions look inactive in the Web UI.

Fix

  • add last_active_at to sessions with a migration/backfill from started_at
  • update reopen_session() to refresh last_active_at
  • make the rich-session queries use the newer of message activity and explicit resume activity
  • reuse reopen_session() in the CLI --session preload path

Regression coverage

  • add a SessionDB regression test proving reopen_session() refreshes last_active even when the session already has older messages
  • update the CLI resume test to assert --session goes through reopen_session()
  • extend schema migration coverage for the new last_active_at backfill

Testing

  • scripts/run_tests.sh tests/test_hermes_state.py::TestListSessionsRich::test_reopen_session_refreshes_last_active_over_old_messages tests/cli/test_resume_display.py::TestPreloadResumedSession::test_reopens_session_in_db
  • scripts/run_tests.sh tests/test_hermes_state.py tests/cli/test_resume_display.py

Closes #14501

Changed files

  • cli.py (modified, +2/-7)
  • hermes_state.py (modified, +32/-17)
  • tests/cli/test_resume_display.py (modified, +1/-7)
  • tests/test_hermes_state.py (modified, +26/-3)

Code Example

version: 0.10.0 (2026.4.16) [fa8f0c6f]
os: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
python: 3.11.15
model: MiniMax-M2.7
provider: minimax-cn
gateway: running (manual, pid 2637)
platforms: feishu, weixin
skills: 111
RAW_BUFFERClick to expand / collapse

Bug Description

When a user loads a previous session using hermes --session <id> in a new CLI process, the Gateway's sessions.json does not update the session's last_active timestamp or register the new process_id. This causes the Web UI "聊天" tab to show stale/incorrect session info, while "实时" tab still works (it reads .jsonl files directly).

Root Cause

The CLI uses NoGatewayAIAgent (direct API calls without going through Gateway), so when a session is loaded via --session, the Gateway's sessions.json is never updated with the new process_id or last_active timestamp. The session appears inactive in the Web UI despite being actively used.

Steps to Reproduce

  1. Start hermes CLI → creates session A → chat for a bit → exit CLI
  2. Start hermes CLI again → load session A using hermes --session <id>
  3. The session continues in Web UI "实时" tab, but "聊天" tab does not show it as active

Expected Behavior

Loading a session should register it as active in Gateway's sessions.json so both Web UI "聊天" tab and "实时" tab correctly show the session as active.

Debug Info

version: 0.10.0 (2026.4.16) [fa8f0c6f]
os: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
python: 3.11.15
model: MiniMax-M2.7
provider: minimax-cn
gateway: running (manual, pid 2637)
platforms: feishu, weixin
skills: 111

extent analysis

TL;DR

Update the Gateway's sessions.json when loading a session via hermes --session <id> to reflect the new process ID and last_active timestamp.

Guidance

  • Investigate modifying the NoGatewayAIAgent to update the Gateway's sessions.json when a session is loaded via --session.
  • Verify that the sessions.json file is being updated correctly by checking its contents after loading a session.
  • Consider adding logging to track when a session is loaded and when the sessions.json file is updated to help diagnose any issues.
  • Review the Web UI code to ensure it is correctly reading the sessions.json file and updating the "聊天" tab accordingly.

Example

# Pseudo-code example of updating sessions.json when loading a session
def load_session(session_id):
    # Load session using NoGatewayAIAgent
    session = load_session_using_api(session_id)
    # Update sessions.json with new process ID and last_active timestamp
    update_sessions_json(session_id, get_current_process_id(), get_current_timestamp())

Notes

The provided information suggests that the issue is related to the NoGatewayAIAgent not updating the Gateway's sessions.json when a session is loaded via --session. However, without more information about the implementation of NoGatewayAIAgent and the Gateway's API, it is difficult to provide a more specific solution.

Recommendation

Apply workaround: Modify the NoGatewayAIAgent to update the Gateway's sessions.json when a session is loaded via --session, as this is the most direct way to address the issue.

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…
#api#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING