Generated Chrome native-host wrapper pins a version path that the next update deletes

**Component:** Claude Code browser extension integration (Windows)
**Severity:** Medium — the extension silently stops connecting after any Claude Code update; no error is surfaced
**Status:** Currently reproducing on the reporting machine

---

## Summary

`chrome-native-host.bat` is generated once with a **hard-coded, version-pinned path** to the bundled `claude.exe`. When Claude Code updates, the old version directory is removed and the wrapper is not rewritten — so the Chrome native messaging host points at a path that no longer exists.

The extension then fails to connect, with no surfaced error.

## Evidence

```
File: C:\Users\\.claude\chrome\chrome-native-host.bat
Written: 2026-08-21 04:17

@echo off
REM Chrome native host wrapper script
REM Generated by Claude Code - do not edit manually
"…\LocalCache\Roaming\Claude\claude-code\2.1.234\claude.exe" --chrome-native-host

Target exists? False <-- 2.1.234 was removed by the update
Present on disk: 2.1.237 <-- updated 2026-08-21 22:38
```

The native messaging manifest that points at this wrapper:

```
HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
-> C:\Users\\AppData\Roaming\Claude Code\ChromeNativeHost\
com.anthropic.claude_code_browser_extension.json

{
"name": "com.anthropic.claude_code_browser_extension",
"path": "C:\\Users\\\\.claude\\chrome\\chrome-native-host.bat",
"allowed_origins": ["chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"]
}
```

## Reproduction

1. On Windows, set up the Claude Code browser extension so `chrome-native-host.bat` is generated.
2. Note the version directory it references.
3. Let the bundled Claude Code binary update (`claude-code\\claude.exe`).
4. Observe that the old version directory is gone and the `.bat` still references it.
5. The extension no longer connects. Nothing reports why.

## Expected

The wrapper resolves the current Claude Code version at **run time**, or is regenerated whenever the bundled binary updates.

## Actual

The version is baked in at generation time. Every update silently breaks the integration until the wrapper happens to be regenerated.

## Suggested fix

Resolve the binary at invocation rather than at generation. For example, have the `.bat` locate the newest version directory at run time, or point it at a stable, versionless launcher path that the updater maintains — the same pattern that would fix the identical class of bug elsewhere in the Windows integration.

---

## Related

This was found while investigating a Claude Desktop packaging failure with the same root pattern — *a path that points into a directory something else is allowed to replace.* In that case the consequence was severe: the unattended MSIX auto-update removed the working package before its replacement could register, and registration was blocked by a Chrome-held file inside the package's own data container, leaving the app unlaunchable and unrecoverable by reinstalling.

Both native messaging hosts on this machine resolve into the Claude Desktop MSIX data container:

```
com.anthropic.claude_browser_extension
-> …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
ChromeNativeHost\chrome-native-host.exe

com.anthropic.claude_code_browser_extension
-> …\.claude\chrome\chrome-native-host.bat
└─ execs …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
claude-code\2.1.234\claude.exe --chrome-native-host
```

Because Chrome holds these executables open for as long as the extension is connected, and MSIX re-registration must clear that directory, they participate directly in the Desktop failure. Filed separately for Claude Desktop.

## Environment

| | |
|---|---|
| OS | Windows 10 Pro 22H2, Build 19045.6466 |
| Claude Code | 2.1.237 bundled; wrapper pinned to 2.1.234 |
| Claude Desktop | `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc` (MSIX) |
| Browser | Google Chrome |

Start by locating the code that generates .claude\chrome\chrome-native-host.bat and the native messaging manifest path described in the issue. Reproduce an update from version 2.1.234 to 2.1.237 on Windows, then verify that the wrapper still launches the current bundled binary after the old version directory is removed and the extension reconnects.

Written by the indexing model from the issue text.