[FEATURE] Claude in Chrome: connected browser can be driven cross-machine with no reliable device identification

Adding a concrete instance of the security half of this, from a setup where the ambiguity is fully resolvable — one machine, one owner, no second computer.

Environment: macOS Darwin 25.5.0, Claude desktop 1.24012.9, claude-code 2.1.219, extension 1.0.84.

list_connected_browsers returns three devices, all "isLocal": true, all "osPlatform": "macOS":

0bc2d9ca-…842bf0e    Browser 1
c35f32b7-…78505ee9   Browser 2
ff7bdecb-…66faf70    Browser 3

Only two can exist. Exhaustive enumeration of the machine:

• find ~/Library/Application\ Support -type d -name fcoeoabgfenejglbffodgkkbkcdhcgfn returns exactly two hits — Chrome Default and Profile 3.
• Their Local Extension Settings LevelDBs contain 0bc2d9ca… and c35f32b7… respectively. Neither contains ff7bdecb….
• One Chrome browser process. No other Chromium-family browser installed and running. Six further Chrome profiles exist, none with the extension.
• The account owner has no second computer.

Then the decisive test — quit Chrome entirely, quit the desktop app entirely, reopen both:

0bc2d9ca   connected 15:14:26   (2.2 min ago)    <- matches the restart
c35f32b7   connected 15:14:26   (2.2 min ago)    <- matches the restart
ff7bdecb   connected 14:32:30   (44.1 min ago)   <- unaffected

The third browser's connection survived a full restart of both Chrome and the Claude desktop app on the only machine involved. It is not on this machine, and the account owner has no way to find out what it is.

Ruled out, since it is the obvious first guess: this is not the desktop app's own in-app browser pane. That pane runs in Electron session partitions (~/Library/Application Support/Claude/Partitions/launch-preview-*), not a Chrome profile, and carries no extension. Opening it and re-running list_connected_browsers adds no device and does not refresh ff7bdecb's connectedAt. The connection also predates the app process by 42 minutes and survived its restart untouched.

This is the gap the issue describes, with one detail worth adding: isLocal: true is reported for a browser that demonstrably is not local. On this account the flag appears to track "this app has paired with that deviceId before" — all three IDs sit in preferences.chromeExtension.pairedFromDeviceIds in ~/Library/Application Support/Claude/claude_desktop_config.json — rather than machine identity. So the one field a user would reach for to answer "is that mine?" returns a confident wrong answer.

Mitigating here: the unknown device has never been selected or driven. Across all ~/Library/Logs/Claude/main*.log, selections run 575 × 0bc2d9ca, 108 × c35f32b7, 0 × ff7bdecb. But nothing in the product surfaces that, and nothing would have stopped a session from targeting it — the tool-use gate presents all three as equivalent choices.

Two asks beyond the ones already in the issue:

1. Make isLocal mean local, or drop the field. A wrong answer is worse than none.
2. Give the account owner a list of connected browsers with last-seen and a revoke button, the way active sessions already work in account settings. Right now there is no way to disconnect a browser you cannot physically reach.

Thanks for the extension — it does a lot of real work here daily. This is a gap in something otherwise very useful.

Follow-up to my comment above, with the consent-prompt test run. It answers the "is that browser mine?" question by observation rather than inference, and the answer is worse than I expected.

switch_browser broadcasts a Connect confirmation to every connected extension. I fired it at a moment when list_connected_browsers confirmed three connected devices — the two Chrome profiles on this machine plus the unidentified ff7bdecb…, all three stamped within a 267 ms spread.

The account owner watched both Chrome windows for the full window. Two prompts appeared. One in each of his own profiles. There was no third prompt anywhere on his screen, and the pairing log confirms only one device answered:

19:45:23 [Chrome Extension MCP] Paired with "<name redacted>" (0bc2d9ca)

Three devices connected, two consent surfaces rendered. So a browser that the account can enumerate, and that a session could have been pointed at, has no consent UI reachable by the person who owns the account. There is no product surface anywhere — not list_connected_browsers, not account settings' Active sessions, not the extension itself — where that device can be seen, named, or disconnected.

Two smaller findings from the same run, both of which make the multi-browser picker harder to use safely:

1. Browser names are stripped before they reach the model. That device was named "<name redacted>" at 19:45:23, and independently at 09:20:46 earlier the same day. Every list_connected_browsers read before, between, and after returns name: "Browser 1". The name reaches the log and the user's own picker; the agent only ever sees the placeholder. (This looks like the same root as #70542.)
2. The Browser N numbers are not stable across reads. The single deviceId 0bc2d9ca… was labelled Browser 2, Browser 1, Browser 2, Browser 3, Browser 1 across five pairings in one day. So when a tool result says "pick Browser 1", that label identifies nothing — and if a user re-picks from a list whose numbering shifted under them, they can hand the agent a different machine than the one they chose a few minutes earlier.

One correction to something I nearly filed: switch_browser returning No browser responded within the timeout does not mean the broadcast failed. On the first attempt I read that as the tool being broken (it matches #56878) and was about to report it as such. The prompts had in fact rendered correctly in both windows — the owner simply came back after the two-minute window. The only instrument that can distinguish "nothing was delivered" from "nobody clicked" is the person looking at the screen, which is itself part of the usability problem here.

Net: the cross-machine capability described in this issue is real, reachable, and currently unobservable from the owning account's side. Everything above is from one ordinary two-profile setup, not a contrived one.

Correction to my two comments above. My "no second computer" premise was false, and the security inference I built on it does not hold. The identification gap is real, but it is narrower and sharper than I described.

I re-ran the switch_browser consent probe, this time with every machine I have access to open and a person watching each screen. A third prompt did appear — on a different computer I own, in my own Chrome profile signed in there. The extension reached that machine through ordinary Chrome profile sync; nobody installed it. My earlier probe reported "no third prompt anywhere" because I only ever looked at my own screen.

Retracting specifically:

• "one machine, one owner, no second computer" — there was a second computer.
• "a browser the account can enumerate has no consent surface" — it had one, on a screen I was not looking at.

What still stands, and it is what made this take three days to identify:

1. isLocal is wrong. The tool documents the field as "whether it appears to be on this computer", and it returned "isLocal": true for a browser on a different machine. Every physical count on the host contradicted it at the same moment: three browsers reported connected, two chrome-native-host unix sockets, one Chromium process, two extension install directories. isLocal is the one signal a user would naturally trust to answer "is that browser mine?", and here it answered incorrectly.

2. Names set through switch_browser do not persist. I named both of my own browsers during the Connect flow. Within the hour list_connected_browsers reported them as "Browser 1" and "Browser 2" again, and the two ordinals had swapped between the devices — so the labels are not stable identifiers either.

3. Chrome profile sync installs the extension on every machine you sign that profile into. That is Chrome working as designed, but the consequence is a device appearing in the list that the user never installed and cannot place.

Together those leave a user with nothing to identify a device by: no hostname, no last-seen, no stable label, and a locality flag that can be incorrect. The smallest change that would have resolved this immediately is a correct isLocal, plus a hostname or a persistent user-assigned name in list_connected_browsers.

Environment: macOS Darwin 25.6.0, Claude desktop 1.24012.9, extension 1.0.84.