Multi-Session Support for Claude in Chrome (Tab Group Isolation)
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-groupor--session-idparameter
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:
- I run a sports card business with multiple Claude Code instances for different tasks
- Work Claude is managing Shopify inventory in one tab group
- Social Claude needs to schedule Buffer posts in another tab group
- 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_
Showing cached comments. Read the full discussion on GitHub ↗
22 Comments
+1 would love to see this feature added
+1
+1
Would be amazing!
+1
+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.
+1
This would be a beast of an improvement!
+1 This would be huge.
+1
+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.
+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
+1
+10000
+1
+1
+1
+1
+1!
Windows Named Pipe architecture analysis & concrete proposal
I've investigated the root cause on Windows and found the exact bottleneck.
Current Architecture (Windows)
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:
Combined with per-session Tab Group isolation (as originally proposed in this issue), each CLI session would:
This would allow full parallel operation of multiple
claude --chromesessions without interference.Related Issues
Environment: Windows 10, Claude Code v2.1.87 (npm), Chrome extension v1.x
This is a key feature... How can we help make it happen?
Thanks — I think the best way to help is to make the implementation path explicit.
From my investigation, this is really two problems:
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:
--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.
+1
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.