feat: expose per-session window list in sidebar

[shunkakinoki]

Summary

• Adds per-session window/tab enumeration to the sidebar, so sessions with multiple tmux windows show each window as a clickable row
• Introduces MuxWindowInfo type and optional windowList field on MuxSessionInfo
• Adds switch-window client command to switch directly to a specific window within a session
• Windows are only displayed when a session has more than one tab

Changes

Contract (packages/mux/contract):

• New MuxWindowInfo interface (id, index, name, active, paneCount)
• MuxSessionInfo.windowList optional field

TmuxProvider (packages/mux/providers/tmux):

• Batch-fetches all windows via listWindows() and groups by session name
• Populates windowList in listSessions()

Runtime (packages/runtime):

• SessionData.windowList field piped through computeState()
• switch-window command handler in the server

TUI (apps/tui):

• SessionCard renders window rows (with active indicator) when windowList.length > 1
• Clicking a window row sends switch-window command

Test plan

• bun test - 349 tests pass
• bun run build - builds successfully
• Manual: open sidebar with multi-window session, verify windows shown
• Manual: click a window row, verify it switches to that window

[inspect-review]

inspect review

Triage: 10 entities analyzed | 0 critical, 0 high, 9 medium, 1 low
Verdict: standard_review

Findings (2)

1. [low] Server-side switch-window is hard-coded to tmux and ignores the resolved provider abstraction. In packages/runtime/src/server/index.ts the handler resolves const p = sessionProviders.get(cmd.sessionName) ?? mux; and calls p.switchSession(...), but then unconditionally runs Bun.spawnSync(["tmux", "select-window", "-t", ${cmd.sessionName}:${cmd.windowIndex}], ...). This will be incorrect/broken for non-tmux providers and breaks the provider-agnostic command semantics.
2. [low] Server switch-window swallows/ignores failures but still updates and broadcasts focus/current session state as if the switch succeeded. The code wraps Bun.spawnSync(...) in try { ... } catch {} but spawnSync typically does not throw on non-zero exit; failures are ignored, yet focusedSession, cachedCurrentSession, and cachedCurrentSessionTs are updated and broadcastFocusOnly() is called. This can leave clients believing the window switched when it did not.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[Palanikannan1437]

hey @shunkakinoki, would you mind sharing a screenshot of how this looks?

[shunkakinoki]

Hey @Palanikannan1437! Here's how the window list looks:

primary session (4 windows): 0:btop, 1:dotfiles, 2:dotfiles, 3:tui
work session (3 windows): 0:editor, 1:shell, 2:work

The active window has a ▸ indicator in green. Clicking a window row sends a switch-window command to jump directly to that tab.

Windows only appear when a session has >1 tab — single-window sessions are unchanged.

[inspect-review]

inspect review

Triage: 24 entities analyzed | 0 critical, 0 high, 23 medium, 1 low
Verdict: standard_review

Findings (1)

1. [low] Agent-to-window association is hard-coded to tmux for all sessions/providers: server/index.ts unconditionally builds paneToWindow via shell(["tmux","list-panes", ...]) and then uses it for every session when enriching windowList (paneToWindow.get(a.paneId) === w.id). For non-tmux providers (or environments without tmux), this mapping will be empty/wrong, so agentStatus/agentName on windows will be missing/incorrect.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[inspect-review]

inspect review

Triage: 24 entities analyzed | 0 critical, 0 high, 23 medium, 1 low
Verdict: standard_review

Findings (2)

1. [low] Server-side switch-window is tmux-specific and ignores the resolved mux provider for window selection. In packages/runtime/src/server/index.ts, case "switch-window" calls const p = sessionProviders.get(cmd.sessionName) ?? mux; p.switchSession(cmd.sessionName, tty); but then always runs Bun.spawnSync(["tmux", "select-window", "-t", ${cmd.sessionName}:${cmd.windowIndex}]). This will fail/no-op or select the wrong window when the session provider is not tmux.
2. [low] switch-window resolves a client tty but does not use it for the tmux select-window call, so with multiple tmux clients attached it may select the window in the wrong client. Evidence: const tty = ... is computed, passed to p.switchSession(...), but Bun.spawnSync(["tmux","select-window",...]) does not include any -c/client targeting using tty.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[inspect-review]

inspect review

Triage: 21 entities analyzed | 0 critical, 0 high, 20 medium, 1 low
Verdict: standard_review

Findings (1)

1. [low] STATUS_PRIORITY is referenced before it is defined in packages/runtime/src/server/index.ts. The windowAgentMap builder uses STATUS_PRIORITY[status] inside the orderedMuxSessions.map(...) block added around line ~525, but const STATUS_PRIORITY: Record<string, number> = { ... } is declared later in the same function around line ~1055. Since const is not hoisted, this will throw a ReferenceError at runtime when that code path executes.
   Evidence:

• Use: if (!existing || STATUS_PRIORITY[status] > STATUS_PRIORITY[existing.status]) { ... } inside the new windowAgentMap scan block.
• Definition later: const STATUS_PRIORITY: Record<string, number> = { ... } added at ~1100.

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes

[Palanikannan1437]

i'm not sure about this ui, seems up a bit too much for me, i think we could keep this toggleable via some shortcut, show windows, with the default as off...what do you think?

[Palanikannan1437]

@eduwass is this something you wanted, I remember from one of the issues you opened a long time ago