Summary
Multiple Chrome profiles can each load FSB and connect to the hub on :7225. An MCP session may attach to a profile started with --no-startup-window (no UI window) while the user’s visible session is another profile. Symptoms include No current window, empty list_tabs, and navigate failures until the headless/wrong profile is killed.
Repro
- Context: Two+ Chrome user-data-dirs both running FSB; MCP hub on
ws://localhost:7225.
- Steps:
- Start profile A with a visible window and X signed in.
- Start profile B with
--no-startup-window (or otherwise no usable window); both extensions connect to hub.
- From MCP, call
list_tabs / navigate.
- Observed: wrong extension wins attach;
list_tabs empty or “no current window” class failures; recovery requires killing the wrong Chrome.
Code pointers (verified against /workspace/FSB)
mcp/src/bridge.ts — hub on port 7225, relay clients, multi-instance hub/relay (~L128+, ~L163+).mcp/src/version.ts — FSB_EXTENSION_BRIDGE_PORT = 7225.mcp/README.md — multi-client hub/relay notes (~L589).extension/utils/agent-tab-resolver.js — TAB_NOT_OWNED (~L106).extension/ui/sidepanel.js — “no active tab in current window” (~L347).- Likely area: bridge session binding / extension registration metadata (profile or window id) — confirm before inventing new APIs.
Proposed fix
Pin each MCP client session to a single extension connection (Chrome profile/window). On attach, reject or warn if the connected Chrome has no normal window (e.g. --no-startup-window). Prefer explicit selection when multiple extensions are connected rather than silent last-writer-wins.
Acceptance / regression
- With two profiles connected, MCP tools target only the pinned profile; wrong-profile attach surfaces a clear error.
--no-startup-window-only connection cannot become the silent default for interactive compose.list_tabs non-empty for the pinned visible profile.
Owner
mcp-server (primary) + extension (window/profile metadata on connect)
Priority: P0 · Owner: mcp-server
Summary
Multiple Chrome profiles can each load FSB and connect to the hub on
:7225. An MCP session may attach to a profile started with--no-startup-window(no UI window) while the user’s visible session is another profile. Symptoms includeNo current window, emptylist_tabs, and navigate failures until the headless/wrong profile is killed.Repro
ws://localhost:7225.--no-startup-window(or otherwise no usable window); both extensions connect to hub.list_tabs/navigate.list_tabsempty or “no current window” class failures; recovery requires killing the wrong Chrome.Code pointers (verified against /workspace/FSB)
mcp/src/bridge.ts— hub on port 7225, relay clients, multi-instance hub/relay (~L128+, ~L163+).mcp/src/version.ts—FSB_EXTENSION_BRIDGE_PORT = 7225.mcp/README.md— multi-client hub/relay notes (~L589).extension/utils/agent-tab-resolver.js—TAB_NOT_OWNED(~L106).extension/ui/sidepanel.js— “no active tab in current window” (~L347).Proposed fix
Pin each MCP client session to a single extension connection (Chrome profile/window). On attach, reject or warn if the connected Chrome has no normal window (e.g.
--no-startup-window). Prefer explicit selection when multiple extensions are connected rather than silent last-writer-wins.Acceptance / regression
--no-startup-window-only connection cannot become the silent default for interactive compose.list_tabsnon-empty for the pinned visible profile.Owner
mcp-server (primary) + extension (window/profile metadata on connect)
Priority: P0 · Owner: mcp-server