[FEATURE] Support multiple concurrent Claude Code sessions via isolated tab groups in Claude in Chrome

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When running multiple Claude Code instances simultaneously (e.g., in different terminal windows or tmux panes), all instances compete for control of the same Chrome browser via the Claude in Chrome extension. Tool calls from one session can interfere with another session's tabs, leading to unpredictable behavior.

The current workaround is to launch entirely separate Chrome instances with --user-data-dir, but this is heavyweight and defeats the purpose of the existing tab group architecture.

Proposed Solution

The Claude in Chrome extension already has a "tab group" concept (visible in tabs_context_mcp and tabs_create_mcp). Extend this to support multiple concurrent MCP connections, each with its own isolated tab group:

1. Session-scoped tab groups: When a Claude Code instance connects, assign it a unique session ID and create (or reuse) a dedicated tab group for that session
2. Tool call isolation: Scope all browser automation tool calls (navigate, computer, read_page, etc.) to the session's assigned tab group only
3. Visual identification: Color-code or label tab groups to indicate which Claude Code session owns them (e.g., "Claude Session 1", "Claude Session 2")
4. Connection management: Support multiple simultaneous WebSocket connections from different Claude Code processes

Alternative Solutions

• Instance ID flag: Similar to #15125, allow claude --chrome-instance=<id> where the ID corresponds to a tab group rather than a Chrome profile
• Tab group selection: Interactive /chrome command to select or create a tab group for the current session
• Automatic namespacing: Each Claude Code process gets a random session ID, and the extension auto-creates a matching tab group

Priority

Medium - Enables parallel development workflows

Feature Category

API and model interactions

Use Case Example

A developer might run:

• Terminal 1: Claude Code working on frontend changes, using Chrome to preview UI
• Terminal 2: Claude Code working on backend API, using Chrome to test endpoints
• Terminal 3: Claude Code reviewing docs, using Chrome to browse documentation

Currently these sessions conflict. With tab group isolation, each would operate in its own browser context without interference.

Additional Context

Related issues:

• #15125 - Targeting specific Chrome instances/profiles (complimentary)
• #15715 - Chrome profile selection (complimentary)

The key insight is that the extension's existing tab group architecture could naturally support this—it just needs to handle multiple MCP connections and scope operations per-connection rather than globally.