[FEATURE] Support targeting specific Chrome instances/profiles for Claude in Chrome integration

Anyone have a workaround for this for the time being?

this is killing me too

Workaround that worked for me is to log out all other chrome accounts except the one you want with Claude subscription.

Support for multiple workspaces is a huge pain. I already spend days stabilizing multiple proxy connectors to mcp but the browser feature is by far the most annoying one.

Anyone have a workaround for this for the time being?

I downloaded Chrome for Testing, added my preferred profile, turned off extension syncing, and THEN added the Claude extension. This works, but I'd rather be able to use production Chrome than a whole separate app.

Claude just connected to the browser and asked me to assign a name to my computer. Maybe this fixes it?

Claude just connected to the browser and asked me to assign a name to my computer. Maybe this fixes it?

Nope, if you try yolo mode on the machine running the browser command, it will still control your remote chrome without even asking.

using v2.1.59, it looks like y'all only look for Default or Profile directories, which seems super fragile. (e.g., i made a profile earlier via Chrome and it named the directory {profileName}.)

it would think you could check for the presence of a Preferences file (or similar) to identify profiles.

i.e., something like this:

const profiles = [];
for (const e of entries) {
  if (!e.isDirectory()) continue;
  try {
    await fs.promises.access(path.join(browserPath, e.name, "Preferences"));
    profiles.push(e.name);
  } catch {}
}

rather than what y'all basically have of:

const profiles = entries
  .filter((e) => e.isDirectory())
  .filter((e) => e.name === "Default" || e.name.startsWith("Profile "))
  .map((e) => e.name);

at least, i would suspect this is one of the precursors to targeting specific profiles.

Adding my use case here. I run two Chrome profiles daily -- one for my business (Google Workspace) and one personal (gmail). I use Claude in Chrome via Cowork/Claude Desktop for automation workflows that need to interact with both Google Drives.

The current switch_browser behavior consistently times out after 60s and requires me to manually click "Connect" in the target browser every single time. In a typical session I might need to switch 2-3 times, and each interruption breaks the autonomous workflow that Claude is running.

My workaround: I keep Claude in Chrome connected to my business profile only and use a FUSE-mounted Google Drive for the personal account. This works for file operations but means I can't use browser automation for the personal profile at all (e.g., extracting content from web apps like Gemini that aren't accessible via API).

Of the proposed solutions, the config file option ("chromeProfile": "Work" in settings.json) would be the most useful for my workflow -- it would let me set a default profile and switch deterministically without the manual approval step each time. The interactive selection prompt would also be acceptable as long as it doesn't require switching to the browser window to click.

Would love to see this prioritized. The multi-profile use case is probably common for anyone running a business alongside personal accounts.

A workaround that works today if you're okay with CDP instead of the --chrome extension: launch a dedicated Chrome instance with an explicit debugging port and separate user-data directory.

#!/bin/bash
# chrome-isolated — launch a dedicated Chrome for automation
PORT="${1:-9222}"
PROFILE="$HOME/.chrome-claude-profile"

google-chrome \
  --remote-debugging-port="$PORT" \
  --user-data-dir="$PROFILE" \
  --no-first-run \
  --no-default-browser-check \
  "$@" &

This gives you a completely isolated Chrome instance that won't interfere with your personal browser. You can run multiple instances on different ports (9222, 9223, etc.) for different accounts.

From Claude Code, connect via http://localhost:9222 using the MCP browser tool or CDP commands. Each port maps to exactly one Chrome instance, so there's no ambiguity about which browser you're controlling.

The key is --user-data-dir — it creates a separate profile directory so cookies, extensions, and login sessions are fully isolated. You log in once to each instance and it persists across restarts.

This doesn't solve the --chrome extension targeting problem (which needs official support), but it's been reliable for deterministic browser automation in autonomous workflows.

For anyone hitting this on macOS in the meantime, I built a Claude Code plugin that solves the multi-profile drift problem at the AppleScript layer (not the Native Messaging / CDP layer that this issue is asking Anthropic to fix natively):

https://github.com/yolo-labz/claude-mac-chrome

It does NOT replace --chrome — it's a parallel skill (chrome-multi-profile) that your Claude Code session can call to drive any specific Chrome profile/window deterministically. Three signals stacked:

1. Reads ~/Library/Application Support/Google/Chrome/Local State for the authoritative profile catalog (display names, signed-in emails)
2. Extracts emails from live tab titles to map each window → profile
3. Disambiguates same-email collisions by URL-set overlap against each profile's Sessions/Tabs_<id> SNSS file

All addressing uses stable AppleScript window/tab string IDs (id of window w returns "817903115" and persists for the lifetime of the window) instead of the ordinal tab N of window M pattern, which is what causes drift in every other tool I tried.

Strictly a workaround until --chrome-profile lands natively. macOS-only. MIT, no telemetry. Hopefully useful to someone else burning time on this.

I found a silly workaround. In Cloud Desktop you can setup "Routines" under "Code" section. I created a routine that opens my Chrome 2 minutes before my Cowork schedule fires off. This makes the Chrome available for the Cowork to pick up.

native messaging fundamentally cannot target instances, the extension host connects to whichever chrome process claims the manifest name first. hit this on a macos automation layer. ended up reading Local State JSON from ~/Library/Application Support/Google/Chrome/Local State because the Default/Profile N directory convention breaks as soon as anyone creates a profile through the UI (it uses the display name as the dir). CDP with explicit --user-data-dir and --remote-debugging-port per instance is the only deterministic path across restarts. one gotcha, the websocket endpoint rotates per session so hit /json/version first to resolve the current ws url.

Adjacent workaround for users who can swap --chrome for an extension-based approach: install hangwin/mcp-chrome
and give each Chrome profile a unique bridge port + matching MCP entry in your client config. Tested with 5 profiles
running concurrently — each MCP tool prefix routes to its own profile's Chrome (own cookies, own logged-in
accounts).

Doesn't replace native --chrome-profile targeting, but unblocks the multi-profile workflow today on Windows
without --user-data-dir shenanigans.

Setup runbook + scripts (incl. profile→port mapping + chrome-mcp-doctor.ps1): https://github.com/MankhongGarden/ch
rome-mcp-windows-survival-guide#gotcha-6--multi-profile-port-collision--approach-b-workaround

Adding a +1 from the Cowork side of things — this isn't just a Claude Code CLI issue, it bites Cowork users equally hard, and Cowork users are arguably less equipped to deal with it because they're not on the command line and can't shell out to workarounds.

Concrete scenario I hit today (Cowork on macOS, two machines: Mac Mini and MBP, multiple Chrome profiles per machine):
1 list_connected_browsers returns three entries — two on the Mac Mini, one on the MBP. The auto-assigned names (Browser 1, Browser 2, Browser 3) renumber between sessions, so they can't be referenced reliably from one session to the next.
2 One Mac Mini entry was explicitly named Mac Mini at some prior connect — but it turned out to be the wrong Chrome profile (a non-primary profile signed into a different Google account). The "right" profile (logged into the account I wanted Cowork to operate as) was the unnamed Browser N entry. No way to tell from the names alone.
3 switch_browser returned Connected to browser "Mac Mini" even though I never clicked anything in any Chrome window — the wrong profile auto-accepted in the background while I was looking elsewhere. Cowork happily continued in the wrong identity.
4 There is no UI to rename a browser entry, no UI to inspect the underlying deviceId, no way for the agent to query "what Google account / profile path am I attached to right now?", and no way for the user to pin Cowork to a specific profile before starting a task.
The proposed fixes in this issue (#15125) — especially "extension displays a stable instance ID in its panel" + "user-editable friendly labels" — would solve the Cowork case completely. Even just exposing the deviceId in the extension's side panel so a Cowork user could read it out loud to the agent ("use device 2f70b1ce…") would be a meaningful improvement over today's situation.
Adding to the impact statement: in my case the wrong-profile selection happened during a DNS / email-deliverability task that touched a domain registrar account. If the agent had landed in the wrong logged-in identity unnoticed, the consequences would have ranged from "confusing" to "actively harmful." Profile targeting isn't just a productivity issue; for any task that depends on which account the agent is signed in as, it's a correctness issue.

It seems like this behavior has improved from what I've read about others' experiences. Claude can now prompt each profile to determine which one you wanted to activate, but it cannot handle multi-threading across more than one browser. E.g. if I want Task 1 doing X in one profile and Task 2 doing Y in the other profile, it fails. Connecting Task 2 will cause Task 1 to switch over with it.

This is clearly a bug and should be fixed.

+1. My setup is one Chrome profile per project, and I keep all of them open at once, so the "close every other profile" workaround isn't realistic here.

Right now Claude connects to whichever profile responds first, and the picker only shows generic "Browser 1/2" names that renumber between sessions, so it lands on the wrong profile constantly.

The option that would actually solve this for my workflow is the config one (option 4): a chromeProfile key in settings.json. If it reads from project-level .claude/settings.json, each project could pin its own profile and the mapping would just be right without me selecting anything every session. The instance-ID-in-the-panel idea (option 1) would work too, but per-project config is the one that fits a profile-per-project setup.

It'd be nice if you could PIN Claude desktop folders to specific Chrome profiles. Right now, I can't even tell when it's switching between profiles because another session used a different one. It 'forgets' open Claude tab groups.

As of v2.1.154 you can pick which connected browser Claude uses: run /chrome and choose Select browser…, or pick when prompted the first time a browser action runs with more than one connected. Each Chrome profile with the extension connects separately, so this lets you target a specific one (changelog, docs: https://code.claude.com/docs/en/chrome).

Closing as shipped — reopen if profile targeting still isn't working for you.

🤖 Generated with Claude Code

As of v2.1.154 you can pick which connected browser Claude uses: run /chrome and choose Select browser…, or pick when prompted the first time a browser action runs with more than one connected. Each Chrome profile with the extension connects separately, so this lets you target a specific one (changelog, docs: https://code.claude.com/docs/en/chrome). Closing as shipped — reopen if profile targeting still isn't working for you. 🤖 Generated with Claude Code

This still isn't really good enough; Claude Desktop doesn't even know which profile it's pointing to after it starts talking to it. You can name both browser profiles, and it immediately forgets which one it is talking to. You can't have different Claude Desktop sessions working with different profiles at the same time; it'll only work with whatever the last one you connect to is. So if y ou change something in one session, you risk clobbering whatever is going on in the other session because it can't even see that it's now using a different browser.

FWIW Cowork remains utterly confused as well