fix(desktop): scope submit drift guard to genuine session switches

[Kenmege]

Summary

The submit "session context drift" guard (added in 7acaff5 / #54527) aborts a prompt submission whenever $selectedStoredSessionId or the raw route token (pathname:search:hash) changes mid-submit. Both signals churn programmatically on a busy gateway, so on machines with background streaming sessions, per-minute cron sessions, a messaging surface, or gateway-profile switches, essentially every send from a second chat aborts silently — optimistic message dropped, draft left in the composer, no error, prompt.submit never fired. This affects existing sessions, not just the new-chat first-send covered by #63624 and the open first-send PRs.

Fixes the client-side half of #63078 (see my comment for the live evidence). The server-side _wait_agent 30 s ceiling described there still deserves its own fix.

False-positive churn sources removed

• Selection null-resets — store/gateway-switch.ts calls setSelectedStoredSessionId(null) on a gateway/profile switch or reconnect; the guard read that as "user switched away".
• search/hash-only route changes — overlays and panels park state in location.search/hash; only the pathname selects a chat, but the raw token comparison fired anyway.
• Background active-ref retargets mid-create — createBackendSessionForSend still compared activeSessionIdRef + selection + raw token across the seconds-long session.create round-trip (server-side agent/MCP init), during which background gateway events retarget the active ref ([Bug]: Desktop shows newer session output in an older session #47709 class). The just-created session was session.closed and the send returned null.

Change

• New helper session-context-drift.ts:
  • routeTargetFromToken() reduces a route token to the chat it targets (routed session id, '__new__' for the new-chat route, null for non-chat routes);
  • sessionContextDrift() returns a drift reason (or null): route prong fires only when the routed chat moves to a different, real chat; selection prong only when selection moves to a different, non-null stored id; both are target-aware, so the pipeline's own re-home onto the submit's target (fresh create, resume) never reads as drift.
• use-prompt-actions/submit.ts: all five drift checks use the helper; the 8c28876 post-create baseline re-pin and active-ref check are preserved unchanged.
• use-session-actions/index.ts (createBackendSessionForSend): mid-create check uses the helper; the activeSessionIdRef prong is dropped (every genuine user switch retargets selection and route synchronously; the active ref churns from background events).
• Every abort now logs console.warn('[submit-drift-abort]', reason, { phase }), so the next report of this class is diagnosable from the console.

Genuine switches still abort: clicking another chat mid-submit (routed id + selection both move) and clicking "New session" while a send from an existing chat is in flight both keep the old behavior.

Testing

• New session-context-drift.test.ts: search/hash-only churn, selection null-reset, moves onto the submit target → no drift; moves to a different chat / the new-chat route → drift; non-chat routes → no drift.
• apps/desktop: full vitest suite 199 files / 1699 tests green (no existing test needed changes), npm run typecheck clean.
• Live verification on a busy gateway (background streaming session + cron churn active): first-sends in new chats and sends from existing sessions submit reliably; before the patch both aborted ~100% of the time.

🤖 Generated with Claude Code

[teknium1]

Thanks for narrowing the drift predicate without removing the real misrouting protection. The current main still has the raw guard at apps/desktop/src/app/session/hooks/use-prompt-actions/submit.ts:149-150 and the active-ref create guard at apps/desktop/src/app/session/hooks/use-session-actions/index.ts:262-269, so the premise remains valid.

Problems

• The new tests are pure-helper tests. They do not exercise the changed create path, where the active-ref prong is removed, nor the changed submit call sites. Existing integration coverage is in apps/desktop/src/app/session/hooks/use-prompt-actions/index.test.tsx:1389-1607.

Suggested changes

• Add a delayed session.create regression proving active-ref-only churn does not call session.close, plus the real session-switch counterpart.
• Add submit-harness regressions for selected-id null resets and search/hash-only route churn, while retaining genuine-switch abort coverage.

Current main has moved since the PR base and GitHub reports the branch as merge-conflicted, but the target code remains local and salvageable. This is an automated hermes-sweeper review.

[antonbru]

Reproduced on macOS Desktop v0.18.x

Confirming this bug reproduces consistently on Hermes Desktop on macOS (current main, build with commit 7acaff5ef2).

Symptoms

1. First message in a new session — the session gets created (sidebar shows a title), but the chat view is completely blank. No user message, no response. Only the second Send works.
2. Sending from an existing session on a busy gateway sometimes creates a new empty session instead of posting to the current one.

Both symptoms disappear after applying the changes from this PR (verified locally — the drift guard no longer aborts on programmatic ref/route changes, while genuine session switches are still correctly blocked).

This fix is critical for daily use — without it the desktop app is practically unusable (the first message is lost every time on a fresh session). Really looking forward to seeing this merged and released.

Thanks for working on this!

[Kenmege]

Updated this branch to current main and resolved the submit-path conflict by retaining the scoped sessionDriftReason guard, so ordinary same-session context changes still do not block submission.\n\nFresh focused verification:\n- session-context-drift.test.ts\n- use-prompt-actions/index.test.tsx\n- 56/56 tests pass\n\nThe update is pushed in merge commit 622098748; CI has been retriggered.

[egilewski]

looks mergeable

Review setup: I reviewed a run-owned patch replay against current GitHub main because the submitted branch is stale and conflicted; this does not mean the submitted branch itself merges cleanly.

Security evidence:

• trust boundary: asynchronous desktop sends must remain bound to their intended conversation while gateway and route state change concurrently.
• source/sink/invariant: harmless selection null-resets, search/hash changes, and background runtime-ref churn must not abort prompt.submit, while a move to another real chat must still stop cross-session delivery.
• current-main reproduction: current main's raw equality predicate fires for selection null-resets and search/hash-only changes, while its create guard also fires on active-runtime-only churn.
• PR-head or patch-replay validation: the current-main replay scopes drift to a different routed or selected chat and preserves the post-create active-runtime guard.
• positive/negative cases: desktop typecheck and the complete UI suite passed (227 files; 1879 passed, 1 skipped), covering genuine switches, fresh-chat rehome, routed/profile resume, session actions, and background queue sends.
• residual bypass search: no in-scope cross-session delivery bypass was found across create, resume, attachment, retry, profile-resume, and queued-send paths.
• reviewer validation: the PR remained open and non-draft at the reviewed head, and the replay diff passed whitespace validation.

Signed: GPT-5.6-sol-xhigh in Codex