[BUG] Chrome extension fails to connect on Windows 11: MSIX package ACL blocks native host execution (os error 5)

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?

Summary (made by claude)

Chrome extension cannot connect to Claude Desktop on Windows 11. The native messaging host executable (chrome-native-host.exe) is deployed inside the MSIX package's isolated AppData folder, which Windows ACLs prevent external processes (including Chrome and even the logged-in user via PowerShell) from launching. Result: Native host has exited on every connection attempt.

Environment

• OS: Windows 11
• Claude Desktop version: Claude_1.6608.2.0_x64__pzs8sxrjxfjjc (MSIX package)
• Installer: .exe installer, run with administrator privileges
• Browser: Google Chrome (latest stable)
• AV: Norton (disabled during testing — no effect)
• Claude Code: Not installed

What Should Happen?

Symptoms

1. Chrome extension service worker console

2. Manual invocation via DevTools console

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

→ Same error: Native host has exited.

3. Direct execution of native host executable (PowerShell, normal user context)

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

→

This is the root cause: the user themselves cannot execute the binary because it lives in an MSIX-protected path. Chrome inherits the same restriction.

Reproduction

1. Install Claude Desktop on Windows 11 from the MSIX .exe installer (admin rights).
2. Install the Claude Chrome extension and log in with the same account.
3. Confirm registry key is present:

• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension
• Value points to a valid JSON manifest inside the MSIX package folder.

1. Open the extension's sidepanel and trigger any tab action → "No tab available" / extension shows disconnected.
2. Inspect service worker console → Native host has exited.

Error Messages/Logs

## 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" />

Steps to Reproduce

<img width="1335" height="940" alt="Image" src="https://github.com/user-attachments/assets/b020f950-4cff-43e0-bd14-f1c7021901ce" />

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.6608.2.0

Claude Code Version

i didn't use claude code (only cowork)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_