[BUG] Claude in Chrome cannot connect to browser profile "Work" — only detects "Personal" profile on same machine

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code's browser automation (Claude in Chrome / list_connected_browsers) cannot detect or connect to a specific Chrome profile ("Work") on my machine, even though that profile has the extension correctly installed, enabled, signed into the same Anthropic account as the desktop app, and set to "On all sites" access.

The desktop app previously connected to this exact Work Chrome profile successfully in past sessions (confirmed by matching Chrome tab groups the assistant had created there). Today it only ever detects a second, separate "Personal" Chrome profile on the same machine — never "Work" — regardless of what I try.

What Should Happen?

The desktop app should detect and let me connect to the "Work" Chrome profile, the same way it did in previous sessions, so browser automation can run against my actual work browser session (Notion, internal company portal).

Error Messages/Logs

Native host log (%LOCALAPPDATA%\Claude\Logs\chrome-native-host.log) shows the actual failure pattern — a working sequence looks like:

[INFO chrome-native-host] Chrome native host starting (version 0.1.0)
[INFO chrome-native-host] Creating Windows named pipe: \\.\pipe\claude-mcp-browser-bridge-<Windows username>
[INFO chrome-native-host] Named pipe created successfully
[INFO chrome-native-host] Entering main message loop
[INFO chrome-native-host] Socket server listening for connections

But repeatedly, the sequence stops right after "Creating Windows named pipe" — no "created successfully" line ever appears, and the process eventually just logs "Chrome disconnected (EOF received)". The named pipe is scoped per Windows user (not per Chrome profile), so my guess is: when a native host instance from one Chrome profile/window already holds that pipe, a second instance (e.g. from a different Chrome profile) silently fails to bind it, with no error surfaced anywhere. Killing the stray chrome-native-host.exe process and reopening the extension panel seems to let a fresh instance grab the pipe successfully — but this shouldn't require manually killing processes.

Steps to Reproduce

1. Have two Chrome profiles on the same Windows machine ("Personal" and "Work"), both with the Claude in Chrome extension installed and signed into the same Anthropic account.
2. Open Claude Code desktop app, signed into that same account.
3. With "Work" Chrome open (Personal closed) and the Claude extension side panel open in Work Chrome, call list_connected_browsers from the desktop app session.
4. Result: empty array. No "connect" prompt appears in Work Chrome.
5. Confirmed not caused by: extension permissions ("On all sites"), enterprise Chrome policy (checked chrome://policy for "Native" — no results), extension classic vs. new side-panel mode, restarting the extension, restarting Chrome, or restarting the Claude desktop app.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.34493.1.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Possibly related to #90257 (same list_connected_browsers returns [] symptom while the extension itself works locally), but that report is macOS-only and doesn't involve a multi-Chrome-profile scenario like mine.