[BUG] /chrome command reports "Extension not detected" on WSL despite working MCP connection

Resolved 💬 3 comments Opened Feb 7, 2026 by scuttlecrab-es Closed Feb 11, 2026

What's Wrong?

The /chrome slash command incorrectly reports the Chrome extension as "Not detected" when running Claude Code in WSL2, even though the MCP bridge connection is fully functional.

The detection logic checks for the native messaging host config file at the Linux path:

~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json

This file doesn't exist in WSL because Chrome runs on the Windows host. The MCP WebSocket bridge works cross-environment, but the file-based detection doesn't account for this.

What Should Happen?

/chrome should report the extension as connected when the MCP bridge is functional. On WSL, the detection should either:

  1. Fall back to testing the actual MCP bridge connection (e.g., calling tabs_context_mcp)
  2. Check the Windows-side path via /mnt/c/Users/<user>/AppData/Local/Google/Chrome/NativeMessagingHosts/

Steps to Reproduce

  1. Install Claude Code in WSL2
  2. Install the Claude in Chrome extension in Chrome on the Windows host
  3. Run /chrome in Claude Code — status shows "Not detected"
  4. Call mcp__claude-in-chrome__tabs_context_mcp directly — connects successfully and returns tab data, proving the connection works

Error Messages/Logs

No error or stack trace — /chrome simply reports the extension as not detected. The MCP tools work fine when called directly.

Is this a regression?

Not a regression — this appears to have never worked correctly on WSL, despite the v2.1.0 changelog stating "Fixed Claude in Chrome support for WSL environments."

Additional Information

  • The CHANGELOG.md for v2.1.0 states: "Fixed Claude in Chrome support for WSL environments" — but the /chrome status check was not updated to reflect this
  • docs/en/chrome.md still states "WSL (Windows Subsystem for Linux) is also not supported" which contradicts the changelog fix — see #2804
  • The root cause is that /chrome relies on checking a local file path for the native messaging host config, which only exists on the Windows side in a WSL setup

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗