anthropics / anthropics/claude-code

Bug: Claude for Chrome extension installed and enabled, but never registers as a connected browser in a Cowork cloud session

Ouverte
#89,551 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub
area:chrome area:cowork bug has repro platform:macos
Langage dominant
Python
Étoiles
145k
Forks
23.1k
Métriques de merge des PR
Métriques de PR en attente

Description

# Bug: Claude for Chrome extension installed and enabled, but never registers as a connected browser in a Cowork cloud session

**Labels:** bug, claude-in-chrome

## Summary

In a Cowork (remote/cloud) session, all `mcp__claude-in-chrome__*` tools report that no browser is connected, even though the Claude for Chrome extension is installed and enabled in the local Chrome. The extension never appears in `list_connected_browsers`, so no browser automation is possible. The separate `remote-devices` desktop bridge to the *same* Mac works normally, which suggests the desktop↔cloud link is healthy and the failure is specific to Chrome extension pairing.

## Environment

- Session type: Cowork mode, remote/cloud container (Claude Agent SDK)
- Configured model: `claude-opus-5`
- Desktop app version: 1.34493.1 (Electron 42.9.2, Node 24.18.1)
- OS: macOS, arm64 (`darwin`)
- Device name: macbook-pro-4-local
- Chrome: Claude for Chrome extension present and toggled ON (verified at `chrome://extensions` — listed as "Claude / Claude in Chrome")
- Other extension installed: 1Password
- Session account: arvind@factsoftware.com

## Steps to reproduce

1. Start a Cowork cloud session on the desktop app.
2. Confirm the Claude for Chrome extension is installed and enabled at `chrome://extensions`.
3. Ask Claude to perform any browser action, or call the tools directly:
- `mcp__claude-in-chrome__list_connected_browsers`
- `mcp__claude-in-chrome__tabs_context_mcp` with `createIfEmpty: true`
- `mcp__claude-in-chrome__switch_browser`

## Expected behaviour

`list_connected_browsers` returns at least one entry for the local Chrome, and `tabs_context_mcp` creates or returns a tab group so browser automation can proceed.

## Actual behaviour

- `list_connected_browsers` → `[]` (empty array, every time)
- `tabs_context_mcp {createIfEmpty: true}` → `Browser extension is not connected. Please ensure the Claude browser extension is installed and running (https://claude.ai/chrome), and that you are logged into claude.ai with the same account as Claude Code...`
- `switch_browser` → `No other browsers available to switch to. Open Chrome with the Claude extension in another browser to switch.`

Note that `switch_browser` is documented as broadcasting a connect prompt to *every* Chrome with the extension installed. It never surfaced a prompt in the local Chrome, so the broadcast does not appear to reach an installed-but-unpaired extension.

## What was already tried

- 6 separate checks spread over roughly 10 minutes
- 2 full Chrome quit-and-relaunch cycles (not just window close)
- Verified extension is installed AND enabled via `chrome://extensions`
- `switch_browser` broadcast (no prompt appeared in Chrome)

## Contrast: the device bridge works

In the same session, `mcp__remote-devices__get_device_info` succeeds and returns full device details (platform, app version, home directories). So the desktop app is reachable from the cloud container; only the Chrome extension pairing fails.

## Impact

Browser automation is completely unavailable in the session with no actionable diagnostic. The error message points at three possible causes (not installed / not running / account mismatch) without indicating which applies, so there is no way to tell an account mismatch apart from a failed handshake.

## Suggested improvements

1. Have `list_connected_browsers` or the error message distinguish "no extension detected at all" from "extension detected but signed into a different account" — and name the account the session expects.
2. Surface the extension's signed-in account somewhere queryable, so a mismatch is diagnosable without guesswork.
3. Make `switch_browser`'s broadcast reach installed-but-unpaired extensions, or state explicitly that it only reaches already-authenticated ones.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

Start by reproducing the issue with list_connected_browsers, tabs_context_mcp, and switch_browser in a Cowork cloud session, while confirming the extension is enabled in Chrome. Trace the Chrome extension pairing and account-handshake path against the working remote-devices bridge. Done should distinguish missing, unpaired, and account-mismatched extensions or otherwise make the failure actionable.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
electron
Domaine
api, cloud, desktop
Type d'issue
Bug
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
Active
Clarté
Plutôt claire
Accessibilité débutants
35/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.