Claude in Chrome: after Chrome relaunches (update), session client never re-dials the new bridge socket and the restored tab group cannot be re-adopted

Summary

A long-running Claude Code CLI session permanently loses Claude in Chrome after Chrome restarts itself (here: applying a pending Chrome update). Two independent defects combine so that nothing the user can do short of killing the session and giving up the current page brings the browser back:

1. The session's in-process bridge client never re-dials the new native-host socket. Every mcp__claude-in-chrome__* tool returns "Browser extension is not connected" for the rest of the session, while the native host is healthy and answers the same execute_tool request when sent to its unix socket directly. /chrome > "Reconnect extension" and "Select browser…" do not recover it.
2. The extension refuses to re-adopt the tab group Chrome restored. The "Claude" tab group (with the page under test in it) survives the Chrome restart and is still recorded in the extension's tabGroups storage with isMcp: true, but every tool call on that tab is rejected with "not in Claude's tab group for this session", under no session_scope and under the session id. The only offered recovery (createIfEmpty: true / tabs_create_mcp) opens a new tab, so the existing page state cannot be reused.

Please handle Chrome restarts (update relaunch, manual relaunch, crash) end to end: re-scan the socket directory on the next tool call, make "Reconnect extension" actually reset the client, and let a session re-adopt an existing Claude tab group instead of orphaning it.

Environment

• Claude Code 2.1.260 (native install, macOS, Darwin 25.4.0, Apple Silicon)
• Google Chrome 152.0.7977.83 (updated from .76), single profile
• Claude in Chrome extension 1.0.91 (fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Claude Desktop app not involved (only the Claude Code native host manifest com.anthropic.claude_code_browser_extension.json is registered; the spawned host is claude --chrome-native-host)
• Session started 2026-09-03 08:48 and had been driving a localhost:3000 tab successfully for days.

Timeline (from ps, pmset -g log, Chrome profile files)

| When (local) | Event |
|---|---|
| 2026-09-04 14:10 | Chrome 152.0.7977.83 installed on disk while Chrome kept running on .76 (pending relaunch) |
| 2026-09-06 14:42 | Mac woke from sleep |
| 2026-09-06 17:56:11 | Chrome relaunched (Google Chrome --no-startup-window); profile Last Version rewritten to .83 |
| 2026-09-06 17:56:12 | New native host spawned by that Chrome (pid 30308), socket /tmp/claude-mcp-browser-bridge-<user>/30308.sock |
| 2026-09-06 18:04 | Mac went to sleep (i.e. sleep came after the break, and later sleep/wake cycles did not affect the bridge) |
| 2026-09-07 | Every browser tool call in the still-running session: "Browser extension is not connected" |

So the trigger is the Chrome relaunch, not sleep/wake and not a network change.

What is healthy (verified)

• Native host pid 30308 is alive, child of the Chrome pid, stdio pipes to Chrome intact, listening on the unix socket.
• Socket dir is 0700 and the socket is 0600, both owned by the user, so the client's validateSocketSecurity would pass.
• Only one .sock exists in the directory (the stale one from the pre-restart host is gone), so directory scanning would find the right socket.
• Sending the framed request (4-byte LE length + JSON) to the socket by hand:

{"method":"execute_tool","params":{"client_id":"claude-code","tool":"tabs_context_mcp","args":{}}}

returns a normal extension answer:

No MCP tab groups found. Use createIfEmpty: true to create one.

What is broken

1. Session client never reconnects

From the session, all of these return "Browser extension is not connected":
tabs_context_mcp (with and without createIfEmpty), list_connected_browsers, switch_browser, select_browser.

The bundled client (SocketConnectionError / reconnect logic in the CLI binary) gives up after 100 attempts with "Will retry on next tool call", but subsequent tool calls do not re-dial (no client ever appears on the socket in lsof -U; the host is the only holder). /chrome > "Reconnect extension" and "Select browser…" were both tried by the user and changed nothing.

The MCP log for the server only contains the startup lines and no bridge-level reconnect entries:
~/Library/Caches/claude-cli-nodejs/<cwd>/mcp-logs-claude-in-chrome/2026-09-02T23-48-02-118Z.jsonl

2. Restored tab group cannot be re-adopted

Chrome restored the "Claude" tab group containing the page under test. The extension's Local Extension Settings still hold it:

{"1277550962":{"chromeGroupId":279849679,"createdAt":1788762609689,"domain":"blank","mainTabId":1277550962,
 "memberStates":{"1277550962":{"indicatorState":"none","isMcp":true,"previousIndicatorState":"pulsing"}}}}

Yet, sent directly to the healthy bridge:

• tabs_context_mcp with no session_scope: "No MCP tab groups found."
• tabs_context_mcp with session_scope = the session id (and several other values): "No tab group exists for this session."
• find / read_page / get_page_text with tabId: 1277550962: "Tab 1277550962 is not in Claude's tab group for this session. Tools can only target tabs inside the group."

The session-to-group mapping appears to live only in memory and is lost on Chrome restart (same family as #87774 / #89335), and there is no API to attach an existing tab or group to the current session. The only way out is createIfEmpty: true or tabs_create_mcp, which opens a new tab and abandons the page the user was testing.

Expected

• After Chrome restarts (update relaunch, manual relaunch, crash), the next browser tool call should re-scan /tmp/claude-mcp-browser-bridge-<user>/ and connect to whatever host is listening.
• "Reconnect extension" should reset the in-process client, not only the extension side.
• A tab group that Chrome restored and that the extension still records as isMcp should be re-adoptable by a session (e.g. tabs_context_mcp picks it up, or an explicit adopt/attach tool), instead of forcing a new tab.

Related

• #88558, #86793: same "worked, then permanently not connected" symptom, trigger unknown there.
• #61117, #73903 (both auto-closed as inactive): same socket-level diagnosis (CLI never dials the healthy host socket).
• #87774, #89335: session-to-tab-group mapping lost, recovery orphans tabs.
• Also filed through /feedback, receipt f5650ef9-5083-4e8c-836d-12efa9858a4b.