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\<user>\.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\<user>\AppData\Roaming\Claude Code\ChromeNativeHost\
       com.anthropic.claude_code_browser_extension.json

  {
    "name": "com.anthropic.claude_code_browser_extension",
    "path": "C:\\Users\\<user>\\.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\<version>\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 |