[BUG] Remote Chrome instance reported as isLocal: true and made controllable without explicit remote-device consent

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?

A Chrome extension instance running on a different physical computer is reported as isLocal: true by list_connected_browsers, and it can be fully driven (navigate, create tabs, run page scripts) from another machine's session without any consent prompt or remote-device warning.

Two things are wrong:

1. The isLocal flag lies. It's the main signal that distinguishes "my machine" from "a remote machine," but it reports true even for an instance on a separate computer. This makes it unusable as a trust/security boundary.
2. Silent cross-device control. Because the remote instance looks local, selecting it and issuing commands just works — the other computer's browser gets navigated and manipulated with nothing shown on either machine to authorize it.

Confirmed live with two computers side by side: commands issued from Machine A opened tabs (Google, Instagram) on Machine B's screen, while both instances still claimed isLocal: true. The user never approved remote control of the second machine, and any authenticated sessions open there (Instagram, Facebook, Google, etc.) are exposed to control from a different machine.

What Should Happen?

A browser running on a different physical machine should be reported as isLocal: false, and controlling it should require explicit on-device consent before any command runs not silent cross-device control.

Error Messages/Logs

Steps to Reproduce

1. Install and sign into the Claude-in-Chrome extension on two separate physical computers (Computer A and Computer B) using the same account.
2. On Computer A, open a Claude Code / browser-automation session.
3. Call list_connected_browsers. Both instances are returned for example:

[
{"deviceId":"<id-A>","name":"Browser 1","osPlatform":"Windows","isLocal":true},
{"deviceId":"<id-B>","name":"Browser 2","osPlatform":"Windows","isLocal":true}
]

1. Note that the instance physically on Computer B is also flagged "isLocal": true.
2. From Computer A's session, select the Computer B instance:

select_browser with that instance's deviceId.

1. Issue an automation command against it, e.g. navigate to https://www.instagram.com, then tabs_create_mcp.
2. Observe on Computer B's screen: the tab actually opens/navigates on Computer B, driven entirely from Computer A's session with no consent prompt or remote-device warning shown on either machine.

Observed in practice: With two machines side by side, commands issued from Computer A opened Google + Instagram on Computer B, while Computer A itself had Google + Facebook. Both instances still reported isLocal: true, so nothing distinguished the remote machine from the local one.

Minimal repro note: No special code or files are required the only precondition is two extension instances on two physical machines under one account. The bug is in the locality reporting (isLocal) and the absence of a remote-control consent gate, not in any page content.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_