Desktop: message queued in a busy session is delivered to an unrelated idle session

[LeighAtVT]

Summary

On the desktop app, a message queued/composed for one busy session was delivered to a different, unrelated session — the one that had most recently gone idle/focused. The user got no indication it landed in the wrong thread; the wrong session executed the message with full tool access. This has happened to this user multiple times ("when I have something queued in one thread, it will sometimes post in an unrelated thread").

Environment

• Hermes Agent 0.18.2 (git install), desktop app 0.0.1 (Hermes.app)
• macOS 26.5.2 (build 25F84)
• Platform: desktop (both deliveries tagged platform=desktop in agent.log)
• Model: claude-fable-5 / anthropic

Evidence (from ~/.hermes/logs/agent.log and state.db)

The user composed a message intended for a long-running work session (20260708_151656_007b80, 369 messages, actively mid-task). Instead it was delivered to an unrelated session (20260709_113746_44b749, a config-discussion thread) that had gone idle ~2 minutes earlier:

2026-07-09 11:46:24,927 INFO [20260709_113746_44b749] agent.turn_context: conversation turn:
  session=20260709_113746_44b749 model=claude-fable-5 provider=anthropic platform=desktop
  history=27 msg='you can probably look in posthog too, to find evidence of where they look, and w...'

2026-07-09 11:48:19,302 INFO [20260708_151656_007b80] agent.turn_context: conversation turn:
  session=20260708_151656_007b80 model=claude-fable-5 provider=anthropic platform=desktop
  history=369 msg='you can probably look in posthog too, to find evidence of where they look, and w...'

The 11:48:19 delivery is NOT the app self-correcting — it is the user manually re-sending the same message to the correct thread after noticing the misfire. Without that manual catch, the intended session would never have received the message.

Timeline context: the receiving (wrong) session's previous turn completed at ~11:44; the intended session was busy mid-turn when the message was sent at 11:46.

Impact

1. Silent cross-thread contamination — the wrong session treats the message as an on-topic instruction and acts on it with full tool access. In this case it burned several minutes of redundant read-only DB/analytics queries; the sharper risk is an approval-shaped message ("yes, go ahead") landing in a session that is waiting to approve something else entirely.
2. Silent message loss for the intended thread — the busy session never receives the queued message unless the user notices and re-sends manually.
3. No UI indication that delivery went somewhere other than where the user typed it.

Repro shape (not 100% deterministic — "sometimes")

1. Have two desktop sessions: A (busy, mid-turn on a long task) and B (idle).
2. Type/queue a message in session A while it is working.
3. Sometimes the message is delivered as a new turn in session B instead of being queued for A.

Happy to provide additional log context or run a diagnostic build — the misfire recurs often enough for this user that a debug-instrumented repro is feasible.

[falkoro]

Triage note: this looks like the exact failure mode addressed by the open PR #57849 ("drain queued prompts for background sessions"). Root cause there: the desktop queue drainer lived only inside the mounted ChatBar and submitted into the currently selected session — so a prompt queued in busy Session A could drain into whatever session was foreground by the time A went idle, i.e. "delivered to an unrelated idle session". #57849 threads explicit sessionId/storedSessionId through the queued-submit path so a drain always targets its source session, and pins it with a regression test ("a fromQueue drain sends to its queued session even after the active session changes").

@teknium1 worth linking these — if the reporter can still reproduce on a build containing #57849, that's important review input for that PR; if not, this is likely a duplicate it resolves.

[re-ITRT]

Confirmed still reproducible on latest main (d7b3607), with a reliable repro path involving the Messaging sidebar tab:

Repro:

1. Session A running (busy), type a follow-up message and send → queued
2. Click "Messaging" in sidebar (ChatBar unmounts, UI freezes briefly)
3. Navigate back — clicking Session A is unresponsive; switch through Session B first
4. Session B executes the queued message meant for Session A

Log evidence (instrumented submit.ts):

[SUBMIT] targetStored: 20260705_182729_3bd374 (= Session A)
         sessionId: 7ec2f72e                     (= Session B runtime!)
         fromQueue: true

The queue correctly enqueued to Session A, but submit.ts:152 received Session B's runtime ID because runtimeIdByStoredSessionIdRef returned the wrong mapping. After Messaging tab navigation, the stored-session→runtime map appears to be stale/corrupted for the originating session.

#57849 is merged but does not cover this trigger path. The drain correctly carries targetStoredSessionId, but when runtimeIdByStoredSessionIdRef.current.get(sessionKey) returns the wrong runtime ID, submit.ts silently routes to the wrong session.

I'll attempt a fix and report back.