claude-code - 💡(How to fix) Fix [BUG] Chrome extension fails to connect on Windows 11: MSIX package ACL blocks native host execution (os error 5) [2 comments, 2 participants]

chrome.runtime.connectNative('com.anthropic.claude_browser_extension')

---

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

---

## Troubleshooting Already Attempted

- [x] Full reinstall of Claude Desktop (admin) — no change.
- [x] Reinstall Chrome extension — no change.
- [x] Verified registry key under `HKCU\Software\Google\Chrome\NativeMessagingHosts` is correctly registered and the JSON manifest is valid.
- [x] Verified Claude Desktop is running and logged in before connection attempts.
- [x] Disabled Norton antivirus completely — no change.
- [x] Confirmed allowed_origins in the manifest match the installed extension IDs.
- [x] Triggered native host manually via DevTools `chrome.runtime.connectNative(...)` — same error.
- [x] Attempted direct execution of `chrome-native-host.exe` from PowerShell — fails with `os error 5` (Access Denied), confirming the binary itself is unreachable to external callers.
- [x] **Cross-PC verification:** the identical installer works on a different Windows laptop with the same account. Issue is specific to this machine's MSIX/ACL state.

## Root Cause Analysis

`C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\` is the **MSIX isolated package directory**. Windows protects this path with ACLs that restrict executable launches to the MSIX app itself. External processes — including Chrome (which spawns the native host as a child process) and even the interactive user via PowerShell — receive `Access is denied`.

For Chrome native messaging to work under MSIX, the installer must either:
1. Deploy a copy of `chrome-native-host.exe` (plus its dependencies) to a location outside the MSIX package container (e.g., `%LOCALAPPDATA%\AnthropicChromeNativeHost\`) and register the manifest to point there, **or**
2. Use a Windows-supported sponsor/proxy mechanism that lets external callers traverse the MSIX boundary.

Currently the manifest points directly into the protected package path, which appears to be the installer bug.

### Application event log (corroborating)
".NET Runtime" errors related to "profile API connection infrastructure" appear in `eventvwr.msc → Windows Logs → Application` correlated with each connection attempt — consistent with ACL-blocked process spawn.

## Workaround Attempted (and why it likely fails)

Copying the native host folder to `%LOCALAPPDATA%\AnthropicChromeNativeHost\` and updating the manifest/registry to point there is a candidate workaround, but:
- Dependent DLLs/resources inside the MSIX package may not resolve outside the container.
- Even if the relocated `.exe` launches, IPC back to the Claude Desktop process inside the MSIX sandbox (named pipe / local socket) is likely blocked by the same isolation boundary.

This is a packaging-side fix, not a user-side fix.

## Related Issues

Possibly the same root cause as (Windows-side reports):
- #51160
- #23218
- #21363
- #15336

## Requested Outcome

Modify the MSIX installer to deploy the Chrome native messaging host components to a non-isolated location and register the manifest accordingly, so that Chrome (and other external callers) can launch it.

<img width="1335" height="940" alt="Image" src="https://github.com/user-attachments/assets/4d105b38-d5a2-4db7-9b3b-ed7630e6443c" />