[BUG] --claude-in-chrome-mcp subprocess version drift causes Chrome bridge failures after auto-update

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?

Two related version drift bugs in the --claude-in-chrome MCP browser bridge that cause Chrome integration failures after Claude Code auto-updates during long-running sessions.

Root Cause

When a session is started with claude --chrome, the --claude-in-chrome-mcp subprocess is spawned from the Claude Code version installed at that time. If Claude Code auto-updates during the session, three components end up running different versions:

| Component | Version | Started |
|---|---|---|
| Claude Code main process | 2.1.25 | Current |
| --claude-in-chrome-mcp subprocess | 2.1.19 | Session start (stale) |
| Native host wrapper | 2.1.25 (after fix) | After Chrome restart |
| Chrome native host process | Desktop app binary | After Chrome restart |

The MCP browser bridge subprocess continues running the old binary (2.1.19) from session start. When Chrome restarts, the native host socket is recreated, but the stale MCP subprocess can't reconnect or has a protocol mismatch with the current native host.

Bug 1: Native host wrapper hardcodes version path

The native host wrapper at ~/.claude/chrome/chrome-native-host hardcodes a specific version path (e.g. ~/.local/share/claude/versions/2.1.22) instead of using the current symlink. After auto-updates, Chrome's native host runs the wrong (old) version.

Bug 2: Long-running sessions don't refresh MCP subprocess

When Claude Code auto-updates, the --claude-in-chrome-mcp subprocess is not restarted or updated. It stays on the version from session start, causing version drift between the subprocess and the native host. This is particularly impactful for sessions that run for hours or days.

What Should Happen?

1. Native host wrapper should use the current symlink (e.g. ~/.local/share/claude/current) instead of hardcoding a specific version path. This ensures Chrome's native host always runs the latest installed version.
2. Long-running sessions should detect auto-updates and restart the --claude-in-chrome-mcp subprocess to match the updated Claude Code version. This could be done via version check on reconnect, a file watcher on the symlink, or periodic health checks.

Error Messages/Logs

$ ps aux | grep claude-in-chrome
PID 40852: /Users/user/.local/share/claude/versions/2.1.19 --claude-in-chrome-mcp
# Note: main Claude Code process is 2.1.25, but MCP subprocess is still 2.1.19 from session start

# Native host wrapper was pointing to hardcoded path:
$ cat ~/.claude/chrome/chrome-native-host
# ... contained hardcoded path to versions/2.1.22 instead of using current symlink

# Chrome bridge errors after Chrome restart due to version mismatch
# Frame with ID 0 is showing error page

Steps to Reproduce

1. Start a long-running Claude Code session with claude --chrome
2. 2. Note the version of the --claude-in-chrome-mcp subprocess (e.g. 2.1.19)
3. 3. Allow Claude Code to auto-update during the session (e.g. to 2.1.25)
4. 4. Restart Chrome (or let it restart on its own)
5. 5. Attempt to use browser automation tools via MCP
6. 6. The Chrome bridge fails — the stale MCP subprocess (2.1.19) can't communicate with the updated native host

Additionally, inspect ~/.claude/chrome/chrome-native-host — it hardcodes a version path instead of using the current symlink, so even a fresh Chrome native host may run the wrong version after an update.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.25 (Claude Code) — MCP subprocess was 2.1.19

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_