Multi-Session Support for Claude in Chrome (Tab Group Isolation)

Open 💬 23 comments Opened Dec 23, 2025 by alarconm

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 (a "swarm"), they all share the same Claude in Chrome browser session. This causes:

  • Tab conflicts: One Claude instance navigates away from another's work
  • Screenshot capturing wrong tabs: Screenshots grab the wrong content
  • Actions interfering with each other: Commands from one session affect another's tabs

Real-world use case: I run a business with multiple specialized Claude agents working in parallel:

  • Work Claude → Shopify Admin, inventory, orders
  • Social Claude → Buffer, Instagram, TikTok
  • Support Claude → Email, customer service
  • Research Claude → Web research, competitor analysis

All need browser access. Currently they fight for the same tabs, causing constant conflicts and requiring manual intervention.

Current workaround: Use Chrome DevTools MCP with separate --user-data-dir profiles. But this:

  • Requires manual Chrome launches with special flags
  • Loses the seamless "same session as user" benefit (cookies, authentication, etc.)
  • More complex setup that defeats the elegance of Claude in Chrome

Why Claude in Chrome is special: It uses the REAL browser session - same cookies, same authentication, no bot detection issues. This is a major unlock that shouldn't be fragmented across different MCP tools.

Proposed Solution

Add session isolation to Claude in Chrome. Here are three potential approaches:

Option A: Tab Group Isolation (Recommended)

  • Each Claude Code instance gets assigned to a specific Chrome tab group
  • Tabs within a group are isolated from other groups
  • Extension tracks which tabs belong to which session via group ID
  • Tab groups are already a native Chrome feature - just needs MCP awareness

Option B: Profile Selection

  • Support connecting to different Chrome profiles
  • Each Claude instance specifies which profile to use
  • Profiles already exist in Chrome - extension would select on connect

Option C: Session Tokens

  • Claude in Chrome generates unique session tokens per connection
  • Each Claude Code instance uses its own token
  • Extension routes commands to correct tabs based on token

Technical notes:

  • Claude in Chrome uses Chrome's Native Messaging API
  • Tab groups are native Chrome - minimal extension changes needed
  • Could be as simple as adding --tab-group or --session-id parameter

Expected behavior:

# Terminal 1 - Work Claude
claude --tab-group work

# Terminal 2 - Social Claude  
claude --tab-group social

# Each instance operates on its own isolated set of tabs

This would be a killer feature for anyone running Claude at scale!

Alternative Solutions

Current workaround: Chrome DevTools MCP with separate --user-data-dir profiles and different debugging ports (9222, 9223, etc).

Problems with workaround:

  • Requires launching Chrome manually with --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-1
  • Loses the seamless authenticated session (logged into sites, cookies, etc.)
  • Need to re-authenticate on every site in each profile
  • More complex setup - defeats Claude in Chrome's simplicity

Other tools: Browser MCP also exists but has similar isolation issues and lacks Claude in Chrome's native messaging elegance.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Real scenario from today:

  1. I run a sports card business with multiple Claude Code instances for different tasks
  2. Work Claude is managing Shopify inventory in one tab group
  3. Social Claude needs to schedule Buffer posts in another tab group
  4. Research Claude needs to check competitor prices on eBay

What happens now:

  • Work Claude navigates to Shopify
  • Social Claude takes a screenshot but captures Shopify instead of Buffer
  • Research Claude navigates to eBay, disrupting Work Claude's Shopify session
  • Constant tab conflicts requiring manual intervention

With this feature:

# Terminal 1
claude --tab-group work  # Only sees/controls work tabs

# Terminal 2  
claude --tab-group social  # Only sees/controls social tabs

Each instance operates independently without conflicts. Massive productivity unlock!

Additional Context

_No response_

View original on GitHub ↗

22 Comments

magiusdarrigo · 6 months ago

+1 would love to see this feature added

rdylina · 6 months ago

+1

jasonpincin · 6 months ago

+1

Would be amazing!

roshanbellary · 5 months ago

+1

alexbleakley · 5 months ago

+1
This is currently the primary thing stopping me work seamlessly with claude on browser tasks. Any solution that allows multiple sessions to use the browser without stepping on each other's toes would be impactful.

TedYav · 5 months ago

+1
This would be a beast of an improvement!

terencedignon · 5 months ago

+1 This would be huge.

russianoracle · 5 months ago

+1

aryan-socratic · 5 months ago

+1, currently claude in chrome doesn't work even with official agent teams introduced with claude opus 4.6
I think this issue should be solved soon to unlock the real power of claude in chrome.

Lprog2000 · 5 months ago

+1
running two cowork conversations at the same time and if one needs the browser, the other loses connection. i have to wait for one to finish before starting the next. multitasking lack
I'm planning to bring my team of 5 people onto the max pro plan, but this limitation is a blocker. Parallel browser access across conversations is essential for our workflow

maciematt · 5 months ago

+1

jamespelton · 4 months ago

+10000

hirvesh · 4 months ago

+1

heathkh · 4 months ago

+1

anik8das · 4 months ago

+1

tinkaman · 3 months ago

+1

LarsHoldgaard · 3 months ago

+1!

labolabo · 3 months ago

Windows Named Pipe architecture analysis & concrete proposal

I've investigated the root cause on Windows and found the exact bottleneck.

Current Architecture (Windows)

Chrome Extension → Native Messaging → chrome-native-host.bat
                                            ↓
                    Named Pipe: \.\pipe\claude-mcp-browser-bridge-{username}
                                            ↓
                    Claude Code session (only ONE can listen)

The pipe name is hardcoded per OS user. Since Named Pipes are exclusive (only one process can listen), multiple CLI sessions cannot coexist.

Additionally, Claude Desktop registers its own Native Messaging Host (com.anthropic.claude_browser_extension) which takes priority over Claude Code's (com.anthropic.claude_code_browser_extension). If Desktop is running, Code can never connect.

Proposed Fix

Include session ID in the pipe name:

\.\pipe\claude-mcp-browser-bridge-{username}-{session_id}

Combined with per-session Tab Group isolation (as originally proposed in this issue), each CLI session would:

  1. Create its own Named Pipe with a unique name
  2. Own a dedicated Tab Group in Chrome
  3. The extension would route messages to the correct pipe based on Tab Group membership

This would allow full parallel operation of multiple claude --chrome sessions without interference.

Related Issues

  • #21791 (EADDRINUSE - Native Host and MCP Server both try to create pipe listener)
  • #21337 (socket discovery doesn't find named pipes on Windows)
  • #20546 (Desktop vs CLI Native Messaging Host conflict)

Environment: Windows 10, Claude Code v2.1.87 (npm), Chrome extension v1.x

heathkh · 3 months ago

This is a key feature... How can we help make it happen?

labolabo · 3 months ago

Thanks — I think the best way to help is to make the implementation path explicit.

From my investigation, this is really two problems:

  1. Session-specific bridge identity (transport layer) — the connection between Claude Code and the Chrome native host needs to be session-scoped
  2. Browser-side isolation/routing — tab-group-aware targeting so each session only sees its own tabs

On Windows, the current bridge naming is keyed only by OS username, which effectively limits Claude in Chrome to a single active session per user. A minimal first step would be to make the bridge session-scoped (e.g. include a session ID in the pipe/socket name) while preserving backward compatibility. Tab-group isolation can then be layered on top for browser-side routing.

The most useful help right now would be:

  • Concrete multi-session use cases from affected users (what you're running in parallel, how sessions conflict)
  • OS/browser details to confirm this is cross-platform in product scope, even if the transport bottleneck differs by platform
  • Maintainer guidance on the preferred contract / CLI shape (--session-id, --tab-group, etc.)

If Anthropic is open to that direction, I'm happy to draft a short design note and/or an initial PR for the transport layer.

harshbirajdar · 2 months ago

+1

machineghost · 1 month ago

Claude web DESPERATELY needs the ability to close tabs (and not just tabs it started) to be useful. The existing "only let it mess with tabs in its own group" is more than enough safety to ensure it doesn't close something the user wants open.

Showing cached comments. Read the full discussion on GitHub ↗