Claude --chrome connects to wrong browser when multiple Chrome instances on LAN

[wstock]

Description

When running claude --chrome on a machine with multiple Chrome instances on the same LAN (each with the Claude extension installed), the connection can go to the wrong browser. There's no way to specify which Chrome instance to connect to.

Environment

• Ubuntu host (n100) running Claude Code with --chrome for automated token renewal via systemd timer
• Windows gaming PC (BIGRIG) on the same LAN, also running Chrome with the Claude extension
• Both machines logged into the same claude.ai account

Behavior

• claude --chrome connects to whichever Chrome extension responds first
• The automated renewal script on the Ubuntu host connected to BIGRIG's Chrome instead of the local one
• switch_browser exists but requires manual user interaction (clicking "Connect"), making it unsuitable for unattended/automated use
• No way to specify a target browser by name, hostname, or ID programmatically

Workaround

Added a navigator.platform check after connecting to detect if the browser is on the expected OS (Linux vs Win32) and log a warning. The OAuth flow works regardless of which browser handles it, so we proceed with a warning rather than failing.

Feature Request

It would be useful to have:

1. A way to target a specific named browser in --chrome mode (e.g., --chrome-browser "n100")
2. Or auto-prefer the local machine's Chrome over remote ones
3. Or a non-interactive switch_browser that can specify a target by name

This would make --chrome reliable for unattended automation on multi-machine setups.

[aeghnnsw]

Same issue — two machines, connects to the wrong browser regularly. Local-first priority would fix it for me. switch_browser requiring manual confirmation every time is too disruptive.

[spiveym]

claude code should obviously default to the browser located on the machine in use by default. There should absolutely be no reason why it should connect to another browser instance on a local network.

[zirinisp]

Same issue. Actually, it took me a while to understand what was going on because it was losing the connection and was asking to connect again, and basically it was jumping from one machine to the other. It's going to be nice to be able to connect its machine to one browser or even make this some kind of feature, and then my MacBook can run the browser on my Mac Mini, my desktop; even that would be nice, but I think that we need some control. Otherwise, it is a mess.

[Ovid]

Yeah, I'm gonna pile on to this bug. I am not happy. claude --chrome is so amazing I just switched to the Claude Chrome €180 a month plan because Chrome integration eats tokens like popcorn at a horror movie. However, it's so powerful that it's worth every penny.

And then things went wrong.

My role is both uplifting the engineering capabilities of a couple of hundred developers while simultaneously trying to guide the AI adoption and making friends by saying things like, "Are you out of your mind? No, you cannot use AI for [redacted]."

So I'm in the office, sitting in a leadership meeting, with people from at least five countries present. You know what those meetings are are, right? Serious meetings with serious people dealing with serious problems and they do not play games during leadership meetings. But I was.

Part of my role is one I adopted myself: experimenting with numerous AI technologies and seeing how far I could push them and share learnings with our teams. I created a game, currently at roughly 30K lines of code (not counting tests), and by using Claude with superpowers, a few custom skills, and a unique workflow I've created, I can build amazing software with very little effort and have decent architecture. One of those pieces of software is the game and the Chrome integration led me to UAT (user acceptance testing) and it's been incredible in finding bugs ... until it stopped working.

My laptop's open during the meeting when I suddenly noticed some movement in Chrome. The game I had been using the Chrome plugin to do UAT with suddenly fires up, even though the Chrome integration had stopped working days ago. No idea why it stopped working. None. Tried repeatedly debugging. Everything seemed set up correctly. I removed the plugin (and filed a long report explaining why) and then reinstalled. Still didn't work. But suddenly, here's the plugin working, rerunning my game's UAT run in Chrome during the middle of the leadership meeting.

I'm trying to act casual and pay attention to the discussion about [redacted], but Claude is thumbing its nose at me. I'm switching to all of my running Claude instances, trying to figure out what's going on and shut it off, but no, they're not running this. What the hell? I figured it was some mysterious bug in this beta software, running in the background. I exited my Claude instances. The UAT was still running. What the heck?

So, um, security probably missed the issue that I can install dangerously insane plugins in Chrome, but I'm the person charged with guiding our AI implementations, so I regularly explore strange things. I only gave the Chrome plugin access to localhost on three specific ports, using software I had written myself. I was sure it was safe (because I'm obviously an idiot).

So here, during the meeting, suddenly a tab opens up and Claude is playing a damned game! in the middle of this meeting. I'm very lucky that this meeting was over Zoom and I wasn't screen sharing.

Something is seriously weird, I have no idea what's going on, but I have 217 other things I have to deal with, so I pray that things aren't as bad as they seem and I get back to other work, thinking I'll deal with this after I leave the office.

So I get back home and there's my personal laptop sitting open. I had installed the Chrome plugin on that, too, asking it to do the UAT testing that my work laptop couldn't. I checked its logs and discovered that, somehow, it had connected to my work laptop while I was in another city. My Chrome on my work laptop isn't even logged into the same account, but my Claude access, of course, is.

Here's an image of my personal laptop, on the left, running UAT on my work laptop, on the right.

OK. Serious bug, not good, with my personal laptop able to connect to my work laptop, but then ...

Right now, my wife and daughter happen to be in another country and we are having a video call, when suddenly I notice that my personal laptop's Chrome is doing something interesting. UAT has now switched back to my personal laptop. I'm paying €180 a month just for this one feature and I've now had multiple UAT runs broken because of this.

(In both instances of the UAT switches, I had to click something from Claude Chrome plugin about naming the laptops, but I forgot to take screenshots and during the meeting, I was too distracted to really pay attention to this).

So I'm running UAT on my personal laptop again, after having removed the Claude plugin from my work computer, and hoping that nothing else weird happens. So far it seems to be fine, but definitely not happy.

[Ovid]

If anyone's curious, here are Claude's notes from the UAT run while I was in the office. You can see near the end where it wrote, "CRITICAL UAT NOTE: Browser extension disconnected during gameplay at Ross 154. When reconnecting, it opened a new Chrome window which loaded a DIFFERENT save game ("Rocinante" instead of "Rust Bucket"). This is because saves are stored in localStorage which is per-browser-profile/window."

[spiveym]

If anyone's curious, here are Claude's notes from the UAT run while I was in the office. You can see near the end where it wrote, "CRITICAL UAT NOTE: Browser extension disconnected during gameplay at Ross 154. When reconnecting, it opened a new Chrome window which loaded a DIFFERENT save game ("Rocinante" instead of "Rust Bucket"). This is because saves are stored in localStorage which is per-browser-profile/window."

with all due respect, link out to it if you feel it's valuable, otherwise it's just text taking up 90% of this issue page.

[Ovid]

@spiveym You're absolutely right! ;) Fixed now.

[tbrodeen]

I sit at my main desk with a MacBook running Cowork. About six feet away, a Windows machine is also running, both on the same local network. I can see both screens from where I sit.
I gave Cowork a URL to work from in Chrome on my Mac. It started executing, and a Chrome window opened and started running commands on my Windows machine instead. Cowork on my Mac decided to run its Chrome session from a completely different computer.
This also explains a longer-running frustration. I've been fighting with Cowork for a while over it seemingly not spawning browsers. It may have been opening them on one of my six other networked machines the entire time. From Cowork's perspective everything succeeded. From mine, nothing happened.
Claude thinks it might be related to Chrome DevTools Protocol. CDP binds to a network port (typically 9222), and if multiple machines on the same LAN have Chrome with remote debugging enabled, Cowork could be discovering or connecting to whichever instance responds first rather than the local one. So any machine on the network with that port open could win the race, and there's currently zero indication when Cowork reaches across the network to a different host.