[FEATURE] Support Claude in Chrome for WSL environments

[shostako]

Problem Statement

When running Claude Code in WSL (Windows Subsystem for Linux), the "Claude in Chrome" feature fails with the error:

Error: Claude in Chrome Native Host not supported on this platform

WSL is a popular development environment, especially for web developers who use Linux tooling but work on Windows machines. Currently, WSL users cannot use the Claude in Chrome feature to control their Windows Chrome browser, forcing them to either:

• Switch to Windows-native Claude Code for browser automation tasks
• Use separate MCP servers (Playwright/Puppeteer) which launch isolated browser instances without user session data

Proposed Solution

Add support for WSL environments to connect to Windows Chrome via Native Host. This could be achieved by:

1. WSL-Windows Bridge: Create a Windows-side relay process that WSL Claude Code can communicate with
2. WebSocket Alternative: Use WebSocket connection instead of Native Messaging when running in WSL
3. Cross-platform Detection: Detect when running in WSL and automatically use the appropriate connection method

Alternative Solutions

Current workarounds:

• Use Claude Code from Windows PowerShell/cmd.exe (works but loses WSL dev environment)
• Use Playwright/Puppeteer MCP servers (works but creates isolated browser without user session)

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. Developer works in WSL with their preferred Linux tooling (vim, bash, etc.)
2. They want to automate testing on their actual Chrome browser with logged-in state
3. With this feature, they could use Claude in Chrome directly from WSL
4. This would allow seamless browser automation while staying in the WSL environment

Additional Context

• Tested on Claude Code v2.0.71
• Windows 11 with WSL2 (Ubuntu)
• Chrome extension is installed and working on Windows side
• claude --chrome works correctly when run from Windows PowerShell

[orenmizr]

i use claude via ubuntu linux. everything dev is in linux but the terminal (windows terminal with ubuntu bash). ubuntu has it own chrome that can run in windows, i thought the chrome linux would work.

workarounds anyone ? (still using playwright mcp)

[stubborncoder]

After installing and failling to this, I cannot run again claude in WSL, I have only the option to remove the extension??

[orenmizr]

run claude with --no-chrome option and disable it. until it is fixed.

[pavelbe]

I can confirm this is a major pain point for Windows+WSL developers.

Setup:

• Windows 11 + WSL2 (Ubuntu)
• Claude Code CLI 2.0.75 (npm-global)
• Chrome on Windows (primary browser)

Problem: Claude in Chrome cannot be used from WSL. When Chrome integration is enabled, Claude Code fails with: Error: Claude in Chrome Native Host not supported on this platform

Workaround: --no-chrome works, but then the official Chrome integration is unavailable. DevTools/Playwright MCP is not equivalent because it often runs an isolated browser without my real Chrome profile/session.

Request: Please add an official WSL bridge so WSL CLI can control Windows Chrome with the real user session (e.g., Windows-side relay / WebSocket bridge / WSL detection + supported transport).

[jw409]

Technical Analysis: The Simplest Fix

I investigated this and found the block is overly conservative. Here's why WSL should work with minimal changes.

Root Cause

The platform detection explicitly returns null for WSL:

case"wsl":default:return null

This prevents all Chrome integration, even though WSL can run Chrome natively.

The Simple Solution: Treat WSL as Linux

WSL2 with WSLg can run Chrome as a Linux application. When Chrome runs inside WSL, the existing Linux native messaging code path works - no cross-boundary complexity needed.

The fix would be:

// Change from:
case"wsl":default:return null

// To (fall through to Linux):
case"wsl":
case"linux":return x$(Q,".config","google-chrome","NativeMessagingHosts")

This allows users who have Chrome installed in WSL (via apt install google-chrome-stable or similar) to use Claude in Chrome immediately. The native messaging manifest gets written to ~/.config/google-chrome/NativeMessagingHosts/, Chrome picks it up, and everything works exactly like native Linux.

Why This Makes Sense

Playwright already works in WSL - it spawns a Linux Chrome instance via WSLg/X11 and controls it. There's no reason native messaging shouldn't work the same way.

The current check seems to assume "WSL user = Windows Chrome user", but many WSL developers run Linux Chrome for consistency with their dev environment.

Recommendation

Treat WSL as Linux for native messaging paths. Users with Linux Chrome in WSL get support immediately with a one-line, low-risk change that uses the existing tested Linux code path.

(Connecting to Windows Chrome from WSL is a separate, more complex feature that would require a bridge - but that's a different ask than this.)

---

Tested on Claude Code 2.0.76, Windows 11, WSL2 Ubuntu 24.04

[davidlbangs]

It seems like Anthropic has a profound lack of respect for WSL users, which probably accounts for a large share of their users. The page announcing the feature does not even mention that they did not implement this for people with Windows computers and WSL. The error message is ridiculous - as if they did not even bother testing this and providing a proper error message.

davidlbangs@MSI:~/dev/rcv123-exp$ claude --chrome This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason: Error: Claude in Chrome Native Host not supported on this platform at re2 (file:///home/davidlbangs/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2694:1487) at file:///home/davidlbangs/.nvm/versions/node/v22.14.0/lib/node_modules/@anthropic-ai/claude-code/cli.js:2694:937