Repository navigation
Sidebar tab highlight is not always correct in shell sessions #73
Description
Bug
When the active session is a shell session, the corresponding sidebar tab is not always highlighted correctly to reflect which session has focus.
Expected
The sidebar entry for the active session should always be visibly highlighted (the active-ring/selected state) so it's clear which session is currently focused.
Actual
For shell sessions, the sidebar highlight occasionally doesn't follow the active session — the wrong tab appears highlighted, or no tab appears highlighted at all.
Notes
The active-terminal highlight is driven by UpdateActiveTerminalHighlight / UpdateSidebarActiveState (called on every MainViewModel.ActiveSession change). Worth checking whether the sidebar-side path runs in all the same scenarios as the terminal-ring path, especially for sessions launched as raw shells vs. Claude sessions.
Activity
AThraen commentedon Aug 27, 2026
Likely fixed by #93 + #106 — worth re-testing before doing any work here.
The root cause described in this issue matches what #93 found:
MainViewModel.ActiveSessiononly ever moved on a sidebar click. There was no focus or click handler on the WebView2 at all, so clicking straight into a pane and working in it left the highlight on whatever row was last selected in the sidebar.That also explains the "for shell sessions" part. A Claude session raises alerts, and
AlertDetector/NotifyUserInteractedchurn kept nudging the sidebar state; a plain shell produces none of that, so the stale highlight just sat there.Now clicking or typing in a pane promotes it (#93), and #106 corrected that to fire on real key events only — an earlier attempt promoted on any PTY input, which mouse movement and terminal replies also trigger.
Both are on
mainbut not yet in a release. Please re-check against a build frommain; if the highlight still lags for shell sessions specifically, that's a different bug and this issue should stay open with the new detail.AThraen commentedon Sep 6, 2026
Shipped in v0.7.0 — closing
Correcting my own earlier comment: it said the fixes were "on
mainbut not yet in a release". All three are in v0.7.0 (tagged 2026-09-06):5c9b955MainViewModel.ActiveSessionmoved only on a sidebar click87798c4onData, which also carries device-attribute replies, cursor-position reports and focus in/out — those made the highlight move on its ownc4f3985HwndHost, so mouse input landing on the hosted content raises no WPF routed events at all — aPreviewMouseLeftButtonDownon the hostBorderonly ever fired for the thin ring around the terminalThe root cause matches this report, including the "for shell sessions" qualifier: a Claude session raises alerts, and the
AlertDetector/NotifyUserInteractedchurn kept nudging sidebar state back into agreement. A plain shell emits none of that, so the stale highlight simply sat there.Closing as fixed. If the highlight still lags on a v0.7.0-or-later build — specifically for shell sessions, after clicking straight into a pane without touching the sidebar — please reopen with the build number; that would be a different bug from the one #93/#106/#108 fixed.