hermes - 💡(How to fix) Fix bug: /sessions does not show previous sessions after TUI restart

Bug Description

The /sessions slash command in the Hermes TUI only shows sessions that have live in-memory agents. It does not show historical sessions that were persisted to the database when the TUI was closed and restarted.

Steps to Reproduce

1. Run hermes --tui and start a conversation in a session
2. Close the TUI (let the process exit)
3. Restart the TUI: hermes --tui
4. Run /sessions in the new TUI instance
5. Observe: the previous session is not shown
6. However, hermes sessions list in a separate terminal does show the session
7. Using /resume <session_id> (copied from hermes sessions list) correctly resumes the session

Expected Behavior

/sessions should show sessions that the user can resume, including sessions persisted from previous TUI runs. The user should not need to know to manually copy session IDs from hermes sessions list.

Actual Behavior

/sessions shows an empty or "no sessions" state even when historical sessions exist in the database. Only sessions with live in-memory agents (within the same TUI process) are shown.

Technical Details

This is a design mismatch between two separate session systems:

The session.active_list handler in tui_gateway/server.py:2568-2586 only iterates over _sessions.items() — the live in-memory session registry. It intentionally does not query the historical DB.

# tui_gateway/server.py:2568 - session.active_list
@method("session.active_list")
def _(rid, params: dict) -> dict:
    # Only returns sessions that exist in _sessions in-memory dict
    snapshot = list(_sessions.items())
    rows = [_session_live_item(sid, session, current) for sid, session in snapshot]
    return _ok(rid, {"sessions": rows})

session.list (used by /resume picker and hermes sessions list CLI) queries the SQLite DB and correctly shows persisted sessions.

Root Cause

The /sessions command was designed exclusively for switching between live in-memory sessions within a single TUI process (for features like spawning sub-agents). It was not designed as a historical session browser.

The UX problem: users expect /sessions to be the command for listing and switching sessions (matching the CLI hermes sessions list), but it silently shows nothing because there are no other live sessions after a restart.

Suggested Fix (Directional)

One of:

1. Change /sessions to use session.list (DB) instead of session.active_list — make it a true session browser matching hermes sessions list
2. Or: When session.active_list returns empty, fall back to session.list and show a message: "No other live sessions. Found X historical sessions — use /resume to browse them."
3. Or: Add a flag to /sessions like /sessions --all that includes historical sessions

Option 1 seems most aligned with user expectations.

Investigation Notes

• /sessions is defined in ui-tui/src/app/slash/commands/session.ts:95-106 — calls patchOverlayState({ sessions: true })
• The sessions overlay uses ActiveSessionSwitcher component, which calls session.active_list RPC (activeSessionSwitcher.tsx:265-267)
• session.activate handler at server.py:2589-2622 attaches frontend to a live session — only works for in-memory sessions
• /resume (no arg) uses SessionPicker which calls session.list (DB query) — correctly finds historical sessions
• The hermes sessions list CLI command uses session.list from hermes_cli/commands.py

Environment

• Hermes Agent: latest (main branch, 75cd420b3)
• Interface: interactive CLI / TUI slash command
• OS: Linux