[BUG] Claude Desktop for Windows (MSIX/AppContainer) breaks Native Messaging with "Claude in Chrome" extension (related to #56949, #52766)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

> Also reported via support.anthropic.com (case ID: 215474252984400, awaiting human specialist follow-up).
> Related MSIX package family Claude_pzs8sxrjxfjjc issues: #56949 (installer wedged state), #52766 (child process exit).

🎯 Summary (English)

The Windows distribution of Claude Desktop (version 1.6608.2.0) is delivered as an MSIX package and runs inside the Windows AppContainer sandbox. As a result, the native messaging channel between Claude Desktop and the "Claude in Chrome" Chrome extension fails: the Windows Named Pipe is created correctly, but the Chrome side disconnects immediately with EOF. This makes all browser automation tools (navigate, list_connected_browsers, switch_browser, select_browser, browser_batch, tabs_context_mcp, etc.) completely unusable on Windows when invoked from Win Claude Desktop or Win-side Claude.ai web sessions.

The same Chrome extension on the same Windows machine works correctly when accessed from Claude Desktop running on a different macOS device (cloud-mediated path), confirming the Chrome extension itself is healthy.

---

🖥️ Environment

| Component | Details |
|---|---|
| Windows OS | Windows 11 (Pro/Home — confirm version) |
| Win Claude Desktop | 1.6608.2.0 (MSIX), publisher: Anthropic, PBC |
| Install path | C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\ (MSIX sandbox) |
| Installer used | Claude_Setup.exe downloaded from https://claude.ai/download (PE32+ web installer that deploys MSIX) |
| Chrome (Windows) | Stable channel (current) |
| Chrome extension | "Claude in Chrome" (Beta) v1.0.70, ID: fcoeoabgfenejglbffodgkkbkcdhcgfn |
| Comparison: Mac mini | Claude Desktop 1.6608.2 (same version) — works correctly |
| Comparison: MacBook Air M5 | Claude Desktop 1.6608.2 (same version) — works correctly |

Both Mac and Windows machines are signed into the same Anthropic account, on the same home Wi-Fi network, with the same Norton antivirus installed.

---

🧪 Steps to Reproduce

1. Fresh install Claude Desktop on Windows using Claude_Setup.exe from https://claude.ai/download
2. Confirm install path is C:\Users\<user>\AppData\Local\Packages\Claude_*\ (MSIX sandbox)
3. Install the "Claude in Chrome" Chrome extension and sign in with the same Anthropic account
4. Open a chat in Win Claude Desktop and search for browser MCP tools (e.g., ask for tools related to "browser navigate")
5. Attempt to call list_connected_browsers or navigate

❌ Actual Behavior

• tool_search initially returns the Claude in Chrome tool definitions (e.g., Claude in Chrome:navigate, :list_connected_browsers, etc.)
• However, invoking any of these tools returns:

``
⚠️ Claude in Chrome is not connected
The Chrome extension isn't reachable right now. This is often transient — the connection usually recovers automatically within a few seconds.
``

• The error persists indefinitely regardless of:
• Claude Desktop restart
• Chrome restart
• Chrome extension toggle (disable/enable)
• Chrome extension reinstall
• Windows OS restart
• Norton antivirus temporary disable
• Toggling "Claude in Chrome" off and on in Claude Desktop settings
• Complete uninstall + clean reinstall of Claude Desktop (Setup.exe always reinstalls into the same MSIX sandbox path)

✅ Expected Behavior

• list_connected_browsers returns the list of connected Chrome browsers (as it does on macOS)
• navigate, select_browser, browser_batch, etc., work normally

---

🔍 Diagnostic Evidence

1. Native Host Log

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\chrome-native-host.log:

[2026-05-11 18:26:59 INFO chrome-native-host] Chrome native host starting (version 0.1.0)
[2026-05-11 18:26:59 INFO chrome-native-host] Creating Windows named pipe: \\.\pipe\claude-mcp-browser-bridge-<user>
[2026-05-11 18:26:59 INFO chrome-native-host] Named pipe created successfully
[2026-05-11 18:26:59 INFO chrome-native-host] Pipe name: \\.\pipe\claude-mcp-browser-bridge-<user>
[2026-05-11 18:26:59 INFO chrome-native-host] Entering main message loop
[2026-05-11 18:26:59 INFO chrome-native-host] Socket server listening for connections
[2026-05-11 18:42:15 INFO chrome-native-host] Chrome disconnected (EOF received)   ← ★KEY FAILURE
[2026-05-11 18:42:15 INFO chrome-native-host] Shutting down chrome native host
[2026-05-11 18:42:15 INFO chrome-native-host] Chrome native host stopped
[2026-05-11 18:42:42 INFO chrome-native-host] Chrome native host starting (version 0.1.0)
[same lines, named pipe re-created]

Key observation: The named pipe is created successfully and the host enters its message loop. The Chrome side connects briefly, then immediately disconnects with EOF. This pattern repeats every time Chrome attempts to invoke the native messaging host.

2. Native Messaging Host Registry Entry (Chrome side, healthy)

HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
→ (Default) = C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json

The manifest path points into the MSIX package sandbox — this is where the AppContainer restrictions likely interfere with Chrome's ability to launch and maintain communication with the host process.

3. Cross-Platform Diagnostic Matrix

| Test | Result |
|---|---|
| Mac Claude Desktop 1.6259.1 → Mac Chrome | ✅ Works |
| Mac mini Claude Desktop 1.6608.2 → Mac Chrome | ✅ Works |
| MacBook Air Claude Desktop 1.6608.2 → Mac Chrome | ✅ Works |
| Mac Claude Desktop → Win Chrome (via Anthropic cloud) | ✅ Works |
| Win Claude Desktop 1.6608.2 → Win Chrome (local Native Messaging) | ❌ Fails (EOF) |
| Win Claude.ai Web (in Chrome) → Win Chrome | ❌ Tool not loaded |
| Win Claude.ai Web (in Edge) → Win Chrome | ❌ Tool not loaded |
| Win Claude Desktop after complete uninstall + clean Setup.exe reinstall | ❌ Still fails (Setup.exe deploys to same MSIX sandbox path) |
| Win after Windows OS restart | ❌ Still fails |
| Win after Norton temporary disable | ❌ Still fails (rules out AV interference) |

The version is identical (1.6608.2) between Mac mini and Windows. The differentiator is OS-level packaging: Mac is a regular app bundle; Windows is MSIX/AppContainer.

---

💡 Hypothesis

The Windows MSIX AppContainer sandbox restricts inter-process communication patterns required for Chrome's Native Messaging Host protocol. Specifically:

• Chrome (running outside the sandbox) cannot fully establish or maintain stdio/pipe communication with a host process that is inside an AppContainer
• The Named Pipe is created (the host process can create it within its own sandbox), but the Chrome side cannot complete the handshake or maintain the connection, hence EOF
• This is consistent with documented AppContainer restrictions on cross-process pipe/file/object access

---

🛠️ Workaround Confirmed (for users with both Mac and Win)

Use Claude Desktop on macOS to operate the Windows Chrome browser remotely via Anthropic cloud routing. The "Claude in Chrome" extension on Windows is itself healthy — only the local Native Messaging path from Win Claude Desktop to the same machine's Chrome is broken.

Mac Claude Desktop → Anthropic cloud → Win Chrome extension → ✅ Works
Win Claude Desktop → local Native Messaging → Win Chrome extension → ❌ EOF

---

🙏 Request

1. Short-term: Restore distribution of a non-MSIX (Win32 .exe / Squirrel) installer for Claude Desktop on Windows, so users can opt into a non-sandboxed install when they need Chrome MCP functionality.
2. Long-term: Architecturally resolve the AppContainer ↔ Chrome Native Messaging incompatibility (e.g., use a separate non-sandboxed broker process for native messaging, or document/configure AppContainer capabilities to permit the required IPC).
3. Documentation: Add a known-issue note in the Claude in Chrome documentation that the Windows MSIX build currently cannot interact with the local Chrome extension.

---

📎 Reproduction Assets Available on Request

• Full chrome-native-host.log (multiple sessions)
• Screenshots of:
• Win Claude Desktop "Apps & features" detail page showing MSIX-specific UI (Camera permission, Background app permission, Reset/Repair buttons)
• Registry editor showing com.anthropic.claude_browser_extension manifest path
• Tool search results showing tools loaded but unreachable
• Comparison screenshots from Mac mini / MacBook Air showing same version working correctly

---

This report was compiled after approximately 4 hours of systematic diagnostic work, eliminating hypotheses including: Chrome extension corruption, Chrome cache issues, sign-in mismatch, browser-based self-exclusion mechanism, IP/network-based filtering, Norton antivirus interference, version-specific regression (disproved by Mac running same 1.6608.2 successfully), Windows OS state, individual Windows install corruption (disproved by clean reinstall reproducing the issue), and several others. The MSIX/AppContainer hypothesis is the only remaining explanation consistent with all observed evidence.

What Should Happen?

Claude Desktop for Windows should be able to communicate with the "Claude in Chrome" extension via Chrome's Native Messaging protocol, so that Chrome MCP tools (navigate, list_connected_browsers, switch_browser, browser_batch, tabs_context_mcp, etc.) work the same way they work on macOS.

Specifically, after installing Claude Desktop on Windows and the Claude in Chrome extension on the same Windows machine, calling any Chrome MCP tool from Win Claude Desktop should reach the local Chrome extension successfully — as it does on macOS with the same Claude Desktop version (1.6608.2) and the same Anthropic account.

Error Messages/Logs

=== Error returned by every Chrome MCP tool call from Win Claude Desktop ===

⚠️ Claude in Chrome is not connected

The Chrome extension isn't reachable right now. This is often transient — the connection usually recovers automatically within a few seconds.

Retry the browser tool in a moment. If it keeps failing, ask the user to check that Chrome is open with the extension signed in, or use alternative approaches.

=== Persists indefinitely. Does not recover. ===


=== chrome-native-host.log ===
Location: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\chrome-native-host.log

[2026-05-11 18:26:59 INFO chrome-native-host] Chrome native host starting (version 0.1.0)
[2026-05-11 18:26:59 INFO chrome-native-host] Creating Windows named pipe: \\.\pipe\claude-mcp-browser-bridge-pika
[2026-05-11 18:26:59 INFO chrome-native-host] Named pipe created successfully
[2026-05-11 18:26:59 INFO chrome-native-host] Pipe name: \\.\pipe\claude-mcp-browser-bridge-pika
[2026-05-11 18:26:59 INFO chrome-native-host] Entering main message loop
[2026-05-11 18:26:59 INFO chrome-native-host] Socket server listening for connections
[2026-05-11 18:42:15 INFO chrome-native-host] Chrome disconnected (EOF received)  ← KEY FAILURE
[2026-05-11 18:42:15 INFO chrome-native-host] Shutting down chrome native host
[2026-05-11 18:42:15 INFO chrome-native-host] Chrome native host stopped
[2026-05-11 18:42:42 INFO chrome-native-host] Chrome native host starting (version 0.1.0)
... (repeats indefinitely with same EOF pattern)

Observation: Named pipe created successfully → Socket server listening → Chrome disconnects with EOF immediately. No Chrome MCP traffic gets through.


=== Chrome Native Messaging Host registry entry ===
Path: HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
(Default) = C:\Users\pika\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json

The manifest path points INSIDE the MSIX AppContainer sandbox — likely the root cause of the IPC failure.

Steps to Reproduce

Environment:

• Windows 11 (build XXXXX — paste your winver output)
• Win Claude Desktop 1.6608.2.0 (MSIX, AppContainer sandbox)

Install path: C:\Users\pika\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\

• Chrome (stable channel)
• Claude in Chrome extension v1.0.70, ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
• Same Anthropic account also used on Mac mini and MacBook Air (where it works correctly)

Steps:

1. Download Claude_Setup.exe from https://claude.ai/download on Windows 11
2. Run installer. Note: installer is a PE32+ executable but deploys an MSIX package — Claude Desktop ends up installed at C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\ (AppContainer sandbox)
3. Install the "Claude in Chrome" extension in Chrome on the same Windows machine, sign in with the same Anthropic account
4. Launch Claude Desktop, sign in
5. In a chat, ask Claude to use any Chrome MCP tool (e.g. "list my connected browsers")
6. Observe: list_connected_browsers returns "Claude in Chrome is not connected"
7. Check chrome-native-host.log at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\
8. Observe: named pipe is created, Chrome disconnects with EOF immediately, repeatedly

Verification that this is NOT a Chrome / extension problem:

• Same Anthropic account, same Chrome extension on the same Windows machine, when accessed FROM a different device's Claude Desktop (Mac mini or MacBook Air running Claude Desktop 1.6608.2) via Anthropic cloud routing → works perfectly. Mac → Anthropic cloud → Win Chrome extension is healthy.
• The failure is specifically Win Claude Desktop → local Native Messaging → Win Chrome extension.

Hypotheses eliminated (≈4 hours of systematic diagnosis):

• Chrome extension corruption (cloud path works from Mac)
• Network / IP filtering (same Wi-Fi, Mac works)
• Norton AV interference (temporarily disabled, no change)
• Windows OS state (restarted, no change)
• Sign-in account mismatch (verified same account everywhere)
• Version regression (Mac mini on same 1.6608.2 works)
• Individual installation corruption (clean uninstall + reinstall reproduces the bug — Setup.exe always deploys to the same MSIX sandbox path)

Remaining consistent hypothesis:
The Windows MSIX/AppContainer sandbox restricts the IPC patterns Chrome's Native Messaging Host protocol requires. Chrome can read the manifest (registered in HKCU) and locate the host EXE, but the EXE inside the AppContainer sandbox cannot complete or maintain the pipe handshake with Chrome (running outside the sandbox). Hence: named pipe creates successfully on the host side, Chrome disconnects with EOF immediately.

Related issues filed against the same MSIX package family (Claude_pzs8sxrjxfjjc):

• #56949 (MSIX wedged state during install — same package family)
• #52766 (Claude Code child process exit on same MSIX build)
• #49917 (related known MSIX issue)

Also reported via support.anthropic.com (case ID: 215474252984400, awaiting human specialist follow-up).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

N/A — first install on this Windows machine, no prior working version known

Claude Code Version

1.6608.2 (Claude Desktop for Windows, MSIX build — not Claude Code CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Important Context

This is a Claude Desktop for Windows bug, not a Claude Code CLI bug. I'm using this Claude Code issue template because related Claude Desktop / Cowork issues on the same MSIX package family (Claude_pzs8sxrjxfjjc) have been filed here previously (see #56949, #52766, #57219). If a dedicated Claude Desktop issue tracker exists elsewhere, please redirect.

Cross-Reference

• Anthropic Support case ID: 215474252984400 (escalated to human specialist, awaiting follow-up)
• Related GitHub issues (same MSIX package family Claude_pzs8sxrjxfjjc):
• #56949 — Claude Desktop installer wedged state (MSIX)
• #52766 — Claude Code child process exit on Claude Desktop MSIX
• #49917 — Related known MSIX issue
• #57219 — Claude Desktop "Claude in Chrome" allowlist not respected (related Win Claude Desktop + Chrome MCP problem)

Field Clarifications

• Claude Code Version field: I filled in 1.6608.2 because that is the version of Claude Desktop for Windows that exhibits the bug. There is no Claude Code CLI installation on this machine.
• Terminal/Shell field: N/A — Claude Desktop is a GUI Electron app, not a CLI tool.
• Is this a regression: Unknown / first install. I cannot confirm whether a prior Win Claude Desktop version worked, because I installed Claude Desktop on this Windows machine for the first time recently, and the latest available installer (Claude_Setup.exe from https://claude.ai/download) always deploys the MSIX form (verified by complete uninstall + clean reinstall — same Claude_pzs8sxrjxfjjc sandbox path every time).

Cross-Platform Diagnostic Matrix (key evidence)

| Setup | Same version | Same account | Same network | Result |
|---|---|---|---|---|
| Mac mini → Mac Chrome | Claude Desktop 1.6608.2 | ✓ | ✓ | ✅ Works |
| MacBook Air → Mac Chrome | Claude Desktop 1.6608.2 | ✓ | ✓ | ✅ Works |
| Mac → Win Chrome (via Anthropic cloud) | Claude Desktop 1.6608.2 | ✓ | ✓ | ✅ Works |
| Win Claude Desktop → Win Chrome (local Native Messaging) | Claude Desktop 1.6608.2 | ✓ | ✓ | ❌ EOF immediate disconnect |

The differentiator is OS-level packaging: macOS Claude Desktop is a regular app bundle (non-sandboxed); Windows Claude Desktop is MSIX (AppContainer sandbox). This strongly suggests the AppContainer IPC restrictions break Chrome's Native Messaging Host protocol.

Screenshots Available

I can provide:

1. Registry editor showing com.anthropic.claude_browser_extension Native Messaging Host manifest pointing into the MSIX sandbox path
2. Win Apps & Features detail page showing MSIX-specific UI (Camera permission, Background app permission, Reset/Repair buttons — none of which appear for Win32 apps)
3. Full chrome-native-host.log showing repeated EOF disconnect pattern
4. "Claude in Chrome is not connected" error in Win Claude Desktop chat

(Please request via comment if useful for triage.)

Diagnostic Time

Approximately 4 hours of systematic hypothesis elimination before arriving at the MSIX/AppContainer hypothesis. Eliminated:

• Chrome extension corruption (cloud-routed access from Mac proves extension is healthy)
• Sign-in / account mismatch (verified same account everywhere)
• Network / IP filtering (same home Wi-Fi, Mac works)
• Norton AV interference (temporarily disabled, no change)
• Windows OS state (restarted, no change)
• Individual install corruption (uninstall + clean reinstall reproduces — Setup.exe always deploys to same MSIX sandbox path)
• Version-specific regression (Mac mini on identical 1.6608.2 works)