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-/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//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-/` 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.

Start by tracing the bundled client's SocketConnectionError/reconnect logic and the /chrome "Reconnect extension" entry point, then inspect tabs_context_mcp and tabs_create_mcp handling. Use the reported socket directory and restored tab-group state as the reproduction, and consider the work done when a restarted Chrome bridge reconnects and the restored Claude tab group can be re-adopted without opening a replacement tab.

索引モデルが issue の本文から書いたものです。