Hermes "session not found" after gateway restart

Likely cause

Session state lives in the gateway's memory, so anything that restarts the gateway — a crash, an auto-restart, an update cycle — discards it while your client keeps sending the old session id. The gateway answers "session not found", and in Desktop the error sticks at the bottom of the UI and does not auto-clear even after you switch conversations (issue #38704). Three related variants: in the TUI, rapid successive messages in one turn hit an auto-respawn handler that never calls reopen_session(), so the row is still marked closed (issue #39013); a provider connection failure mid-conversation can leave a session pinned in "running" state so every later message triggers an interrupt loop, recoverable only by deleting the session (issue #11131); and running the CLI and the Telegram gateway at once causes SQLite lock contention on state.db, so create_session() fails outright (issue #3139).

The fix

1. 1 Start a new conversation. The old session id is genuinely gone from the restarted gateway and cannot be revived from the client side.
2. 2 If the error banner persists after switching conversations, restart the Desktop client — the stale error does not auto-clear on its own.
3. 3 For a session stuck in 'running' after a provider failure, delete that session via the CLI. It will not recover by itself and will keep triggering interrupt loops.
4. 4 Do not run the CLI and a gateway (Telegram, Discord) against the same state.db at the same time — concurrent writes cause lock contention that breaks session creation.
5. 5 In the TUI, let each message complete before sending the next; firing several in one turn hits the respawn path that skips reopen_session().