[BUG] Team member agents on Windows cannot access Chrome MCP tools (claude-in-chrome)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, team member agents (spawned via the Agent tool or agent teams) cannot access mcp__claude-in-chrome__* tools, even though the primary/parent agent can use them successfully.

The primary agent connects to the Chrome MCP bridge fine and can call tools like tabs_context_mcp, read_page, computer, etc. However, when the primary agent spawns a team member agent and that teammate attempts to use any mcp__claude-in-chrome__* tool, it fails — the tools are either not visible to the teammate or return connection errors.

This appears to be the intersection of two issues:

1. The Windows named pipe path bug (now fixed for the primary agent in recent versions) — Issues #24199, #23082, #23466
2. Subagents/teammates not inheriting MCP tools (platform-independent) — Issues #13605, #23625, #23882

While Bug 2 is documented on macOS/Linux, the compound scenario on Windows has not been reported. On Windows, the Chrome MCP bridge uses named pipes (\\.\pipe\claude-mcp-browser-bridge-{user}), which adds an additional layer of complexity to tool inheritance for spawned processes.

What Should Happen?

Team member agents spawned by the primary agent should inherit access to Chrome MCP tools and be able to interact with the browser, the same way the primary agent can. This is especially important for workflows where the user wants to delegate browser automation tasks to teammates (e.g., a QA testing agent that needs to interact with Chrome).

Steps to Reproduce

1. Install Claude Code on Windows (npm install -g @anthropic-ai/claude-code)
2. Install the Claude in Chrome extension
3. Verify the primary agent can use Chrome MCP tools:

• Run claude
• Call tabs_context_mcp — this succeeds

1. Have the primary agent spawn a team member agent (via Agent tool) with a task that requires Chrome MCP tools
2. The team member agent attempts to call any mcp__claude-in-chrome__* tool
3. Result: The tool either doesn't appear in the teammate's available tools, or returns "Browser extension is not connected"

Is this a regression?

I don't know

Claude Code Version

2.1.63 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Related Issues

• #13605 — [BUG] Custom plugin subagents cannot access MCP tools (built-in agents can) (OPEN, oldest tracked issue for subagent MCP inheritance, macOS)
• #23625 — Teammate agents cannot see ToolSearch in their visible tool list (OPEN, deepest root cause analysis — MCP tools resolve to empty arrays on first turn)
• #23882 — Agent Teams: Spawned teammates cannot access ToolSearch or deferred tools (MCP) (CLOSED as duplicate)
• #24199 — Claude-in-Chrome MCP server fails to connect on Windows (named pipe path missing) (CLOSED as duplicate, fixed for primary agent)
• #23082 — Claude-in-Chrome MCP: extension executes but CLI receives 'not connected' error (Windows) (OPEN)
• #30280 — Sub-agents spawned via Agent tool don't reliably inherit MCP tools (OPEN)

Why this is distinct

The existing subagent MCP issues (#13605, #23625) are reported on macOS/Linux where the Chrome MCP bridge uses Unix sockets. On Windows, the bridge uses named pipes (\\.\pipe\...), which have a different discovery mechanism. Even after the named pipe path fix landed for the primary agent, spawned team member processes may not correctly discover or connect to the named pipe. This means a fix for Bug 2 that works on macOS/Linux (e.g., fixing MCP tool inheritance) might still leave Windows broken if the named pipe discovery isn't also propagated to child processes.