[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

[andrewleech]

@jw409 Thanks for your suggestions - claude helped me write a quick wrapper script to patch this in at runtime:

cat > ~/.local/bin/claudec << 'EOF'
#!/bin/bash

CLI_PATH="$HOME/.nvm/versions/node/v22.19.0/lib/node_modules/@anthropic-ai/claude-code/cli.js"
PATCHED_DIR="$HOME/.local/share/claude-code-wsl"
PATCHED_CLI="$PATCHED_DIR/cli.js"

# Create directory if it doesn't exist
mkdir -p "$PATCHED_DIR"

# Check if we need to regenerate the patched file
if [ ! -f "$PATCHED_CLI" ] || [ "$CLI_PATH" -nt "$PATCHED_CLI" ]; then
    # Apply the patch and write to persistent location
    sed 's/case"linux":return/case"wsl":case"linux":return/' "$CLI_PATH" > "$PATCHED_CLI"
fi

# Execute the patched code
exec node "$PATCHED_CLI" "$@"
EOF

chmod +x ~/.local/bin/claudec

Can confirm that with chrome installed in WSL and the claude extension installed this does make it work in by running claudec --chrome !
I had to restart chrome after using this the first time to make the connection actually work, but after that it seems to be working well thanks.

Note:

$ claudec --version
2.0.76 (Claude Code)

[alexlvcom]

+1. Majority of developers on Windows use WSL. The support must be native! Right now Claude + Chrome integration is useless! We develop in WSL, our Claude code is in WSL, and our Chrome is in Windows. I want to instruct Claude to check implemented changes in Chrome, and this is not possible.

[coppinger]

+1

Please make this happen, not being able to use the Claude Chrome extension with Claude Code in WSL is a major hamstring for those of us in sorta-kinda-Linux land :(

[coppinger]

@jw409 Thanks for your suggestions - claude helped me write a quick wrapper script to patch this in at runtime:

cat > ~/.local/bin/claudec << 'EOF'
#!/bin/bash

CLI_PATH="$HOME/.nvm/versions/node/v22.19.0/lib/node_modules/@anthropic-ai/claude-code/cli.js"
PATCHED_DIR="$HOME/.local/share/claude-code-wsl"
PATCHED_CLI="$PATCHED_DIR/cli.js"

Create directory if it doesn't exist

mkdir -p "$PATCHED_DIR"

Check if we need to regenerate the patched file

if [ ! -f "$PATCHED_CLI" ] || [ "$CLI_PATH" -nt "$PATCHED_CLI" ]; then
# Apply the patch and write to persistent location
sed 's/case"linux":return/case"wsl":case"linux":return/' "$CLI_PATH" > "$PATCHED_CLI"
fi

Execute the patched code

exec node "$PATCHED_CLI" "$@"
EOF

chmod +x ~/.local/bin/claudec
Can confirm that with chrome installed in WSL and the claude extension installed this does make it work in by running claudec --chrome ! I had to restart chrome after using this the first time to make the connection actually work, but after that it seems to be working well thanks.

Note:

$ claudec --version
2.0.76 (Claude Code)

This worked! Can't thank you enough @andrewleech

For anyone else trying to achieve the same thing, note, Claude pointed out I was running a newer version of node (v22.20.0), which I had to update, but otherwise it worked exactly as Andrew shared

Edit: I took the long way by having a conversation with Claude to arrive at why and how Andrew's suggestion worked, so here's a link to that conversation incase it's useful for any other noobies like me who need a bit of hand holding https://claude.ai/share/8b7555ee-eaf3-4f34-8592-58899b0e4c2f