Chrome extension service worker never initiates MCP bridge connection (Linux/AUR)
Summary
The Claude Chrome extension installs and authenticates successfully in Google Chrome on Linux, but its service worker never executes the MCP bridge initialization code. The native messaging host crashes on startup due to missing DISABLE_AUTOUPDATER env var (AUR package issue), and even after fixing that, the extension's bridge logic never activates.
Environment
- OS: Linux 6.19.11-arch1-1 (Arch Linux)
- Chrome: Google Chrome 147.0.7727.55
- Claude Code: 2.1.105 (installed via AUR: https://aur.archlinux.org/packages/claude-code)
- Extension: Claude 1.0.68
Two issues found
1. Native host crashes due to auto-updater (AUR-specific)
The AUR package installs Claude Code at /opt/claude-code/bin/claude with a wrapper at /usr/bin/claude that sets DISABLE_AUTOUPDATER=1. However, claude --chrome generates ~/.claude/chrome/chrome-native-host pointing directly to /opt/claude-code/bin/claude, bypassing the wrapper. Without DISABLE_AUTOUPDATER, the native host crashes immediately after Chrome's native messaging connects to it.
Error in extension service worker: Unchecked runtime.lastError: Native host has exited.
Workaround: Setting DISABLE_AUTOUPDATER=1 in the user environment (via ~/.config/environment.d/) so Chrome passes it to the native host. Patching the script directly doesn't survive restarts since claude --chrome regenerates it.
Suggested fix: The generated chrome-native-host script should include export DISABLE_AUTOUPDATER=1, or it should call through /usr/bin/claude (or $(which claude)) instead of hardcoding the binary path.
2. Extension service worker never runs bridge logic
After fixing the native host crash, the extension's service worker remains completely dormant:
- Service worker DevTools console is empty (no logs even on Verbose)
mcpConnectedis never written to extension storage (or staysfalse)chrome.runtime.connectNative()from DevTools works — returns a port, no errors, native host stays alive- But the extension never calls
connectNativeon its own chrome_ext_bridge_enabledfeature flag istrue(source:defaultValue)- Extension has valid OAuth tokens (
accessToken,refreshToken) - Pairing was completed (
bridgeDisplayNameset) browserControlPermissionAccepted: true- Claude Code has 10+ active connections to
bridge.claudeusercontent.com - Chrome has connections to the same bridge server
- But the extension never joins the bridge for MCP tool calls
Steps to reproduce
- Install Claude Code via AUR package
- Install Claude extension in Google Chrome
- Log into claude.ai in Chrome
- Complete extension pairing
- Run
claude --chrome - Invoke any
mcp__claude-in-chrome__*tool → "Browser extension is not connected"
Diagnostic details
- Initially tried Chromium (known unsupported due to server-side feature flag). Switched to Google Chrome — same result for issue #2.
- The cloud bridge (
wss://bridge.claudeusercontent.com) is the data path, not local unix sockets. Both sides connect to the bridge server but the extension never initiates the MCP handshake. - No other Claude Code sessions running during final tests.
- Extension toggled off/on, Chrome restarted multiple times — no change.
Expected behavior
After pairing and authentication, the extension's service worker should automatically initiate the MCP bridge connection via native messaging, allowing Claude Code's mcp__claude-in-chrome__* tools to function.
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Additional findings
After further debugging, the native host crash (issue 1) was resolved — setting
DISABLE_AUTOUPDATER=1in the environment and creating a persistent wrapper script fixes the crash. Native host stays alive, responds to manualconnectNativefrom the service worker DevTools console.However, the core problem is deeper:
The extension's service worker never calls
connectNativeon its own. After toggling the extension off/on, restarting Chrome, opening the side panel, navigating to claude.ai — the service worker remains completely silent. Zero console output even on Verbose. No native messaging connection attempt.Manually calling
chrome.runtime.connectNative("com.anthropic.claude_code_browser_extension")from the service worker DevTools console works — returns a port, no errors, native host spawns and stays alive. But the extension's own code never executes this path.The
--claude-in-chrome-mcpMCP subprocess does appear to be registered correctly byclaude --chrome(the error message "Browser extension is not connected" comes from within the MCP server, confirming it's running). The disconnect is entirely on the extension side — its bridge initialization logic never fires.Environment note
The native host manifest was updated to point to a wrapper script that sets
DISABLE_AUTOUPDATER=1(necessary for AUR installs whereclaude --chromeregenerates the native host script on every startup without the env var).This is not a duplicate of the suggested issues:
CLAUDE_CODE_OAUTH_TOKEN, ensuringtengu_copper_bridgestaystrue) doesn't apply here; both are already correct in our setupThis is the same issue as #41608 (Linux, MCP client never connects to bridge socket), with the additional finding that the extension's service worker never initiates the native messaging connection either. Both the Claude Code side and the extension side fail to bridge.
Additionally, this report includes an AUR-specific finding: the generated native host script bypasses the AUR wrapper that sets
DISABLE_AUTOUPDATER=1, causing the native host to crash on startup.AUR packager here - I can't reproduce the issue and I kind of doubt it is related to the AUR packaging or to
DISABLE_AUTOUPDATER.Correction on the auto-updater finding: tested by running
env -u DISABLE_AUTOUPDATER /opt/claude-code/bin/claude --chrome-native-hostdirectly and it starts and listens on the socket with no crash. The env var is unrelated to this issue.Closing as duplicate of #24935.
Issue 1 (DISABLE_AUTOUPDATER) was a red herring — removing the env var from
~/.config/environment.d/had no effect on the connection failure.Issue 2 (extension never connects) is the same cloud bridge / team OAuth token rejection covered in #24935. Posting updated findings there.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.