bug(desktop): new-session composer prefilled with another session's first input (draft cross-session leak)

[Cozieur]

Problem

When opening a new chat session in Hermes Desktop, the composer is pre‑filled with text that was the first input of a different (previous) session — not an empty box, and not the user's own __new__ draft. The user must manually clear it before typing.

This is not the intended per‑session draft‑restore behavior. A brand‑new session should start empty (or with the user's own __new__ bucket, which should be empty).

Environment

• Hermes.app: 0.17.0 (install‑stamp builtAt: 2026-07-12T07:05:57Z, commit: 2043436af, source: local)
• CLI: 0.18.2
• macOS (host reports 26.6)
• Reproduced with Chinese IME, but the leak is language‑independent.

Suspected root cause (from source inspection)

Draft storage is a single localStorage map keyed by session scope:

• apps/desktop/src/store/composer.ts:27 — SESSION_DRAFTS_STORAGE_KEY = 'hermes:composer-drafts:v3'
• apps/desktop/src/store/composer.ts:29 — NEW_SESSION_DRAFT_KEY = '__new__'
• apps/desktop/src/store/composer.ts:38 — draftKey(scope) falls back to __new__ when scope is empty/whitespace; keys otherwise by activeQueueSessionKey.

The per‑thread swap lives in useComposerDraft:

• apps/desktop/src/app/chat/composer/hooks/use-composer-draft.ts:309-331 — on activeQueueSessionKey change it does takeSessionDraft(activeQueueSessionKey) → loadIntoComposer(text, attachments).
• apps/desktop/src/app/chat/composer/hooks/use-composer-draft.ts:222-262 — the composerRuntime.subscribe(sync) debounced stash (DRAFT_PERSIST_DEBOUNCE_MS) writes draftRef.current under draftScopeRef.current.
• apps/desktop/src/app/chat/composer/hooks/use-composer-draft.ts:90-91, 237 — draftScopeRef is meant to track "the session whose text is actually loaded in the editor" to avoid a session‑switch‑mid‑flight writing one session's draft under another's key (Bug: Gateway message routing misdirects user input between TUI sessions -- prompt permanently lost #54527).

The cross‑session prefill indicates the scope/key used at stash or restore time does not match the actually‑visible session in some transition (new‑session creation, rapid session switch, or a thread swap where activeQueueSessionKey is briefly null/empty and resolves to __new__ but the restored text came from a real session id). Worth checking the takeSessionDraft key path against the key used when the outgoing session was stashed, especially around the __new__ bucket.

Workaround (verified)

Desktop Cmd+Option+I → Console:

localStorage.removeItem('hermes:composer-drafts:v3')

then restart Hermes.app. The prefill disappears (clears cached drafts only; sent messages untouched). The leak recurs until the root cause is fixed.

Suggested fix direction

Audit the session‑key passed to stashSessionDraft / takeSessionDraft across the new‑session transition and rapid switches; ensure a freshly created session never restores a real session id's draft, and that the __new__ bucket is only ever written with the user's in‑progress (unsent) new‑chat text.

[anshuS1310]

Hello I want to know why this is marked as bug as hermes agent was build with the aim for keeping the memory of the previous session so that this agent can know about you more and can answer your next question with more refrence about you or according to ? Because cross section was not there in earlier in any chatbot

[GottZ]

This was generated by AI during triage.

Summary

No pull requests currently address or reference #63054. The issue reports a persisted-session-to-new-session composer prefill, while related issue #66662 identifies a shared __new__ key causing bleed specifically between unsaved new chats; the provided evidence does not establish that #66662's mechanism causes #63054.

Suggested consolidation

No PR is available to merge or close as a duplicate. Keep #63054 open pending a reproducer or diff that establishes its actual cause; track #66662 as a related new-session draft-leak report, but do not consolidate their root causes without evidence connecting the shared __new__ key to #63054's persisted-session leak.

Cross-PR triage: Reviewed 0 pull requests and 2 issues in this complex. Assessment working set: 0 kB of PR diffs, 4 kB of issue/PR text, <1 kB of discussion (2 comments), 0 verify verdicts. verdicts are based on issue/PR descriptions and structural graph facts — diffs were not available at assessment time. Part of an automated triage batch.