claude-code - 💡(How to fix) Fix [BUG] Windows 11 Chrome extension cannot connect to Claude Desktop — MSIX package ACL blocks native host execution (os error 5), persists after full clean reinstall

Preflight Checklist

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

What's Wrong?

Summary

On Windows 11, the Claude for Chrome extension cannot connect to Claude Desktop. The native messaging host executable (chrome-native-host.exe) is deployed inside an MSIX-isolated package folder where Windows ACLs prevent external processes — including Chrome and even the logged-in user via PowerShell — from launching the .exe. Result: every Chrome extension tool call returns "not connected."

A complete clean reinstall on 2026-05-12 (full MSIX removal via PowerShell + leftover folder/registry cleanup + PC reboot + fresh install from claude.com/download) did NOT resolve the issue. Symptoms persist with identical version and signature.

Environment

• OS: Windows 11
• Claude Desktop: Claude_1.6608.2.0_x64__pzs8sxrjxfjjc (MSIX package)
• SignatureKind: Developer (sideloaded, not Store-signed)
• Installer: ClaudeSetup.exe from https://claude.com/download, run as administrator with own admin account
• Browser: Google Chrome (latest stable)
• Antivirus: Norton (fully disabled during testing — no effect)
• Claude Code CLI: Not installed (this issue is in Claude Desktop / Chrome extension, not Claude Code)

Post-Reinstall Package Inspection

Name : Claude Version : 1.6608.2.0 PackageFullName : Claude_1.6608.2.0_x64__pzs8sxrjxfjjc InstallLocation : C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc PackageUserInformation : {S-1-5-21-...-1001 [user]: Installed} ← single-user, correct SID (no split-account bug) SignatureKind : Developer ← NOT Store/Production Status : Ok SignatureKind: Developer indicates the MSIX is signed with a sideload certificate, not a retail Microsoft Store signature. Combined with deployment under the protected WindowsApps\ container, this creates the access-denial pattern documented across multiple existing issues.

Already Attempted (User-side troubleshooting fully exhausted)

• Claude Desktop reinstall (admin context) — no change
• Chrome extension reinstall — no change
• Cleared all claude.ai / anthropic.com / claude.com / claudeusercontent.com site data in Chrome
• Registry keys under HKCU\Software\Google\Chrome\NativeMessagingHosts verified
• Norton AV fully disabled during testing — no change
• Verified allowed_origins in manifest matches installed extension ID

Complete clean reinstall on 2026-05-12:

• PowerShell: Get-AppxPackage -Name "*Claude*" -AllUsers | Remove-AppxPackage -AllUsers
• Verified Test-Path returned False for all Claude package folders
• Deleted leftover AppData\Local\Claude\Logs folder
• Cleaned HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.* keys
• PC reboot
• Verified Get-AppxPackage -Name "*Claude*" returned empty (clean state)
• Fresh download and install from claude.com/download as admin user
• Result: Same Version (1.6608.2.0), same SignatureKind (Developer), same symptoms reproduced

PowerShell direct execution of native host binary (bypassing Chrome entirely):

& "C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe"

→ Error: Access is denied. (os error 5)

This is the root cause indicator: even the logged-in user (whose SID owns the package) cannot launch the binary. Chrome inherits the same restriction.

Cross-machine verification: Same installer with same account works perfectly on a separate Windows laptop. Issue is specific to this PC's MSIX/ACL state — not a generic installer bug.

Layer separation verified: On the same desktop PC, claude.ai workspace Bash works correctly (after clearing claude.ai site cookies). This isolates the Chrome extension issue as purely a native messaging / MSIX ACL problem, separate from any broader workspace or network issue.

Root Cause Analysis

C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc\ is a protected MSIX package container. Windows enforces ACLs on this path such that only the MSIX-registered app itself can launch executables inside it. External processes — Chrome (which spawns the native host as a child process) and the user via PowerShell — receive Access denied.

For Chrome native messaging to work under MSIX, the installer must either:

1. Deploy chrome-native-host.exe and its dependencies to a location outside the MSIX package container (e.g., %LOCALAPPDATA%\AnthropicChromeNativeHost\) and register the manifest pointing to that location, OR
2. Use a Windows-supported sponsor/proxy mechanism that allows external callers to cross the MSIX isolation boundary.

The manifest currently points directly at the protected package path. This appears to be a packaging-side bug.

The fact that the same installer works on a different Windows machine suggests the bug surfaces depending on per-PC ACL state interaction with the Developer-signed sideload package. A retail Store-signed (or properly cross-signed) MSIX would not run into this boundary.

Related Issues

Likely same or adjacent root cause:

• #51160
• #23218
• #21363
• #15336
• #25162 (split-account bug — different but adjacent MSIX packaging issue)

What Should Happen?

Chrome extension should successfully connect to Claude Desktop via native messaging after a clean install. Specifically:

1. chrome-native-host.exe should be launchable by Chrome (and other external callers) without ACL denial
2. list_connected_browsers and other Chrome extension tools should return valid results, not "not connected"
3. The MSIX installer should deploy native messaging components to a location accessible to external callers, or use a sponsor/proxy mechanism that crosses the MSIX isolation boundary
4. This worked correctly before the Squirrel → MSIX installer transition in February 2026

Error Messages/Logs

## 1. Chrome extension tool call response (claude.ai)
"Claude in Chrome extension is currently not connected."
"Chrome extension program is not currently connected."

(Same response for any Chrome extension tool — list_connected_browsers, get current tab URL, etc.)

## 2. PowerShell direct execution of native host binary (as logged-in user)
PS C:\> & "C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe"
Error: Access is denied. (os error 5)

## 3. DevTools sidepanel console (after reinstall)
Unchecked runtime.lastError: Cannot access a chrome:// URL
(Plus various CSP violations for external analytics scripts — unrelated to the connection issue)

Note: No "Native host has exited" appeared in sidepanel context after reinstall, but tool call result "not connected" confirms native messaging connection failure persists regardless of active tab type (verified with naver.com as active tab).

Steps to Reproduce

1. Fresh Windows 11 with admin user (or admin-privileged standard user account)
2. Download ClaudeSetup.exe from https://claude.com/download
3. Right-click → Run as administrator (UAC: Yes, with own admin credentials — NOT a different admin account, to avoid split-account bug #25162)
4. Install Claude Desktop (MSIX package registers as Claude_pzs8sxrjxfjjc)
5. Install Claude Chrome extension from https://claude.com/claude-for-chrome
6. Sign in to claude.ai with the same account on both Claude Desktop and Chrome extension
7. In claude.ai, invoke any Chrome extension tool, e.g.: "list_connected_browsers"
8. Observe: Response returns "not connected" instead of browser list

To confirm MSIX ACL root cause (bypassing Chrome): 9. Open PowerShell as logged-in user (no need for admin elevation) 10. Run: & "C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe" 11. Observe: Error: Access is denied. (os error 5)

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — This issue is in Claude Desktop (MSIX 1.6608.2.0) and Claude for Chrome extension, NOT in Claude Code CLI. Claude Code CLI is not installed on this system. Issue is being filed in this repository because no dedicated Claude Desktop / Claude for Chrome issue tracker exists publicly.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional Context

This issue has been ongoing for 5+ days (since 2026-05-08) on this specific Windows 11 desktop PC. The exact same Claude Desktop installer works perfectly on my separate Windows laptop, indicating the issue is not in the installer itself but in how the MSIX package interacts with this PC's specific ACL state.

Workspace Bash Verification (Same PC, Different Layer)

To rule out workspace/network/account issues, I verified that the workspace Bash tool in claude.ai works correctly on the same desktop PC after clearing claude.ai site cookies in Chrome. This confirms:

• claude.ai account and authentication: working
• Network connectivity to Anthropic infrastructure: working
• Chrome browser baseline functionality: working
• Workspace container provisioning: working

The Chrome extension failure is therefore isolated to the native messaging layer between Chrome extension and Claude Desktop, which is exactly the MSIX ACL issue described in this report.

Pre-Filed Support Ticket

I also filed a support ticket via support.claude.com on 2026-05-11 with the same issue but received no response within 5 days. This GitHub issue serves as a public record and request for engineering review, in parallel with a follow-up to support.

Why This Repository

I'm aware that anthropics/claude-code is the Claude Code CLI repository, and my issue is in Claude Desktop / Claude for Chrome extension. However, there is no public issue tracker for Claude Desktop or Claude for Chrome that I could find. Similar Claude Desktop packaging issues have been filed and accepted in this repository previously (e.g., #25162 for the split-account bug). If this repository is not the correct destination, please advise where to file this report.

Available on Request

I have additional diagnostic data available if needed:

• Full Get-AppxPackage output (pre-removal, post-removal verification, post-reinstall)
• DevTools Service Worker console captures
• DevTools sidepanel context console captures (showing CSP violations and Cannot access a chrome:// URL error)
• Screenshots of the "not connected" tool call responses
• PowerShell direct execution screenshots showing os error 5
• Step-by-step reinstall procedure log

Happy to provide any of the above as comments to this issue.