[Bug]: Opening the same chat in a second Desktop window shows stale history and can send into an out-of-date context (no live sync, no refresh)

[bgexpert]

Summary

When the same chat/session is opened in two Desktop windows (e.g. main Desktop window + a separate window/tab for that same session), the second window does not stay in sync with the live conversation in the first window. There is no refresh button, so the second window simply freezes on the snapshot it loaded when opened.

Worse: if the user types and sends a message in that second window, the agent receives a context that misses everything that happened in the first window after the second window was opened. The user can therefore silently corrupt the conversation context without realizing it.

Steps to reproduce (Hermes 0.18.2, Windows 10)

1. In the main Desktop window, open chat C and exchange several messages (Topic X).
2. Open the same chat C in a second window/tab.
3. Back in the main window, continue the conversation (more messages appear).
4. Look at the second window — it still shows only the snapshot from step 2. No update arrives (there is no refresh control).
5. In the second window, send a new message.
6. Observe: the agent answers based on the stale history (everything from step 3 is missing), because the second window never pulled the live transcript.

Expected behavior

Either (a) the second window live-syncs the same session with the first, or (b) sending in a window holding a stale snapshot is blocked/warned ("this view is out of date — reopen to load latest context").

Actual behavior

The second window silently holds a frozen, partial copy of the session. Sending there injects an out-of-date context, which the user only notices when the agent "forgets" recent turns. This is a data-integrity trap: the user can accidentally split/diverge a single session's context across two windows.

Why this is a bug, not just a feature gap

Related feature requests (multi-window / split-view, e.g. #62806) ask for more windowing. This report is the flip side: the existing ability to open the same session twice actively misleads the user into sending into a stale context, with no UI signal. That's a correctness/UX bug, not a missing feature.

Notes

• Each session is one session_key in state.db; the live agent is bound to a single active lease (active_session_lease, tui_gateway/server.py). A second window reading the same session_key gets a DB snapshot at open time and does not receive the live stream — which explains the freeze. The fix likely needs either shared live state across windows or a stale-view guard before send.
• Distinct from [Bug]: Dashboard cross-tab session bleed + /new hang requiring full container restart #62726 (Dashboard cross-tab bleed — content leaking across tabs) and [Bug]: Session-switch data merging / cross-contamination — can't switch chats cleanly #65005 (session-switch merge on switch). Here the problem is a single session viewed in two places, not two sessions mixing.

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses issue #65047. #66569 implements both peer-window transcript refresh and a submit-time stale-transcript guard, directly preventing sends from an out-of-date Desktop context rather than adding gateway transport fan-out.

Related pull requests

• fix(desktop): block stale multi-window prompt submit #66569 [closed] best fix — (+864/-2) — fixes: fix(desktop): block stale multi-window prompt submit #66569 broadcasts completed-turn hints across Desktop windows, refreshes transcripts on peer notifications or focus, and blocks both composer and session-tile submissions when the authoritative normalized transcript is ahead. Although closed voluntarily to reduce the author's open-PR count, it remains the complete candidate fix; the contributor's keep_open review identified missing owning-profile routing and an unguarded tile-submit path, both of which the subsequent diff explicitly addresses with shared profile-aware guard logic and regression tests.

Suggested consolidation

Merge #66569 after reopening and current-head verification: it is the only PR in this complex and covers the reported stale-view and stale-submit failure modes. Despite the keep_open review on #66569, the final diff addresses both cited blockers—cross-profile transcript reads now use the session-owning profile, and session-tile submissions run the same stale guard—so there are no duplicate PRs to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I65047(["issue #65047 (open)"])
    P66569["PR #66569 (closed)"]
    P66569 -->|best fix| I65047
    class I65047 open
    class I65047 target
    class P66569 closed
    class P66569 best
    click I65047 "https://github.com/NousResearch/hermes-agent/issues/65047"
    click P66569 "https://github.com/NousResearch/hermes-agent/pull/66569"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 40 kB of PR diffs, 4 kB of issue/PR text, 3 kB of discussion (3 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.