Greptile Summary

This PR fixes a session-link navigation bug where clicking session keys in the Sessions table triggered a full-page reload, dropping the in-memory Control UI auth token and disconnecting the gateway. The fix intercepts plain left-clicks on session anchor tags, prevents the default navigation, and performs an in-app state transition instead — preserving the token while correctly switching to the Chat tab with the selected session key and updating the browser URL via history.pushState.

Key changes:

• sessions.ts: Adds an onOpenSession callback prop and a @click handler on session links that guards against modifier keys and non-left-button clicks before calling event.preventDefault() and routing in-app.
• app-render.ts: Implements onOpenSession to reset stale chat state (chatMessage, chatStream, chatRunId, etc.) and call applySettings + setTab("chat"), keeping the in-memory token intact.
• navigation.browser.test.ts: Adds an integration test verifying that a simulated left-click preserves settings.token, sets the correct sessionKey, switches tab to "chat", and reflects the expected URL (/chat?session=...).

Confidence Score: 5/5

• This PR is safe to merge — it precisely targets the root cause, the logic is straightforward, and the new test validates the critical token-preservation invariant end-to-end.
• The click-interception pattern is a standard SPA navigation technique. The guard conditions correctly pass through modifier key and non-left-button clicks so browser affordances (open-in-new-tab, copy-link, etc.) are unaffected. The onOpenSession handler resets all relevant chat state synchronously before calling setTab, which means syncUrlWithTab reads the already-updated host.sessionKey and produces the correct URL. The new integration test directly covers the regression scenario. No security or data-integrity concerns were identified.
• No files require special attention.

_{Last reviewed commit: 6d8d518}

Addressed the P1 review item about queued state leakage on session-link open.

What changed:

• onOpenSession in ui/src/ui/app-render.ts now also clears chatAttachments and chatQueue (it already reset chatRunId).
• Extended ui/src/ui/navigation.browser.test.ts to seed queued state before clicking a Sessions table link, then assert chatAttachments and chatQueue are emptied and chatRunId is null after in-app navigation.

What I intentionally did not change:

• No code change for the Greptile summary comment. It appears informational and does not identify a separate actionable defect beyond the already-addressed session-link behavior.

Addressed latest review feedback with a minimal follow-up:

• Fixed P2 (same-session reopen): onOpenSession now only resets chat state when the clicked session key differs from the current one. Reopening the current session from the Sessions table preserves chatRunId (and existing queue/attachments) so in-flight state is not dropped.
• P1 (clear queued state on session switch): no new code needed in this follow-up, because this branch already clears chatQueue/chatAttachments when switching to a different session.
• Greptile summary: no direct action taken; it is informational and aligns with current behavior.

Validation:

• pnpm --dir ui test src/ui/navigation.browser.test.ts src/ui/views/sessions.test.ts
• pnpm exec oxfmt --check ui/src/ui/app-render.ts ui/src/ui/navigation.browser.test.ts

Thanks for the careful follow-up work on this.

I reviewed it against #40892, now merged to main in f2f561fab1bf3808baed61ebdd55ec3bfe3c8b65.

The merged fix restores current-tab Control UI token continuity through sessionStorage, so clicking a session link no longer loses auth even if the route change causes a same-tab reload. That resolves the underlying regression this PR is targeting, so we no longer need the separate session-link interception path to fix auth disconnects.

Closing as superseded by #40892. If we want SPA-only session-link behavior later for UX reasons independent of auth, that can come back as a narrower follow-up.