hermes - ✅(Solved) Fix TUI `/resume` picker hides WebUI sessions despite them being in state.db [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#15745Fetched 2026-04-26 05:25:22
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Participants
Timeline (top)
labeled ×3cross-referenced ×1

The /resume modal in hermes --tui filters its session list against a whitelist of human conversation surfaces but omits webui, even though WebUI sessions are written to state.db (via sync_to_insights plus the shared AIAgent that backs the WebUI). Conversations started in the official hermes-webui are therefore invisible to the TUI resume picker.

Root Cause

/resume <session-id> and /resume "<title>" already work for WebUI sessions because _resolve_session_by_name_or_id does not apply the source filter — only the unfiltered picker is affected.

Fix Action

Fixed

PR fix notes

PR #15746: fix(tui): include webui in resume-picker allow-list

Description (problem / solution / changelog)

Summary

Closes #15745.

The session.list JSON-RPC handler in tui_gateway/server.py filters its picker output through an allow frozenset whose stated intent (per the inline comment) is to surface human conversation channels and exclude internal sources like tool/acp. webui was missing from the set, so conversations started in hermes-webui — which are written to state.db via sync_to_insights plus the shared AIAgent — were invisible to hermes --tui's /resume modal.

This adds the one missing entry. No behaviour change for any other source.

Diff

                 "cli",
                 "tui",
+                "webui",
                 "telegram",

Test plan

  • Apply the patch on a host with WebUI sessions in state.db (in our case: 6 webui sessions, 554 webui messages).
  • hermes --tui/resume — webui sessions now appear alongside cli/tui/telegram entries.
  • /resume <session-id> and /resume "<title>" continue to work for every source (path was already source-agnostic via _resolve_session_by_name_or_id — unaffected).
  • Maintainer to re-run any TUI integration tests that cover session.list.

Notes

cron is intentionally still excluded — those rows are background runs rather than user conversations and the existing intent of keeping the picker clean still applies.

Changed files

  • tui_gateway/server.py (modified, +1/-0)

Code Example

allow = frozenset(
    {
        "cli", "tui", "telegram", "discord", "slack", "whatsapp",
        "wecom", "weixin", "feishu", "signal", "mattermost", "matrix", "qq",
    }
)
...
rows = [
    s
    for s in db.list_sessions_rich(source=None, limit=fetch_limit)
    if (s.get("source") or "").strip().lower() in allow
][:limit]

---

"cli",
                 "tui",
+                "webui",
                 "telegram",
RAW_BUFFERClick to expand / collapse

Summary

The /resume modal in hermes --tui filters its session list against a whitelist of human conversation surfaces but omits webui, even though WebUI sessions are written to state.db (via sync_to_insights plus the shared AIAgent that backs the WebUI). Conversations started in the official hermes-webui are therefore invisible to the TUI resume picker.

Where

tui_gateway/server.py, the session.list JSON-RPC handler (around line 1577):

allow = frozenset(
    {
        "cli", "tui", "telegram", "discord", "slack", "whatsapp",
        "wecom", "weixin", "feishu", "signal", "mattermost", "matrix", "qq",
    }
)
...
rows = [
    s
    for s in db.list_sessions_rich(source=None, limit=fetch_limit)
    if (s.get("source") or "").strip().lower() in allow
][:limit]

The accompanying comment states the intent is to include human conversation surfaces and exclude internal sources like tool/acp. WebUI sessions match that intent; their omission looks like an oversight.

Reproduction

  1. Start a session via hermes-webui with sync_to_insights: true in webui-state/settings.json.
  2. Run hermes --tui and invoke /resume.
  3. The modal lists CLI / TUI / Telegram sessions, but no WebUI session — even though state.db contains source='webui' rows with full message history (on our deployment: 6 webui sessions, 554 webui messages).

/resume <session-id> and /resume "<title>" already work for WebUI sessions because _resolve_session_by_name_or_id does not apply the source filter — only the unfiltered picker is affected.

Proposed fix

Add "webui" to the allow-set. One-line change; PR follows.

                 "cli",
                 "tui",
+                "webui",
                 "telegram",

Environment

  • hermes-agent main at d635e2df (latest tag v2026.4.23)
  • hermes-webui (nesquena/hermes-webui) deployed natively, sync_to_insights: true
  • Debian 13 (trixie) ARM64

extent analysis

TL;DR

Add "webui" to the allow set in tui_gateway/server.py to include WebUI sessions in the /resume modal.

Guidance

  • Verify that the sync_to_insights setting is true in webui-state/settings.json to ensure WebUI sessions are written to state.db.
  • Check the state.db for rows with source='webui' to confirm that WebUI sessions are being stored correctly.
  • Apply the proposed fix by adding "webui" to the allow set in tui_gateway/server.py to include WebUI sessions in the /resume modal.
  • Test the fix by running hermes --tui and invoking /resume to verify that WebUI sessions are now listed.

Example

allow = frozenset(
    {
        "cli", "tui", "webui", "telegram", "discord", "slack", "whatsapp",
        "wecom", "weixin", "feishu", "signal", "mattermost", "matrix", "qq",
    }
)

Notes

This fix assumes that the issue is solely due to the omission of "webui" from the allow set. If other issues are present, additional debugging may be required.

Recommendation

Apply the workaround by adding "webui" to the allow set, as this is a simple and targeted fix that addresses the specific issue described.

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…

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 - ✅(Solved) Fix TUI `/resume` picker hides WebUI sessions despite them being in state.db [1 pull requests, 1 participants]