Claude in Chrome (Edge, Windows): extension intermittently disconnects and screenshots time out on background tabs; native host stays alive

Summary

On Windows 11 with Microsoft Edge, the Claude in Chrome extension drops its connection to Claude Code / the Claude desktop app intermittently. The browser tools report "Claude in Chrome is not connected" and then recover on their own a few seconds later. Separately, screenshot calls fail with Script injection timed out after 5000ms when the target tab is in a background window.

The local native messaging host process stays alive across the drop, so the break appears to be on the extension side (service worker lifecycle / its connection to the relay), not in the native host.

Environment

• OS: Windows 11 Home (China edition), build 10.0.26300
• Browser: Microsoft Edge 154.0.4258.62
• Extension: Claude v1.0.99 (fcoeoabgfenejglbffodgkkbkcdhcgfn), Manifest V3, installed from the Chrome Web Store
• Client: Claude desktop app (Windows Store/MSIX package), Code tab, driving the extension through the claude-in-chrome MCP tools
• Native host: chrome-native-host.exe, registered under both HKCU\Software\Microsoft\Edge\NativeMessagingHosts and HKCU\Software\Google\Chrome\NativeMessagingHosts; allowed_origins includes the extension ID above
• Edge has about 13 other extensions installed (12 of them MV3). No enterprise policies. Sleeping tabs / efficiency mode were not explicitly configured (defaults).

Observed behavior

1. Browser tools worked normally during a test session: navigate, screenshot, read_page, find, get_page_text, javascript_tool, click/type/hover/key/scroll, form_input (select and checkbox), and console and network reads all returned correct results.
2. Calling tabs_close_mcp on the test tab returned "Claude in Chrome is not connected".
3. A few seconds later list_connected_browsers showed the browser connected again, with a different connectedAt (about 13 minutes after the earlier value) and a different display name (Browser 1 became the machine name). So the connection was torn down and re-established between the two calls.
4. The chrome-native-host.exe process kept the same PID (started hours earlier) through the whole sequence, so the native host did not restart.
5. In an earlier session a screenshot call failed with:

Error capturing screenshot: Script injection timed out after 5000ms — the page is busy or mid-navigation ... (scale: 0.7).

1. In the test session, document.visibilityState on the MCP tab was "hidden" (document.hidden === true) because the tab group lives in a window the user is not looking at. This may be related to the injection timeouts, since Edge throttles or freezes hidden tabs.

Expected behavior

The connection should survive service worker restarts, or reconnect fast enough that tool calls do not fail in between. Tool calls on tabs inside the MCP tab group should not time out just because that window is in the background.

Additional notes

• resize_window reports success but window.innerWidth did not change (window was maximized). Probably separate, but noting it.
• The computer zoom action returned a blank region after a scroll; probably user error, mentioned only for completeness.

Possibly related

• #87774 (service worker restarts drop the session-to-tab-group mapping, macOS)
• #96540 (extension disconnects mid-batch during an extended session)
• #96539 (screenshot/JS calls intermittently slow on some pages)

This report adds a Windows + Edge data point and shows that the native host survives the drop.

Ideas

• Keep the service worker alive with a periodic alarm or an open port while an MCP session is active, and reconnect automatically on wake-up.
• Make the tool layer retry once with a short backoff on not connected, before surfacing the error.
• Mention Edge "Sleeping tabs" and "Efficiency mode" in the troubleshooting docs, or exempt the MCP tab group from them.