[BUG] Cowork binds Chrome extension actions to a browser on another machine instead of the local browser

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 15, 2026

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?

I use Cowork on multiple machines under one account: a macOS system and a new Windows 11 laptop. The Claude in Chrome extension is installed and connected on both. When I start a Cowork session on the Windows laptop, browser actions route to the Chrome extension on the Mac instead of the Chrome instance on the machine I'm actually using. From the user's perspective, the Chrome extension simply does not work on the new machine, even though it is connected to the account.

Workaround that confirms the diagnosis: list_connected_browsers shows both browsers, with the Windows browser correctly flagged isLocal: true, while the session is bound to the remote macOS browser. Manually selecting the local browser via select_browser fixes it. Users should not need to know this.

What Should Happen?

Cowork should default to binding browser actions to the Chrome extension on the same machine as the running session. The isLocal flag already exists in list_connected_browsers, so the information needed to pick the right browser is available. At minimum, Cowork should prompt the user to choose a browser when the currently bound one is not local, instead of silently routing actions to a browser on another machine.

Error Messages/Logs

Steps to Reproduce

  1. Install Claude Desktop and the Claude in Chrome extension on machine A (macOS) and use Cowork with browser actions at least once.
  2. Install Claude Desktop and the Claude in Chrome extension on machine B (a new Windows 11 laptop), same account.
  3. Start a Cowork session on machine B and ask Claude to do something in the browser.
  4. Browser actions route to the Chrome extension on machine A (the Mac), or appear to do nothing locally. To the user, the extension looks broken on the new machine.

Diagnosis: list_connected_browsers shows both browsers connected and correctly flags the Windows browser isLocal: true, but the session is bound to the remote macOS browser. Manually running select_browser with the local deviceId fixes it.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop (Cowork), latest version as of 2026-08-15; not a CLI issue

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗