Repository navigation
bug(cdp): any BrowserPane unmount clears CDP; last dom-ready wins attachment #27
Description
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
BrowserPaneper 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
BrowserPaneshould 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()inBrowserPanecleanup should be conditional — only detach if this pane'swebContentsIdis the one currently attached- Consider designating the sidebar browser as the authoritative CDP target and having split-tree panes opt out of
attach/detachentirely, or attach only when focused
🤖 Generated with Claude Code
Activity
fix(browser,security): resolve issues #27, #28, #29
amirlehmam commentedon Jun 8, 2026
Fixed in v0.8.3. Thanks for the precise root-cause writeup @schroldgames.
cdp.detach()is now ownership-aware — the bridge only tears down the connection if the unmounting pane is the one currently attached (awebContentsIdis plumbed throughcdp.detach(wcId)and checked in both the IPC handler and the bridge). Closing a split-tree browser pane no longer kills the sidebar browser's CDP.dom-readywins" non-determinism: eachBrowserPanenow re-claims the CDP target on a capture-phasemousedown, so the pane you're actively interacting with becomes the target ("focused wins").dom-readystill attaches on first load.Added unit coverage for the ownership-aware detach in
tests/unit/cdp-bridge.test.ts.feat(browser): agent-browser engine in the pane