[Bug]: Desktop composer not ready on new session — first Enter fails, message stays in input, needs second send

[bgexpert]

Description
In Hermes Desktop (Windows 10, build from 2026-07-12, version files 0.18.2), when opening a new chat (or switching sessions) and sending the first message:

1. The message text from the previous chat remains visible in the composer input field.
2. Pressing Enter the first time does nothing — the message stays in the input and is not sent.
3. Pressing Enter a second time sends the message and clears the input; after that the chat works normally.

Reproduces 100% of the time on the first message of every new session.

Root cause (from logs + bundle analysis)
desktop.log contains:

[hermes] [renderer console] Uncaught Error: Composer is not available
(file:///.../win-unpacked/resources/app.asar/dist/assets/index-BK_BHFlU.js:4103)

In the renderer bundle, the composer wrapper classes (rCi/iCi thread-composer, aCi edit-composer) throw Composer is not available when _composerApi.getState() returns null. The send()/setText()/reset() methods all guard with if(!t)throw Error("Composer is not available"). On a fresh session the composer API state is null at the moment of the first Enter, so the send is dropped; by the second Enter the composer has mounted and getState() is non-null, so it works. This is a session-switch / mount-timing race in the Desktop UI layer (similar class to issue #46563).

Steps to reproduce

1. Open Hermes Desktop.
2. Start a new chat (or switch to a different session).
3. Type a message and press Enter once.
4. Observe: message is not sent, text remains in input.
5. Press Enter again -> message sends and input clears.

Expected
First Enter sends the message and clears the input; the input should not retain text from a previous session when a new session is opened.

Environment

• OS: Windows 10
• Hermes: 0.18.2 (version files consistent)
• Desktop build: win-unpacked, resources/app.asar/dist/assets/index-BK_BHFlU.js
• Already tried: clearing %APPDATA%\Hermes\Local Storage\leveldb (composer-drafts cache) — did NOT fix it, confirming it is a runtime mount-timing bug, not stale cache.

Possible fix direction
Make the composer wrapper resilient to null state: queue send()/setText() and flush once _composerApi.getState() becomes available, instead of throwing Composer is not available.

[daerias]

Also reproduces on macOS (arm64, v0.18.2).

One additional data point: when rich_drafts: true is set in gateway config, the previous session's draft text gets restored into the new session's composer. Combined with the mount-timing race, this means users see old text they didn't type, and need two Enters to clear it.

Platform: macOS 26.5.1, Apple Silicon.

[Enough1122]

Hi — confirming this also reproduces in our environment and adding one more data point that may help narrow the fix.

Reproduction confirmation

• Hermes Desktop: same symptoms on Windows 10 (build from 2026-07-12, version files 0.18.2, win-unpacked).
• Behavior matches 1:1: composer on a fresh session is pre-filled with text from the previously-active session; first Enter is silently swallowed (Composer is not available from the renderer bundle); second Enter sends and clears.
• Reproduces 100% of the time on the first message of every new session; switching between existing sessions also triggers the same race (not only __new__).

Additional observation
We hit an adjacent case that looks related: after sending the first message, if we open a second new session without manually clearing the composer, that text gets carried over again (so the stale text can chain across multiple __new__ sessions in a row, not just from the most recent active one). This suggests the per-session draft bucket is being initialized from the wrong source on session creation, not just from the previously-selected session — consistent with the getState()-returns-null hypothesis, since if the composer API is mounted in a stale-draft context before the new session state is hydrated, the hydrate order itself is the bug.

Environment

• OS: Windows 10 64-bit
• Desktop build: win-unpacked, same renderer bundle hash as reported above
• Tried: clearing %APPDATA%\Hermes\Local Storage\leveldb (composer-drafts cache) — same behavior afterward, confirms runtime mount-timing race, not stale cache (matches what the OP already verified).

Hope this helps — happy to grab a fresh desktop.log or HAR if useful.

—
This comment was drafted and submitted on behalf of the reporter by an AI assistant (Hermes Agent) operating under explicit user instruction. The user opted out of pre-publish review for this comment.

[teknium1]

Thanks for the detailed reproduction and the macOS confirmation.

Automated hermes-sweeper review found that current main already implements this behavior:

• 281a439ad483e6f130c2305a5e932c652778cb3b guards unbound assistant-ui composer mutations so Composer is not available does not escape the renderer; the current implementation is at apps/desktop/src/app/chat/composer/hooks/use-composer-draft.ts:65.
• 8b84d82227a3b637a26ba5f4f41bb08281e2ab84 changes Enter submission to read the live contentEditable payload. Current code does this at apps/desktop/src/app/chat/composer/index.tsx:558 and apps/desktop/src/app/chat/composer/hooks/use-composer-submit.ts:110; enter-submit-dom-race.test.tsx:129 covers first-Enter submission with stale composer state.
• 2afa92c74ff591dbd7b7b85decd9fb07df932d15 scopes delayed draft persistence to the swap-effect owner and rejects stale delayed writes, addressing draft bleed during session switches at use-composer-draft.ts:306.

The linked PR #63358 targets the same mount-time class, but its requested user-visible guarantee is already present on current main.