Bug: "Session Zombie" queue lock and UI state leaks during session switching in Desktop App

[Thewind777]

Bug Description

There are two critical state-handling bugs present in the Hermes Desktop App:

1. Session Zombie Queue Lock: When a concurrent session limit is enforced (e.g., set to 2), stopping or finishing a task fails to clear the backend slot. The app continues to treat stale sessions as active, locking the queue and blocking new prompts.
2. Session Visual Merging / State Leak: When switching between tabs in the left sidebar—especially while a session is busy or a follow-up is queued—the chat interface glitches and "merges" the sessions. The active message view from one session leaks directly into the other. This requires multiple refreshes or completely restarting the desktop application to get the views isolated again.

Steps to Reproduce

1. Go to Settings in the Hermes Desktop App and set the concurrent session limit to 2.
2. Open and run two separate sessions with active prompts.
3. While Session A is busy or actively handling an output/follow-up, click on Session B in the left sidebar.
4. Observe the interface glitch: Session B's view will incorrectly display or blend with Session A's chat content.
5. Stop both sessions and attempt to start a third; observe that the concurrent limit acts as though both slots are still fully occupied.

Expected Behavior

When a session is stopped, finished, or idle with no active background processes running, the gateway should release its slot immediately, updating the concurrent session counter so that new slots open up for execution.

Actual Behavior

The desktop app frontend locks up and refuses new input due to ghost session counters. Concurrently, session context boundaries break down in the UI layer during sidebar navigation. The chat history from separate sessions visually merges together, forcing the user to repeatedly restart the application and force-refresh to fix the UI rendering.

Affected Component

CLI (interactive chat)

Messaging Platform (if gateway-related)

No response

Debug Report

Report       https://paste.rs/4OPiZ
  agent.log    https://paste.rs/jMG8C
  gateway.log  (Logs have been temporarily removed to redact exposed plain-text API credentials.)
  gui.log      https://paste.rs/B0koo
  desktop.log  (Logs have been temporarily removed to redact exposed plain-text API credentials.)

Operating System

Windows 11

Python Version

3.11.15

Hermes Version

0.18.2

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

This points to an issue where session-scoped UI rendering and background workers are not keyed strongly enough by the unique session_id in the Electron layer (specifically around use-prompt-actions.ts or the active streaming subscriptions). When a user switches sessions or hits "stop," stale asynchronous stream updates continue pushing data to the active viewport, and dropped WebSocket signals leave dirty "active" flags inside ~/.hermes/state.db.

Proposed Fix (optional)

1. Queue Sticking: Implement a definitive cleanup hook or timeout handler within the desktop client's IPC/WebSocket wrapper (use-prompt-actions.ts) that catches termination, error, or idle signals. If a user interrupts a running turn, it must explicitly dispatch a state cleanup mutation to ensure the active session flags in the local SQLite database (~/.hermes/state.db) drop back down to 0 immediately.

2. UI Visual Merging: Scope the chat viewport context strictly to the selected session_id. When switching sidebar tabs, immediately unmount or purge the state of the active message thread/composer component rather than letting background asynchronous streaming events continuously append updates to a shared, dirty UI viewport.

Are you willing to submit a PR for this?

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

[johncrash64]

I hit this on a multi-session workload and traced it to a concrete root cause in the renderer's gateway-event dispatcher. Posting the analysis here since this is the highest-severity of the three related issues (#56390, #46194, this one all describe the same bug class).

Root cause: unscopedStreamSessionId is a single shared ref across all concurrent sessions

File: apps/desktop/src/lib/gateway-events.ts
Function: resolveGatewayEventSessionId (lines 107–120)
The shared ref: useRef<string | null>(null) in apps/desktop/src/app/session/hooks/use-message-stream/gateway-event.ts:116

// gateway-events.ts:107-127 (current)
const sessionId =
  eventType === 'message.start'
    ? activeSessionId
    : streamEvent
      ? unscopedStreamSessionId || activeSessionId   // ← bug
      : activeSessionId

let nextUnscopedStreamSessionId = unscopedStreamSessionId

if (eventType === 'message.start' && activeSessionId) {
  nextUnscopedStreamSessionId = activeSessionId       // ← overwrites the shared ref
} else if (eventType && UNSCOPED_STREAM_END_EVENT_TYPES.has(eventType)) {
  nextUnscopedStreamSessionId = null
}

unscopedStreamSessionId is one module-level ref shared across every concurrent session streaming through the same handleGatewayEvent callback. When session A starts streaming (message.start), the ref is set to A. When session B starts streaming before A finishes, the ref is overwritten to B. Any subsequent unscoped stream event from A (delta/tool/reasoning) now resolves to B.

This explains the "Session Visual Merging / State Leak" half of this issue: when the active session's transcript receives a delta that belongs to a different concurrent stream, the message list mutations are keyed to the wrong runtime id and the UI grafts content across sessions.

Why it hasn't been caught (latent today, triggers under specific conditions)

The Python backend (tui_gateway/server.py:1187-1191) always stamps session_id on emitted events:

def _emit(event: str, sid: str, payload: dict | None = None):
    params = {"type": event, "session_id": sid}
    ...

So the happy path hits the first if (explicitSessionId) branch and the unscoped fallback is never reached. The bug becomes visible only when:

• An event is emitted without session_id (global error broadcasts, plugin-emitted events, race conditions during reconnect/replay)
• The queue drains a follow-up message while a session switch is mid-flight (interacts with [Bug]: Queued messages can fire into the wrong session when switching between concurrent sessions (Desktop only) #56390)
• Auto-compression or session.info heartbeats arrive between message.start and message.complete

Reproduction

1. Open 3+ chat sessions in the Desktop app
2. Start long-running prompts in sessions A and B simultaneously
3. Switch between them while both are streaming
4. Trigger any path that emits an unscoped event (e.g. reconnect the gateway mid-stream, trigger a global error)
5. Deltas/tool events from one session briefly paint onto the other's transcript

Proposed fix

Replace the single shared ref with a per-session map keyed by runtime session id, so each concurrent stream tracks its own "last seen" session:

// In use-message-stream/gateway-event.ts:
const unscopedStreamSessionByRuntimeRef = useRef<Map<string, string>>(new Map())

// In resolveGatewayEventSessionId (gateway-events.ts):
// Look up the active session's pinned stream owner; fall back to activeSessionId
// only when no pin exists. Each session maintains its own pin.

Alternative conservative fix: since the backend always provides session_id in practice, drop unscoped stream events when activeSessionId is null or when a concurrent stream is in flight.

Related renderer errors during the same reproduction

[hermes] [renderer console] Uncaught Error: useClientLookup: Index 14 out of bounds (length: 1)
[hermes] [renderer console] Uncaught Error: Composer is not available

The useClientLookup race is upstream (assistant-ui/assistant-ui#4051, #3652) and Hermes already has MessageRenderBoundary as a palliative — but that boundary swallows the crash without addressing why the message list mutated mid-render in the first place. The unscopedStreamSessionId race above is what produces the inconsistent snapshot the boundary then has to catch.

DB-level verification (important)

I verified the SQLite store is not contaminated: every messages row has the correct session_id, integrity_check passes, FTS5 passes, and there are zero orphaned or duplicated messages across sessions. The bug is purely renderer-side attribution of in-flight events — the persisted data stays correct. So the "context loss" symptom is a view-layer artifact, not actual data corruption, and a session resume / window refresh recovers the correct transcript.

Related issues

• [Bug]: Queued messages can fire into the wrong session when switching between concurrent sessions (Desktop only) #56390 — Queued messages fire into wrong session (drains the queue into whatever is focused)
• [Bug]: Desktop session switch leaks queued follow-up state and can show wrong chat contents #46194 — Session switch leaks follow-up state + shows wrong chat
• All three describe the same underlying race. Consolidating the fix here would close all of them.

Happy to open a PR with the per-session map fix if a maintainer confirms the direction.

[linfeng961]

Confirmed reproducible on Windows 10 (Hermes Desktop v0.19.0, commit 8208fc5) with the same symptom described in #56390:

1. Have two sessions running concurrently (both with active prompts).
2. In session A, while the agent is busy, type a message and press Ctrl+Enter to queue it.
3. Switch to session B before the queue drains.
4. The queued message from session A is delivered into session B instead of A.

This happened twice consistently. The queue routes to whatever session is currently focused at flush time, not the session where the message was originally queued.

Windows-specific environment: i5-10600KF, AMD RX 580, backend connected via opencode-go provider (DeepSeek v4 Flash). Happy to provide additional debug info if needed.