[BUG] `mcp__claude-in-chrome__*` tools absent entirely on Windows (MSIX-hosted sessions) — present and working on macOS at identical CLI 2.1.260

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Why this is a Claude Code issue, not a Claude Desktop one

Filing here deliberately. Prior reports of this failure were routed away as
"doesn't appear to be about Claude Code" (#58009, bot-closed and locked). Respectfully, the
failing components are Claude Code's:

• The missing tools are Claude Code MCP tools (mcp__claude-in-chrome__*), absent from a

Claude Code session's tool registry.

• The native-messaging host is Claude Code's own binary:

~/.claude/chrome/chrome-native-host.bat → claude.exe --chrome-native-host.

• The failure is version-correlated with the Claude Code CLI (2.1.260), not with a Desktop

feature.

Summary

On Windows, a Claude Code session hosted by Claude Desktop has no mcp__claude-in-chrome__*
tools at all — list_connected_browsers, select_browser, tabs_context_mcp are not merely
failing, they are absent from the registry. ToolSearch for them returns no match. The server does
not appear in either the "requires authentication" or the "still connecting" lists, so it is not
registering at all.

The same Claude Code version (2.1.260) on macOS, in the Desktop chat pane, works correctly and
drives real Chrome profiles.

This is distinct from #91469 / #91485 / #91145, where the tools exist and report
"not connected". Here they never appear.

Environment — controlled A/B

| | Windows (fails) | macOS (works) |
|---|---|---|
| Claude Code CLI | 2.1.260 | 2.1.260 |
| Surface | Desktop chat pane | Desktop chat pane |
| Desktop package | MSIX, Claude_1.46388.2.0_x64__pzs8sxrjxfjjc, CN="Anthropic, PBC" | PKG |
| Host binary in use | %APPDATA%\Claude\claude-code\2.1.260\claude.exe | — |
| Native host manifest path | C:\Users\<u>\.claude\chrome\chrome-native-host.bat | /Users/<u>/.claude/chrome/chrome-native-host |
| Extension ID | fcoeoabgfenejglbffodgkkbkcdhcgfn | same |
| Extension version | 1.0.90, enabled, no disable reasons | — |
| mcp__claude-in-chrome__* | absent | present, working |

Both machines: Windows 11 / macOS, same Chrome extension build, same account.

What has already been eliminated

Please do not close this as a user misconfiguration — the config layer was checked
exhaustively against a known-good Mac:

1. Native-messaging registry key — present:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension

1. Manifest → wrapper → binary chain — intact and resolving end to end.
2. Wrapper parity — Windows .bat and macOS shell wrapper are the same wrapper in the same

location; both route to a Claude Code CLI process, neither to an app bundle.

1. Extension ID — identical on both.
2. Browser registration coverage — Windows registers 7 browsers (Chrome, Chromium, Edge,

Brave, Arc, Opera, Vivaldi) vs the Mac's 2. The failing machine is a superset.

1. CLI version — identical, 2.1.260, verified by running-process path (not PATH, which

reports an unrelated npm build).

1. Extension install/enable state — installed and enabled in the target profile.

Steps to reproduce

1. Windows 11, Claude Desktop (MSIX) with Claude Code 2.1.260.
2. Install "Claude in Chrome" (1.0.90), sign in, confirm the native host is registered.
3. Open a Claude Code session in the Desktop chat pane.
4. Ask for list_connected_browsers, or ToolSearch for it.

Expected: the tool exists (even if it returns an empty browser roster).
Actual: no mcp__claude-in-chrome__* tool exists in the session at all.

Candidate causes (not verified — offered to save triage time)

• Stale OAuth token cache. oauth:tokenCache and oauth:tokenCacheV2 are present in

%APPDATA%\Claude\config.json on the failing machine. Per #91469, the cache is cleared on 403
but never on 401, causing an endless loop. If a failed bridge auth prevents the MCP server from
registering, that would explain absent-vs-erroring tools. Untested at time of filing.

• MSIX / AppContainer. Windows ships MSIX; macOS ships PKG; the legacy Squirrel .exe is

unsandboxed. Fits a Windows-only native-messaging failure. Counter-evidence: the installed package
declares runFullTrust and unvirtualizedResources.

Asks

1. Distinguish "bridge failed to connect/authenticate" from "connected, zero browsers."

Absent tools give the user nothing to act on. Register the tools and let them return a real
error.

1. Invalidate the cached token on 401, not only 403 (per #91469).
2. State Windows support explicitly in the docs. The Chrome docs do not say the integration is

unavailable or degraded on Windows Desktop, so users spend hours on correctly-configured machines.

1. Please route rather than bot-close. If this belongs to another team, move it — #58009 was

closed in 3 days and locked in 7, and its technical content was never assessed.

Prior art — all closed, none fixed

| Issue | Opened | Closed | Outcome |
|---|---|---|---|
| #24539 | 9 Feb 2026 | 13 Feb | duplicate |
| #25162 | 12 Feb 2026 | 30 Mar | bug, has repro, platform:windows → stale |
| #52766 | 24 Apr 2026 | 27 Apr | duplicate |
| #56949 | 7 May 2026 | 10 May | duplicate |
| #58009 | 11 May 2026 | 14 May | invalid — bot-closed, then locked |
| #58201 | 12 May 2026 | 20 Jul | bug, has repro, platform:windows, area:chrome → stale |

Two were accepted by triage as reproducible Windows bugs and then auto-closed for inactivity
without a fix. Roughly 15 further Claude-in-Chrome issues were opened in the week before this
filing.

Happy to provide logs, run diagnostics, or test a patch build on the affected machine.