Description

The CDP bridge (src/main/cdp-bridge.ts) holds a single webContentsId at a time. Two behaviors cause unexpected loss of the CDP connection:

1. Any unmount clears CDP for all panes

BrowserPane calls window.wmux.cdp.detach() in its cleanup effect when it unmounts. This unconditionally clears the bridge — even if another BrowserPane is still open and valid. Closing a split-tree browser pane (e.g. one opened by clicking a terminal link) silently breaks the CDP connection to the sidebar browser that's still visible.

2. Last dom-ready wins

Every BrowserPane calls cdp.attach(webContentsId) when its webview fires dom-ready. There is no coordination between instances, so whichever pane mounts last owns the connection. With the sidebar browser (which keeps one pane per workspace mounted simultaneously) and ad-hoc split-tree browser panes both calling attach, the active CDP target is non-deterministic from the user's perspective.

Context

wmux has two distinct browser systems:

• Sidebar browser (Ctrl+Shift+I) — one BrowserPane per workspace, all kept mounted, CSS-toggled visibility. Synthetic surface IDs (browser-{wsId}), outside the split tree.
• Split-tree browser panes — created on demand (link clicks, keyboard split shortcuts), live inside the split tree as browser-type surfaces.

Both render BrowserPane and both call cdp.attach/cdp.detach. The CDP bridge has no awareness of which pane should be the authoritative target.

Expected behavior

• Closing one BrowserPane should not detach CDP if another is still open
• The CDP target should be the pane the user is actively viewing, or at minimum a designated primary (e.g. the sidebar browser for the active workspace)

Suggested fix

• cdp.detach() in BrowserPane cleanup should be conditional — only detach if this pane's webContentsId is the one currently attached
• Consider designating the sidebar browser as the authoritative CDP target and having split-tree panes opt out of attach/detach entirely, or attach only when focused

🤖 Generated with Claude Code