[BUG] Claude-in-Chrome: session started before the extension re-registers binds a stale browser registration and is denied on ALL domains for its whole lifetime (root-caused with timestamps)

Summary

A Claude Code session that starts before the Chrome extension has (re)registered its browser connection binds a stale browser registration and is then denied on all domains ("Navigation to this domain is not allowed" / "Permission denied for this action on this domain") for the entire lifetime of that session — while a session started on the same machine a minute later works perfectly. No approval prompt ever renders in the broken session. We root-caused this with process/registration timestamps; details below.

This likely explains the "works sometimes, denied other times, nothing fixes it" pattern reported in #43255, #49979, #66074, #50606, #74696.

Environment

• Windows 11 Pro (10.0.26200)
• Claude Code desktop app, multiple concurrent sessions
• Claude in Chrome extension, Google Chrome (stable)
• Reproduced across several days and many sessions

Symptoms in a broken session

• tabs_context_mcp and tabs_create_mcp work (tab group is created, tabs listed)
• navigate, read_page, computer (screenshot), find are all denied on every domain — including the user's own sites and https://example.com
• No "Claude in Chrome wants to..." approval prompt ever appears
• list_connected_browsers returns a row whose connectedAt timestamp predates the current app start (a leftover registration from a previous app run)

Root cause (verified with timestamps)

After a full app restart we captured this sequence:

| Event | Time |
|---|---|
| Claude app core process starts | 08:21:17 |
| Session A starts | 08:21:23 |
| Chrome extension registers its live connection | 08:21:33 |
| Session B starts | 08:22:46 |

• Session A was born 10 seconds before the live browser registration existed. The only registration visible to it was a stale one from the previous app run. It bound that dead handle and was denied on all domains for its whole life.
• Session B, started 73 seconds after the extension registered, had full browser access with normal approval prompts.

So the binding is decided once at session startup and never re-evaluated. A session that loses the race never recovers.

Things that do NOT fix a broken session (all tested)

• Restarting Chrome (fully, including tray)
• Toggling the extension in chrome://extensions
• Chrome extension site-access settings / adding sites to any allowlist
• Installing the extension in Edge instead (same wall)
• Killing every other Claude session process (the broken session stays broken)
• Fully restarting the Claude app and resuming the session — the session comes back still broken, so the dead binding appears to be restored with the session
• Switching the session's permission mode

What DOES work

• Starting (or reloading) the session after the extension has registered — i.e., start the app, wait ~20–30 s for the extension to connect, then open the session that needs the browser.
• Any new session started after the extension registered works immediately.

Suggested fixes

1. On any denied browser action, re-resolve the browser registration instead of permanently trusting the handle bound at session start (or re-bind whenever the bound registration's connectedAt is older than the current app start).
2. Expire stale registrations: a registration from a previous app run should never be offered to a new session.
3. Surface the failure honestly: "browser connection is stale, reconnect" instead of the misleading per-domain "Navigation to this domain is not allowed", which sends users down allowlist/permissions rabbit holes (see the linked issues — none of them found the cause because the error message points away from it).

Diagnostic for anyone else hitting this

Run list_connected_browsers and compare each row's connectedAt against the Claude app's process start time. A row older than the app start is a dead registration; if your session's actions are denied on all domains while tab management works, your session is bound to that dead row. Reload the session after Chrome reconnects.