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

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary

When the "Claude in Chrome" extension is connected to a Claude account, a Claude session (Claude Code CLI, etc.) can enumerate and drive every browser connected to that account — including browsers on other physical machines. The problem is not that cross-machine access exists (it can be genuinely useful); it's that there is no adequate way to identify which connected browser is which, and no per-device consent step before a browser can be driven. This is both a usability gap and a security exposure.

Framing

This is submitted as a feature request and security concern. The underlying issue applies even to a single user who has the extension installed on two of their own machines: the identification and consent model is too weak to reliably tell devices apart or to prevent an unintended device from being controlled.

What happens

• Browsers with the extension register against the Claude account.
• list_connected_browsers returns only: a generic display label ("Browser 1", "Browser 2", …), an opaque deviceId, an osPlatform (e.g. "Windows"), and a connect timestamp.
• There is no machine/host name, no OS username, no location, no browser-profile name, no logged-in-identity hint — nothing that lets a human (or the model) tell which physical browser a given entry is.
• The extension itself surfaces no identifying information either — we asked the in-browser assistant directly and it had nothing it could report about its own device.
• The "Browser N" labels and the deviceId ordering are not stable across calls, so you can't even rely on positional identity.

Concrete incident (2026-07-11)

• A default/implicit browser selection reached a browser on a different machine than the one being worked on, rather than the local PC.
• Before we realized the browser wasn't local, real Google Cloud resources were created under a Google account that happened to be signed into that other browser: a GCP project, a service account, and a downloaded service-account key. (All later deleted/revoked.)
• We also observed a live, actively-controlled local browser that did not appear in list_connected_browsers at one point — so the enumeration can be incomplete as well as unidentifiable.
• Net effect: there was no reliable way to know, or verify in advance, which physical machine any given action would actually hit.

Security concern (threat model)

Because a session can drive any browser connected to the account, and identification is weak/absent, this is a real attack surface:

• If an attacker can install the extension on a victim's PC and connect it to the attacker's Claude account (or trick a victim into connecting to the attacker's account), the attacker's Claude session could then drive the victim's browser — reading email, accessing or deleting the Google account, exfiltrating anything the browser is logged into, etc. As I understand it, anything that browser is signed into is reachable.
• The reverse also holds (what we hit accidentally): a session silently reaching a browser on a different machine than intended.
• Stronger device identification + explicit per-device pairing/consent would mitigate both the accidental and the malicious cases.

Environment

• Claude Code CLI on Windows 11
• Google Chrome (single profile, single Windows user on the affected PC) + "Claude in Chrome" extension installed & enabled

Proposed Solution

Feature requests

1. Meaningful per-browser identification in list_connected_browsers (and any picker UI): machine/host name, OS user, browser profile name, approximate geolocation or IP-derived location, and a stable unique ID. Enough for a person and the model to confidently distinguish devices.
2. Self-identification from the extension: let a user open the extension on a given machine and see that machine's identifier, so they can match "which browser am I?" to the list.
3. Explicit per-device pairing/consent before any session can drive a browser — opt-in per browser rather than automatic enrollment. And/or default to controlling only the browser on the machine where the session originates, with cross-machine control as an explicit opt-in.
4. Never silently default to an arbitrary connected browser; always require confirmation and clearly display the identity of the selected device before acting.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Concrete incident (2026-07-11)

• A default/implicit browser selection reached a browser on a different machine than the one being worked on, rather than the local PC.
• Before we realized the browser wasn't local, real Google Cloud resources were created under a Google account that happened to be signed into that other browser: a GCP project, a service account, and a downloaded service-account key. (All later deleted/revoked.)
• We also observed a live, actively-controlled local browser that did not appear in list_connected_browsers at one point — so the enumeration can be incomplete as well as unidentifiable.
• Net effect: there was no reliable way to know, or verify in advance, which physical machine any given action would actually hit.

Additional Context

_No response_