Chrome extension unreachable for ~5 minutes after every sleep/standby resume (reconnect backoff never resets on wake)

What's Wrong?

On a Windows laptop with Modern Standby and Fast Startup, the Claude in Chrome extension loses its bridge connection every time the machine suspends, and then stays unreachable for about 5 minutes after resume. Every mcp__claude-in-chrome__* call fails with "Chrome extension isn't reachable right now" or "The hidden tabs_context_mcp lookup did not respond within 8s".

My local Claude Code transcripts show 13 such failed tool calls on 18 Sep 2026 and 21 on 19 Sep, and every cluster starts within minutes of a Windows resume event (Kernel-Power 507 exit Modern Standby, Kernel-Power 107 exit sleep, Kernel-Boot 27 Fast Startup resume).

Looking at the shipped service worker (assets/service-worker.ts-*.js, extension 1.0.94), the bridge reconnect delay is Math.min(2e3 * Math.pow(1.5, nt - 1), gt) with gt = 3e5, so it saturates at 5 minutes. Attempts that fail while the machine is suspended keep incrementing nt, and nothing resets it on resume:

• the 30 second bridge-keepalive alarm only calls the connect function when Date.now() >= tt, so it honors the stale delay
• there is no chrome.idle listener
• on Modern Standby the network stays connected, so navigator.onLine never flips and the online handler does not fire

The extension's own https://clau.de/chrome/reconnect handler resets the counter and reconnects instantly, which suggests the connection logic is fine and only the retry scheduling is wrong.

What Should Happen?

After the machine resumes, the extension should re-establish the bridge connection within a few seconds. A tool call that arrives while the socket is closed should trigger an immediate reconnect attempt instead of waiting out a backoff that grew while the device was asleep.

Steps to Reproduce

1. On a Windows 11 laptop with Modern Standby (powercfg /a reports "Standby (S0 Low Power Idle) Network Connected") and Fast Startup enabled, sign in to the Claude Chrome extension and run any browser tool from Claude Code so the bridge connection is live.
2. Leave the machine idle until the screen turns off and it enters Modern Standby (Windows default is 3 minutes), or shut down and power on again, which with Fast Startup is a hibernate resume.
3. Wake the machine. Leave Chrome running the whole time.
4. Immediately ask Claude Code to run a browser tool, for example tabs_context_mcp.

Result: the calls fail with "Chrome extension isn't reachable right now" for roughly 5 minutes and then recover on their own. Opening https://clau.de/chrome/reconnect in the browser fixes it instantly at any point during that window.

Error Messages / Logs

Chrome extension isn't reachable right now. If browser tools were working earlier in this session, this is usually transient - retry in a moment.

The hidden tabs_context_mcp lookup did not respond within 8s. The Chrome extension may be slow to start, or the computer running that browser may be offline or asleep. Retry navigate, or call tabs_context_mcp explicitly to get a tabId first.

Example correlation from one day (local time, Europe/Prague):

19 Sep 06:50:48  Kernel-Power 506  enter Modern Standby
19 Sep 07:01:29  Kernel-Power 507  exit Modern Standby
19 Sep 07:05 to 07:18  six failed browser tool calls, then recovery
19 Sep 10:29:02  enter standby,  10:34:26  exit standby
19 Sep 10:37 to 10:39  failed browser tool calls

Environment

• Claude Chrome extension 1.0.94, Chrome 153.0.8010.54
• Windows 11 Pro build 26200, Modern Standby + Fast Startup enabled
• Claude Code 2.1.233, running inside the Claude desktop app for Windows
• Browser tools go through the cloud bridge (wss://bridge.claudeusercontent.com)
• Is this a regression: unknown, it has behaved this way since I started using the extension

Workaround

A Windows scheduled task bound to the resume events (Kernel-Power 507 and 107, Kernel-Boot 27) opens https://clau.de/chrome/reconnect, which the extension intercepts in webNavigation.onBeforeNavigate, resets the attempt counter, reconnects and closes the tab. That took the failures from 21 on one day down to under 5 a day. The remaining ones happen when Chrome is started some time after the resume.

Suggested fixes, roughly in order of value

1. Use the existing 30 second bridge-keepalive alarm as a suspend detector. If the gap between two ticks is much larger than 30 seconds, the machine was suspended, so reset the attempt counter and reconnect immediately instead of honoring the stored delay.
2. Do not increment the backoff counter for attempts made while the device is suspended or offline.
3. When a tool call arrives for a device whose socket is closed, force an immediate reconnect attempt instead of returning "isn't reachable".
4. Add chrome.idle.onStateChanged as a reconnect trigger. It needs no permission beyond the ones the extension already requests.
5. Show the connection state and a Reconnect button in the extension popup. Today the only manual recovery is the undocumented clau.de/chrome/reconnect URL, which a user will not find on their own.
6. Expose the same reconnect action to the Claude Code side, for example as an MCP tool, so an agent can recover the connection instead of telling the user to retry.

Happy to provide extension logs or test a build.