/chrome Reconnect never registers claude-in-chrome MCP tools when a session starts with the bridge down (survives --resume) #98135

Summary

When a Claude Code session starts with the Claude-in-Chrome extension bridge down, there is no way to bring the browser tools up from inside the session — or even by restarting into the same session. The mcp__claude-in-chrome__* tools are simply never registered.

Environment

• Claude Code CLI on macOS (Darwin 25.5.0, Apple Silicon)
• Model: claude-fable-5
• Claude-in-Chrome extension installed and previously working in other sessions

What happened

1. Session started with the notice that Claude-in-Chrome is enabled for the session but "the browser connection is not working (it failed or was disabled), so mcp__claude-in-chrome__* tools are not available."
2. Ran /chrome → Reconnect extension. The command completed with no output.
3. The model then found no mcp__claude-in-chrome__* tools: ToolSearch over the deferred-tool list returns no matches, and calling mcp__claude-in-chrome__tabs_context_mcp directly returns No such tool available.
4. Exited and relaunched with claude --resume <session-id> (full new process). Same result: no browser tools registered in the resumed session.

Expected

Either /chrome Reconnect should register the MCP tools into the running session, or a fresh process resuming the session should re-attempt the extension connection and register them. If reconnection genuinely requires action on the Chrome side (toggling the extension, relaunching Chrome), /chrome should say so instead of reporting success while the tools stay unavailable.

Impact

Mid-task there is no recovery path: the session had staged work (files prepped for a Gmail-attachment flow) that only a browser tool could finish, and the user had to complete the last step manually. Restarting the session loses nothing thanks to --resume, but it also fixes nothing, which turns into a frustrating loop of "reconnect → try → still dead."

Notes

• Observed 2026-09-29, ~05:30–06:15 CDT.
• The same session also could not fall back to the desktop computer-use path (macOS Accessibility not granted), so this bug left zero UI-automation routes — worth considering the two failure modes together from a recovery-UX angle.