Bug Description

In Hermes Desktop, a session that can be found via session search can be pinned, but it does not appear in the pinned section if that session is hidden from the normal loaded session list.

This happened with a Desktop session titled desktop ui bug. The session is searchable, and the UI allows pinning it from the search result, but the pinned section does not show it afterward.

This appears to affect sessions that exist in state.db but are not included in the normal sidebar/session list, such as sessions with a parent_session_id relationship.

Steps to Reproduce

1. Have a Hermes Desktop session that is discoverable via session search or direct session lookup, but absent from the normal loaded sidebar session list.
   • One example is a child/continuation session hidden by the normal sidebar list query.
2. In Desktop, find that session through session/sidebar search.
3. Pin the session from the search result.
4. Reload or restart Desktop.
5. Look at the pinned section in the Desktop sidebar.

Expected Behavior

The pinned session should appear in the pinned section after it is pinned, even if it was discovered through search and is not part of the normal loaded session list.

Pinned sessions should be renderable by session ID, either by hydrating the pinned session record or by including pinned hidden/search-result sessions in the pinned-session data source.

Actual Behavior

The session can be found through search and pinned, but it does not appear in the pinned section.

The pin appears to be stored, but the pinned section only renders sessions that can be resolved from the normal loaded $sessions list. Since this searched session is hidden from that list, the pinned row has nothing to render.

Affected Component

Other

Hermes Desktop / apps/desktop session sidebar, session search, and pinned sessions.

Messaging Platform

N/A

Debug Report

Collected with:

hermes debug share --local

Relevant redacted dump:

version:          0.15.1 (2026.5.29) [bb0619db]
os:               Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
python:           3.11.15
openai_sdk:       2.24.0
profile:          default
hermes_home:      ~/.hermes
model:            gpt-5.5
provider:         openai-codex
terminal:         local

features:
  toolsets:           hermes-cli
  mcp_servers:        0
  memory_provider:    built-in
  gateway:            running (systemd (user))
  platforms:          telegram
  cron_jobs:          0
  skills:             93

config_overrides:
  agent.max_turns: 150
  display.streaming: True

Note: hermes debug share --local also printed recent local logs. I am not pasting those full logs here because they include unrelated conversation/tool output and local session details; no traceback was observed for this UI/state rendering bug.

Operating System

Ubuntu 24.04.4 LTS under WSL2 on Windows

Python Version

Python 3.11.15

Hermes Version

Hermes Agent v0.15.1 (2026.5.29)
Project: /home/fermin/.hermes/hermes-agent
Python: 3.11.15
OpenAI SDK: 2.24.0

The local installed CLI reported it was a couple commits behind when first checked, but the fork clone used for investigation has since been fast-forwarded to upstream main at b34ee8074.

Additional Logs / Traceback

No traceback observed. This is a UI/state rendering bug.

Relevant local session DB evidence:

Session:
  id: 20260602_133018_d1c043
  title: desktop ui bug
  parent_session_id: 20260602_132539_deeae3
  started: 2026-06-02 13:30:18
  end_reason: null
  message_count: 55

Parent:
  id: 20260602_132539_deeae3
  title: Hermes Desktop Scroll Bugs
  end_reason: compression
  ended: 2026-06-02 13:42:17

The session is searchable, but it is not shown in the normal sidebar list / pinned section.

Root Cause Analysis

Likely cause:

• Session search can return sessions that are not present in the normal loaded session list.
• Pinning from the search result stores the session ID.
• The pinned section appears to render pinned sessions by resolving pinned IDs against the currently loaded $sessions list.
• If the pinned session is not in $sessions, the pinned section cannot render it.

Possible related files/areas:

apps/desktop/src/app/chat/sidebar/
apps/desktop/src/store/session.ts
apps/desktop/src/hermes.ts

The deeper cause of why this session is hidden may be a separate bug: this session has a parent_session_id even though it was reportedly opened as a normal new thread, not intentionally as a branch/subthread. This issue is specifically about the pin rendering failure for search-found hidden sessions.

Proposed Fix

When pinning a session from search results, the Desktop UI should be able to render that pinned session even if it is not currently present in the normal loaded session list.

Possible approaches:

1. Hydrate pinned session IDs from the backend before rendering the pinned section.
2. Merge search-result session records into the session store when they are pinned.
3. Change the pinned section to render from a dedicated pinned-session source rather than only from $sessions.

A regression test should cover:

1. A session is returned by search.
2. The session is not present in the normal loaded session list.
3. The user pins the search result.
4. The pinned section renders the pinned session.