feat: tabbed panes — multiple tabs per split pane (cmux-style)

[aterrylu]

Summary

Redesigns the split-pane system to support multiple tabs per pane, inspired by cmux's tab architecture. Each split pane now has a tab bar where sessions and previews can be stacked as tabs, instead of requiring a new split for each additional session.

Key Changes

Data Model (layoutTree.ts)

• LayoutLeaf changed from pane: ActivePane | null to tabs: TabItem[] + activeTabIndex: number
• New operations: addTab, removeTab, setActiveTab, activeTabPane, allTabPanes
• Migration function converts old persisted single-pane layouts to tab format
• All 59 layout tree tests updated and passing

Tab Bar (TabBar.tsx)

• Auto-hides for single tab (VS Code style)
• Shows AgentStatusIcon per tab (spinner/checkmark/triangle matching sidebar)
• Close button per tab (shows on hover)
• Active tab: bold text + bottom border highlight

Store (store.ts)

• New actions: addTabToLeaf, closeTab, switchTabInLeaf
• switchPane finds pane across all tabs and activates the correct tab
• openPreview adds as new tab instead of replacing current pane
• movePaneToLeaf center zone adds as tab + handles multi-tab source removal

Sidebar (Sidebar.tsx)

• Removed GroupContainer — flat agent list, no more split grouping
• Sessions visible in any pane tab get subtle background highlight
• Drag-and-drop works: drag to center = add tab, drag to edge = split

SessionMountLayer

• Only maps active tab per leaf to rect (inactive tabs hidden)
• Disables pointer events during drag so drop zones receive events through xterm canvas

Test plan

• All 59 layout tree tests passing
• Build + lint clean
• Playwright automated testing: session click, tab creation, tab switching, split creation
• Single session: tab bar hidden, terminal renders correctly
• Drag to center: creates tab, tab bar appears with status icons
• Drag to edge: creates split (unchanged behavior)
• Tab switching: click tab to switch, terminal content updates
• Sidebar highlights: visible sessions get subtle background
• Persisted state migration: old format auto-converts, corrupted state handled gracefully

Screenshots

Tabs + split view tested via Playwright on forge.

🤖 Generated with Claude Code

[nox-0x]

🔴 Critical

Problem: removeTab does not decrement activeTabIndex when a tab before the active one is removed. With 3+ tabs, closing any tab whose index is less than activeTabIndex causes the active tab to silently shift to the next tab.

Why it matters: Concrete example — tabs [A, B, C], activeTabIndex = 2 (C is active). User closes A (index 0). newTabs = [B, C], newIndex = 2. The check 2 >= 2 clamps it to 1, pointing at C — correct here by accident. But with [A, B, C, D], activeTabIndex = 2 (C is active), closing A gives newTabs = [B, C, D], newIndex = 2, 2 >= 3 is false — index stays at 2 pointing to D instead of C. The user closed a background tab and their focused session visibly jumps. The existing test ("adjusts activeTabIndex when removing before active") only covers the 2-tab boundary case and misses this.

Suggested fix:

let newIndex = root.activeTabIndex;
// Shift down if the removed tab was before the active one
if (idx < newIndex) newIndex--;
// Clamp in case we removed the last tab
if (newIndex >= newTabs.length) newIndex = Math.max(0, newTabs.length - 1);

Also add a test:

it("keeps active tab stable when removing a tab before it (3+ tabs)", () => {
  const l: LayoutLeaf = {
    kind: "leaf", id: "a",
    tabs: [{ id: "t1", pane: pane("s1") }, { id: "t2", pane: pane("s2") }, { id: "t3", pane: pane("s3") }],
    activeTabIndex: 2, // s3 is active
  };
  const result = removeTab(l, "a", "t1") as LayoutLeaf; // remove s1 (before active)
  expect(result.tabs.length).toBe(2);
  expect(result.activeTabIndex).toBe(1); // still pointing at s3
  expect(result.tabs[result.activeTabIndex].pane.id).toBe("s3");
});

[nox-0x]

🟡 Warning

Problem: closeTab calls derivedActivePane(updated, focusedLeafId) using the global focusedLeafId, but the closed tab might be in a different leaf than the focused one. If the user closes a background tab in a non-focused leaf, derivedActivePane resolves the active pane from the focused leaf (correct), but activePane is set unconditionally — which is fine today, but silently assumes focus stays put.

More concretely: if leafId !== focusedLeafId, the new layout has the correct tab removed, but the activePane is re-derived from the focused leaf, not the leaf where the close happened. This is probably the intended behavior, but if the closed tab happened to be the activePane (e.g., user has two leaves, clicks close on the active one in a non-focused leaf), activePane will jump to whatever is in the focused leaf rather than the adjacent tab in the same leaf.

Why it matters: Edge case but reproducible: split into two panes, switch a background pane to multi-tab, close the currently-active (but not focused-leaf) tab. Active panel indicator jumps unexpectedly.

Suggested fix:

closeTab: (leafId, tabId) => {
  // ...
  const updated = removeTab(layout, leafId, tabId);
  // Derive active pane from the leaf that was modified, not the focused leaf
  const targetLeaf = findLeaf(updated, leafId);
  const newActivePane = targetLeaf
    ? (activeTabPane(targetLeaf) ?? derivedActivePane(updated, focusedLeafId))
    : derivedActivePane(updated, focusedLeafId);
  set({
    layout: updated,
    activePane: newActivePane,
    ...saveGroupSnapshot(groups, activeGroupId, updated, focusedLeafId),
  });
},

[nox-0x]

Great feature — the tab bar auto-hide, migration path, and pointer-events fix during drag are all solid. One critical bug in removeTab: when closing a tab whose index is before the active tab in a 3+ tab scenario, the active tab index is not decremented, causing the focused session to silently jump to the wrong tab. Fix is a one-liner (if (idx < newIndex) newIndex--). Also flagged a warning on closeTab in the store re: active pane derivation when closing a tab in a non-focused leaf.

[nox-0x]

🔴 Critical

Problem: removeTab does not decrement activeTabIndex when a tab before the active one is removed. With 3+ tabs, closing a background tab causes the active session to silently jump to the wrong tab.

Why it matters: Example — tabs [A, B, C, D], activeTabIndex = 2 (C is active). User closes A (index 0). newTabs = [B, C, D], newIndex = 2, 2 >= 3 is false → stays at 2, now pointing at D instead of C. User's focused session jumps without any action on their part.

Suggested fix:

let newIndex = root.activeTabIndex;
if (idx < newIndex) newIndex--;
if (newIndex >= newTabs.length) newIndex = Math.max(0, newTabs.length - 1);

[nox-0x]

Great feature overall — tab bar, migration, and drag-drop tab support are solid. One critical bug still outstanding from previous review: removeTab doesn't decrement activeTabIndex when removing a tab before the active one, causing the focused session to silently jump in 3+ tab scenarios. One-liner fix: if (idx < newIndex) newIndex--.

[nox-0x]

Still missing the one-liner fix from prior reviews: removeTab does not decrement activeTabIndex when a tab before the active one is removed. In a 3+ tab pane, closing any background tab at a lower index silently shifts the active session to the wrong tab. Fix: add if (idx < newIndex) newIndex-- before the clamp. See prior inline comment for full details and failing test case. Everything else in this revision looks solid — migration path, pointer-events during drag, tab bar layout offset, and allTabPanes usage in movePaneToLeaf are all correct. Unblock once that one line is in.

[nox-0x]

🟡 Warning

Problem: <button> (close ✕) nested inside <button> (tab) — invalid HTML per spec. A <button> cannot contain interactive elements including other buttons.

Why it matters: Browsers handle this inconsistently — some promote the inner button outside the outer one during DOM parsing, breaking event flow. The e.stopPropagation() on the close button may not work as expected in all browsers, causing a tab-switch to fire simultaneously with the close. Safari in particular tends to reparse this incorrectly.

Suggested fix: Replace the outer <button> with a <div role="button"> (or keep the outer button and use a <span> for the close target), similar to how the sidebar rows already handle this pattern:

<div
  role="button"
  tabIndex={0}
  onMouseDown={(e) => e.preventDefault()}
  onClick={() => switchTabInLeaf(leafId, i)}
  // ...styles
>
  {/* ...content */}
  <button
    type="button"
    onClick={(e) => { e.stopPropagation(); closeTab(leafId, tab.id); }}
    tabIndex={-1}
  >✕</button>
</div>

[nox-0x]

Two issues remain unresolved from prior reviews: (1) 🔴 removeTab still missing if (idx < newIndex) newIndex-- — in 3+ tab panes, closing a background tab silently shifts the focused session to the wrong tab; (2) 🟡 <button> nested inside <button> in TabBar.tsx (line 88) — invalid HTML that breaks stopPropagation() in Safari/some browsers. Both are quick fixes. Everything else in this revision is solid.

[nox-0x]

Same two issues from prior reviews are still unresolved in this revision (75f9009): (1) 🔴 removeTab still missing if (idx < newIndex) newIndex-- — 3+ tab panes will silently jump the focused session when a background tab at a lower index is closed; (2) 🟡 <button> nested inside <button> in TabBar.tsx line 88 — invalid HTML that can break stopPropagation() in Safari. Both are one-liners. Everything else looks great — please just add that index decrement and swap the outer tab <button> to a <div role="button">.

[nox-0x]

Both previously flagged issues are resolved: removeTab now correctly decrements activeTabIndex when closing a tab before the active one (3+ tab case) with the matching regression test, and the outer tab row in TabBar.tsx is now a <div role="tab"> instead of a <button>, fixing the nested-button HTML validity issue. The migration path, pointer-events fix during drag, and allTabPanes usage throughout are all solid. 🟡 Minor: closeTab in the store still derives activePane via focusedLeafId when closing a tab in a non-focused leaf — low-priority UX edge case flagged in the prior review, non-blocking. LGTM.