[BUG] Claude in Chrome: phantom/disconnected tab state persists across full Chrome + app restart (macOS desktop app)

Summary

claude-in-chrome MCP tools (navigate, tabs_context_mcp, tabs_close_mcp) report success against a tab that isn't backed by the real Chrome process. The fake state survives a full Chrome quit and a full Claude desktop app restart, returning the same stale tab id and page content both times.

This is very likely the same root cause as #79313 ("phantom tabs accept and answer javascript_tool execution after Chrome has closed them"), which was auto-closed as stale rather than fixed. Filing fresh per the stale-bot's own instructions, with a repro on a different platform/interface (macOS + Claude desktop app, vs. the original Windows + CLI report) and a simpler trigger.

Environment

• macOS (Darwin 25.6.0), Claude desktop app
• Chrome extension "Claude in Chrome" v1.0.93, confirmed enabled in chrome://extensions with "On all sites" access
• Single Chrome window/process confirmed throughout (no second profile, channel, or off-screen window)

Reproduction

1. tabs_context_mcp {createIfEmpty: true} → new tab id → navigate to a URL. Tool reports success with the correct page title/URL.
2. An OS-level screenshot of the actual Chrome window taken immediately after shows no such tab — just a plain "New Tab".
3. tabs_close_mcp on that tab id → tool reports the tab closed. Real Chrome window: unchanged, same tabs still visible.
4. Fully quit Chrome (Cmd+Q) and relaunch it. Separately, fully restarted the Claude desktop app too.
5. tabs_context_mcp again → returns the same tab id, with the same stale page title/URL from before either restart.

Real Chrome tab ids are not stable across a process restart, so this value cannot be coming from the live browser — the extension/session is driving some other, persistent, disconnected browser context.

Evidence ruling out a wrong-window mixup

Used a separate OS-automation tool (independent of Claude-in-Chrome) to:

• Enumerate all Chrome windows (app_list_windows equivalent) — exactly one window found, matching what's on screen.
• Take a full-desktop screenshot — confirmed only one Chrome window exists anywhere on the display, no minimized/off-screen/other-Space window.
• List running apps — only one Chrome process (com.google.Chrome, stable channel), no Canary/Beta/Dev/Chromium also installed.

So this isn't a case of screenshotting the wrong window among several — there is only one real window, and it never reflects what the extension reports doing.

Expected

tabs_context_mcp reflects the real browser's current tab state; a full Chrome restart invalidates any previously-tracked tab id.

Actual

Tool calls report plausible success indefinitely against a target with no corresponding real tab, and that fake state outlives both a full Chrome restart and a full Claude desktop app restart.

Related: #79313 (closed as stale, not fixed — same symptom, different platform/interface, harder-to-hit trigger).