[FEATURE] Support Claude in Chrome for WSL environments

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)

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

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

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).

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

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

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

``` bash
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)

+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.

+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 :(

@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

Fix for this will go out in the next Claude Code release. Thanks for the report!

Fix for this will go out in the next Claude Code release. Thanks for the report!

This does not look like a real solution. It looks like a hack.
What we actually need is native support for WSL + Windows Chrome for normal, day-to-day development.
Please don’t ignore this problem. There are enough users working in WSL. Thanks for your understanding!

For anyone interested in getting Claude code in WSL to work with Windows native chrome, i created a bridge to get around the restrictions from Claude Code directly.

its a pretty easy install in Windows PowerShell:
Invoke-WebRequest "https://api.github.com/repos/newms87/claude-wsl-chrome-bridge/contents/dist/install.ps1" -Headers @{Accept="application/vnd.github.v3.raw"} -OutFile install.ps1; .\install.ps1

then just run claude-chrome in WSL

The code is all open source and works on my machine. I haven't tested with any other machine so if you want to try it out and let me know how it goes or tell me about any problems, please reach out to me!

https://github.com/newms87/claude-wsl-chrome-bridge

<img width="1701" height="403" alt="Image" src="https://github.com/user-attachments/assets/0fc2c0d6-4c0c-40f7-b060-9c936f6f4c87" />

<img width="607" height="428" alt="Image" src="https://github.com/user-attachments/assets/39493fdb-bd0b-42cd-9426-8a05bd61ec5c" />

!Image

FYI from today's Claude Code 2.1.0 changelog:

Fixed Claude in Chrome support for WSL environments

Not working on 2.1.1

<img width="241" height="132" alt="Image" src="https://github.com/user-attachments/assets/65a70a85-da20-40dd-91bd-674e6a778fe2" />

<img width="1565" height="367" alt="Image" src="https://github.com/user-attachments/assets/d4d4ec64-94c2-4d73-9c8e-c030cd57a040" />

Nope, aaand:

<img width="1217" height="455" alt="Image" src="https://github.com/user-attachments/assets/3eb2d8a1-9317-4bb7-bd75-19a861894701" />

Nope...

Confirming this isn't working and the VS Code Extension doesn't recognize we're in WSL, so doesn't show helpful messages to show it won't work in WSL.

Absolutely not working in Claude Code v2.1.2
I am always getting this brief notification Chrome extension not detected when running claude --chrome.
After that, I am getting this:

<img alt="Image" width="241" height="132" src="https://private-user-images.githubusercontent.com/196689314/533272281-65a70a85-da20-40dd-91bd-674e6a778fe2.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Njc5OTc2NTUsIm5iZiI6MTc2Nzk5NzM1NSwicGF0aCI6Ii8xOTY2ODkzMTQvNTMzMjcyMjgxLTY1YTcwYTg1LWRhMjAtNDBkZC05MWJkLTY3NGU2YTc3OGZlMi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMTA5JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDEwOVQyMjIyMzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kZTEyYWVhYzQ5MDMzYzE3OGZmM2NmMzk0NzAwMjJkYTEwNDRlYTgyZDU5MTBiNDJhNzdmMDVhNzFmODc3YTBkJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.7EN_uFSJg5tJEqLeJeTpqmaq5QE9kpTUIGwazGtkP90">

can also confirm this is not working on v2.1.2

Not even working in v2.1.3

claude --version
2.1.3 (Claude Code)

claude --chrome
❯ /chrome

 Claude in Chrome (Beta)

 Claude in Chrome works with the Chrome extension to let you control your browser directly from Claude Code. Navigate websites, fill forms, capture screenshots, record GIFs, and debug with console logs and network requests.

 Claude in Chrome is not supported in WSL at this time.

 Learn more: https://code.claude.com/docs/en/chrome

Working Solution: WSL → Windows Chrome Bridge (v2.1.3)

Got this working on Claude Code v2.1.3 with WSL2 Ubuntu controlling Windows Chrome. Here's a simple manual fix:

1. Create the bridge files on Windows

Create these files in C:\Users\<USERNAME>\AppData\Local\Google\Chrome\User Data\NativeMessagingHosts\:

com.anthropic.claude_code_browser_extension.bat:

@echo off
wsl.exe -d Ubuntu -- /home/<WSL_USER>/.claude/chrome/chrome-native-host

com.anthropic.claude_code_browser_extension.json:

{
  "name": "com.anthropic.claude_code_browser_extension",
  "description": "Claude Code Browser Extension Native Host",
  "path": "C:\\Users\\<USERNAME>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.bat",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"
  ]
}

2. Add Registry Entry

Create install_registry.reg:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension]
@="C:\\Users\\<USERNAME>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.json"

Double-click to install.

3. Restart Chrome and test

Quit Chrome completely (including system tray), restart it, then run claude --chrome in WSL.

This works because it bridges Chrome's Native Messaging from Windows to the WSL Claude Code native host. No patching required!

Working Solution: WSL → Windows Chrome Bridge (v2.1.3)

@illusive-ch, this is the most elegant and less intrusive solution so far -- definitely something Anthropic should follow. Works exactly as expected.

Tbh thank Claude for helping me come up with it lol.

> Working Solution: WSL → Windows Chrome Bridge (v2.1.3) @illusive-ch, this is the most elegant and less intrusive solution so far -- definitely something Anthropic should follow. Works exactly as expected.

@illusive-ch Best solution thus far. I was not okay running Chrome in WSL wrapper for security concerns. This seems to be a great fix for the time being. Thank you for showcasing this.

## Working Solution: WSL → Windows Chrome Bridge (v2.1.3) Got this working on Claude Code v2.1.3 with WSL2 Ubuntu controlling Windows Chrome. Here's a simple manual fix: ### 1. Create the bridge files on Windows Create these files in C:\Users\<USERNAME>\AppData\Local\Google\Chrome\User Data\NativeMessagingHosts\: com.anthropic.claude_code_browser_extension.bat: @echo off wsl.exe -d Ubuntu -- /home/<WSL_USER>/.claude/chrome/chrome-native-host com.anthropic.claude_code_browser_extension.json: { "name": "com.anthropic.claude_code_browser_extension", "description": "Claude Code Browser Extension Native Host", "path": "C:\\Users\\<USERNAME>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.bat", "type": "stdio", "allowed_origins": [ "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/" ] } ### 2. Add Registry Entry Create install_registry.reg: `` Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension] @="C:\\Users\\<USERNAME>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.json" ` Double-click to install. ### 3. Restart Chrome and test Quit Chrome completely (including system tray), restart it, then run claude --chrome` in WSL. This works because it bridges Chrome's Native Messaging from Windows to the WSL Claude Code native host. No patching required!

<img width="1573" height="232" alt="Image" src="https://github.com/user-attachments/assets/ed13c655-f725-4bcc-a375-ecd0a0e7b1a7" />

Not getting the unsupported error, but any way to troubleshoot or debug this?

Not getting the unsupported error, but any way to troubleshoot or debug this?

I can confirm getting the same error as you. also /chrome keeps showing not detected. Seems like its the chrome part not working as if i launch manually the .bat i get this

<img width="1145" height="173" alt="Image" src="https://github.com/user-attachments/assets/2c8917f4-d405-404f-8a55-49af52d4dfc6" />

Notice the mcp connected appears AFTER i launch claude with --chrome.

I can confirm that after rebooting pc and starting WSL and after that chrome, the socket file in /tmp gets created but 2.1.5 still shows as unrecognized.

Edit: I tried 2.1.3 as well since the original guide was meant for that version. Still Extension: not detected

For those landing here. and having the issue depicted in my previous message, create a symlink from wsl to windows as it seems that claude is checking for file existance (and possibly other things like versions and such)

So:

ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn" ~/.config/google-chrome/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn

After doing so, you should be able to connect to chrome.

For those landing here. and having the issue depicted in my previous message, create a symlink from wsl to windows as it seems that claude is checking for file existance (and possibly other things like versions and such) So: ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn" ~/.config/google-chrome/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn After doing so, you should be able to connect to chrome.

Thanks, this solved the problem, now the chrome estension is working with wsl

For those landing here. and having the issue depicted in my previous message, create a symlink from wsl to windows as it seems that claude is checking for file existance (and possibly other things like versions and such) So: ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn" ~/.config/google-chrome/Default/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn After doing so, you should be able to connect to chrome.

It solved my problem too. Thanks!

These workarounds are helpful but is this the long term plan? WSL users who want to use this feature have to hope to find this thread? I am thinking it's better to be patient and wait for this feature to be actually completed. I suggest the team re-opens this issue until it can operate without manual symlinks and registry key edits. All love to the team but I think this one needs a bit more work.

I got a ln: failed to create symbolic link.
I just did the ln -s ... stuff, you need something before? 🙏

For anyone coming here from searching here is a prompt claude made after I set this up locally based on giving it this url and fixing the various issues.

Claude Code Chrome Integration from WSL
=======================================

This guide explains how to set up Claude Code running in WSL (Windows Subsystem
for Linux) to control Chrome on Windows.

PROBLEM
-------
By default, Claude Code in WSL cannot use the "Claude in Chrome" feature and
fails with:

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

This happens because the platform detection explicitly blocks WSL from using
Chrome integration.

SOLUTION
--------
Create a bridge that forwards Chrome's Native Messaging from Windows to the
WSL Claude Code native host.

PREREQUISITES
-------------
- Windows 10/11 with WSL2
- Google Chrome installed on Windows
- Claude Code installed in WSL (via npm)
- Claude browser extension installed in Chrome (from https://claude.ai/chrome)

SETUP INSTRUCTIONS
==================

Step 1: Gather Information
--------------------------
First, get your Windows username and WSL distro name.

Windows username - Open PowerShell or Command Prompt and run:

    echo %USERNAME%

WSL distro name - From WSL terminal, run:

    cmd.exe /c "wsl.exe -l -q" 2>&1 | tr -d '\r' | tr -d '\0'

Common distro names include Ubuntu, Ubuntu-22.04, Ubuntu-24.04, etc.

*** IMPORTANT ***
The distro name must match exactly. "Ubuntu" and "Ubuntu-24.04" are different
distros. Using the wrong name will cause silent failures.

WSL username - From WSL terminal, run:

    whoami

Step 2: Verify the Native Host Exists
-------------------------------------
Confirm the Claude Code native host script exists:

    ls -la ~/.claude/chrome/chrome-native-host

You should see the file. If it doesn't exist, run "claude --chrome" once to
generate it, then exit.

Step 3: Create the NativeMessagingHosts Directory
-------------------------------------------------
Create the directory where Chrome looks for native messaging configurations:

    mkdir -p "/mnt/c/Users/<WINDOWS_USER>/AppData/Local/Google/Chrome/User Data/NativeMessagingHosts"

Replace <WINDOWS_USER> with your Windows username.

Step 4: Create the Batch File Bridge
------------------------------------
Create a batch file that bridges Windows Chrome to WSL.

File location:
    C:\Users\<WINDOWS_USER>\AppData\Local\Google\Chrome\User Data\NativeMessagingHosts\com.anthropic.claude_code_browser_extension.bat

Contents:

    @echo off
    wsl.exe -d <WSL_DISTRO> -- /home/<WSL_USER>/.claude/chrome/chrome-native-host

Replace:
- <WSL_DISTRO> with your WSL distro name (e.g., Ubuntu-24.04)
- <WSL_USER> with your WSL username

*** CRITICAL ***
The distro name must match exactly what "wsl -l -q" shows. This was the main
issue encountered during setup.

Step 5: Create the JSON Configuration
-------------------------------------
Create the native messaging host manifest.

File location:
    C:\Users\<WINDOWS_USER>\AppData\Local\Google\Chrome\User Data\NativeMessagingHosts\com.anthropic.claude_code_browser_extension.json

Contents:

    {
      "name": "com.anthropic.claude_code_browser_extension",
      "description": "Claude Code Browser Extension Native Host",
      "path": "C:\\Users\\<WINDOWS_USER>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.bat",
      "type": "stdio",
      "allowed_origins": [
        "chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/"
      ]
    }

Replace <WINDOWS_USER> with your Windows username. Note the double backslashes
(\\) in the path.

Step 6: Add the Registry Entry
------------------------------
Chrome needs a registry entry to find the native messaging host.

Option A: Create a .reg file (Recommended)

Create a file named "claude-chrome-wsl.reg" with:

    Windows Registry Editor Version 5.00

    [HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension]
    @="C:\\Users\\<WINDOWS_USER>\\AppData\\Local\\Google\\Chrome\\User Data\\NativeMessagingHosts\\com.anthropic.claude_code_browser_extension.json"

Replace <WINDOWS_USER> with your Windows username. Double-click the file to
import it.

Option B: Create via batch file

If the .reg file doesn't work, create a batch file named "add-registry.bat":

    @echo off
    reg add "HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension" /ve /t REG_SZ /d "C:\Users\<WINDOWS_USER>\AppData\Local\Google\Chrome\User Data\NativeMessagingHosts\com.anthropic.claude_code_browser_extension.json" /f
    pause

Replace <WINDOWS_USER> and double-click to run.

Step 7: Verify the Registry Entry
---------------------------------
*** STRONGLY RECOMMENDED ***

Verify the registry key manually using Registry Editor (regedit.exe).
Command-line verification from WSL often fails due to escaping issues, even
when the key exists.

1. Press Win + R, type "regedit", press Enter
2. Navigate to:
   HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
3. Verify the (Default) value contains the full path to your JSON file

If the key doesn't exist, create it manually:
1. Navigate to HKEY_CURRENT_USER\Software\Google\Chrome
2. Right-click -> New -> Key -> name it "NativeMessagingHosts"
3. Right-click on NativeMessagingHosts -> New -> Key -> name it
   "com.anthropic.claude_code_browser_extension"
4. Double-click (Default) and set the value to your JSON file path

Step 8: Restart Chrome and Test
-------------------------------
1. Close all Chrome windows
2. Open Task Manager and end any remaining Chrome processes
3. Reopen Chrome
4. From WSL, run:

    claude --chrome

TROUBLESHOOTING
===============

"Browser extension is not connected"
------------------------------------
1. Verify the Claude extension is installed and enabled
   - Go to chrome://extensions
   - Ensure the Claude extension is present and enabled

2. Verify the registry key exists
   - Open Registry Editor (regedit.exe)
   - Navigate to:
     HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_code_browser_extension
   - The (Default) value should point to your JSON file

3. Verify the WSL distro name is correct
   - This is the most common issue
   - Run "wsl -l -q" from Command Prompt to get the exact name
   - Update the batch file with the exact name (case-sensitive)

4. Test WSL invocation from Windows
   - Open Command Prompt
   - Run: wsl.exe -d <YOUR_DISTRO> -- echo test
   - Should print "test". If you get "no distribution with the supplied name",
     the distro name is wrong

5. Verify file paths exist
   - Check that ~/.claude/chrome/chrome-native-host exists in WSL
   - Check that the batch and JSON files exist in NativeMessagingHosts folder

Connection works once then drops
--------------------------------
This can happen if there are timing issues. Usually reconnecting works. If it
persists, try restarting Chrome completely.

Registry commands fail from WSL
-------------------------------
Command-line registry operations from WSL often fail due to path escaping
issues. This doesn't mean the registry key doesn't exist. Always verify using
Registry Editor (regedit.exe) directly.

HOW IT WORKS
============
1. Chrome extension tries to communicate with a native messaging host
2. Chrome looks up the registry to find the host configuration
3. The JSON config points to the batch file
4. The batch file runs wsl.exe which calls the Claude Code native host in WSL
5. The native host communicates with Claude Code running in WSL
6. Messages flow back through the same path

REFERENCES
==========
- Original GitHub issue:
  https://github.com/anthropics/claude-code/issues/14367
- Solution comment:
  https://github.com/anthropics/claude-code/issues/14367#issuecomment-3733049468

Is there any point in using WSL when Claude Code is now natively supported by Windows and Chrome support works?

because claude in windows is not nearly as good or works as well as claude in WSL. gitbash is a poor substitute for full wsl.

What about having it use Microsoft Edge instead of Chrome?
I attempted to get that to work with Claude in Chrome extension on MS Edge but Claude in WSL still had some issues accessing the tabs.

Is there any point in using WSL when Claude Code is now natively supported by Windows and Chrome support works?

@psykokwak-com The models are heavily trained on bash/Zsh commands and linux/mac environments, the quality of the code output is much higher in WSL compared to using a terminal like the command prompt or powershell. Tools tend to be much better at reading and reacting to bash terminal output too.

as mentioned, training data is very important.

but also you use wsl

• because you want an environment that matches your production.
• because the filesystem behaves faster on linux based systems
• because most of the dev tools are written for linux (bash etc...)
• because mac is too expensive for some companies : )

I got a ln: failed to create symbolic link. I just did the ln -s ... stuff, you need something before? 🙏

@jycouet You need to first create the parent directory, so do something like this:

mkdir -p ~/.config/google-chrome/Default/Extensions/

Even with doing that I was running into issues with "Chrome extension not detected"..... The problem was I didn't have the Claude in Chrome extension in my Default Chrome account. I ended up adding it there, just in case, so not sure if that fixed it or just updating the symlink. I did both, by doing these two things:

mkdir -p ~/.config/google-chrome/"Profile 1"/Extensions/

ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Profile 1/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn" ~/.config/google-chrome/Profile 1/Extensions/fcoeoabgfenejglbffodgkkbkcdhcgfn

This ticket should be re-opened. A workaround in the comments section on a github issue is not a valid fix for a paid product.

Previous workaround was working until couple days ago. Now I get the message "Claude in Chrome is not supported in WSL at this time"

<img width="1203" height="436" alt="Image" src="https://github.com/user-attachments/assets/6ad185ec-bc89-4845-ade1-d7a5b117f641" />

I actually found a really simple way to make it work : Just install the Google Chrome (GUI) package on WSL Ubuntu and then you have access to Claude plugin inside. It will still do "Claude in Chrome is not supported in WSL as this time" but if you just ask "Please open google-chrome and use claude plugin, i installed everything" it just works 💯

<img width="1920" height="1032" alt="Image" src="https://github.com/user-attachments/assets/dac3ffbe-ef4e-434d-8af2-9dcb80a7e352" />
<img width="1920" height="1080" alt="Image" src="https://github.com/user-attachments/assets/b24f471b-bf1e-4ca0-ae7d-8b7d82ac897f" />
I just asked claude to make what @MattLoyeD said :D

Broke for me too. Turned out the registry key went missing somehow. Restored that, restarted chrome, and it's working again.

I noticed some strange behavior: on another machine, the Claude extension is running in Chrome with the same account. In WSL it says it can’t connect, but when I ask it to open a given URL, it opens the page in Chrome on the other machine, while on my own machine it doesn’t open it at all. I didn’t even know that a Chrome extension could work across the network—this raises a few security questions…

@kubanka-peter I don't work for anthropic and I don't have source code access but I have looked into this in a cursory fashion since you raised a security question, and I found it interesting.

I had claude look into this and at least on my machine ( Linux version 6.6.87.2-microsoft-standard-WSL2 (root@439a258ad544) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025)

1. No network listeners - ss -tlnp shows only expected local daemons
2. The transport is stdio - no network traversal is possible in my local config (look into ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json if you want to double check)
3. On my install the host is just a shell shim — /home/jw/.claude/chrome/chrome-native-host is a 4-line script that execs the Claude Code binary with --chrome-native-host. It opens no ports, creates no sockets.
4. On my install no process runs when it's not running (verified with ps -aux)
5. No unix domain sockets either - ss -xlnp showed nothing besides PulseAudio for WSLg (not part of claude/chrome)

My opinion based on this is that there is no network surface for cross machine communication - the protocol implementation, absent some kind of proxy, is that this isn't possible. I suggest asking claude about stdio and its potential network vulnerabilities if you want to know more.

One thing that has happened to me is that chrome synchronizes tabs across machines, and it's possible that what you are seeing is that claude/chrome was active on your local machine, that tab got synchronized to the other machine, and you're seeing the result of the claude interaction there... but that's the synchronized browser state. I'm trying to find a way to explain it, claude can type and like use your mouse in browser automation mode - the synchronized state on the other machine is what it did, but claude is no longer connected and cannot type, read, or retrieve information.

Another way to put it is if you have your browser set to open to google calendar on machine a, and put in an appointment, and machine b you log in with chrome, and it opens the same tab, you'll see the same appointment on machine b. But machine A is not connected to machine B, machine a and B are connected to google calendar.

Do you have any kind of special network kvm going on (synchronicity? etc?) Anything that's emulating keyboard/mouse on your source to the target machine could be doing something, but it would be outside this channel.

This is only my personal speculation based on available data so take it with a grain of salt.

The exact situation was the following: the other machine belongs to my colleague; there is approximately 1,200 km between us. We are logged into Chrome with different Google accounts, so synchronization can be ruled out.

We were logged into Claude Code and the browser extension with the same Claude account. I don’t know whether Claude Code was running on his machine as well; we has a Max+ plan.

I asked Claude Code to open a page. It said the page was opened, and sometimes it claimed to have access to the content, sometimes not. On my side, I didn’t see anything open in Chrome. I didn’t understand what was happening, so I started debugging and tried several different pages.

Later, while talking with my colleague about a different topic, this came up. I mentioned the URLs I had been testing, and that’s when we realized those pages had actually opened on his machine. He suspected a virus and was about to reinstall his system. We tested it again, and whatever I asked Claude Code to open was opened on his machine.

On my machine, Claude Code is running inside WSL using the symlink-based setup. It did not report that Chrome was unavailable under WSL, and even the /chrome command indicated that everything was fine. The day before, everything had worked correctly. This occurred with version 2.1.38. I’m not sure about the extension version.

It’s possible that Claude Code was also running on his machine and was controlling the browser through that instance.

@kubanka-peter - get in touch if you want to collaborate on a potential report, I think only Anthropic can answer this one. I'm unable to reproduce using WSL2 & Windows as my "two machines" but there's more best discussed elsewhere

For anyone who tried the local WSL bridge solution by @illusive-ch and it stopped working for no obvious reasons: ensure you don't have Claude Desktop app installed.

Root cause: Chrome extension tries to connect to native messaging hosts in this order:

1. com.anthropic.claude_browser_extension (Claude Desktop)
2. com.anthropic.claude_code_browser_extension (Claude Code)

If Claude Desktop is installed, it registers its own native host, wins the race, and the WSL bridge is never reached. To fix this, remove the Desktop native host registry entry and restart Chrome:

reg delete "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension" /f (from Windows terminal)

Note: Claude Desktop may re-register the entry on launch or update. If the connection breaks again, check for the registry key.

If you're still having trouble getting it to work, you might find this note helpful:

https://sderev.com/notes/198/

Claude Code running on WSL can control Chrome without any hassle with that configuration.

If you're still having trouble getting it to work, you might find this note helpful: https://sderev.com/notes/198/ Claude Code running on WSL can control Chrome without any hassle with that configuration.

as a heavy user of chrome devtools, the experience is not the same. does work in a pinch though.

I gave Claude the honor of writing the following comment, he wrote it from WSL2 by typing into Chrome input field via claude --chrome (I already had it set up and working with Claude Code installed in Windows, he patched that up to work from WSL2):

---

Got claude --chrome working from WSL2 (Windows 10, no WSLg) connecting to Windows Chrome. Here's what it took:

1. Bridge the native host to WSL

Edit %USERPROFILE%\.claude\chrome\chrome-native-host.bat to call into WSL instead of the Windows binary:

@echo off
REM Chrome native host wrapper script - modified to bridge to WSL
wsl.exe -d Ubuntu-22.04 -- /home/<user>/.local/bin/claude --chrome-native-host

REM Original:
REM "C:\Users\<user>\.local\bin\claude.exe" --chrome-native-host

(Replace Ubuntu-22.04 and paths with your actual distro/user.)

2. Fix extension detection

The detection code in claude --chrome uses readdir with withFileTypes: true and filters on .isDirectory(). On WSL, it checks ~/.config/google-chrome/ for Chrome profiles with the extension installed. Since Chrome is on Windows, we need to make the Windows Chrome data visible at the Linux path.

A simple symlink to the Windows Chrome Default folder won't work because Node's readdir({withFileTypes: true}) returns isDirectory: false for cross-filesystem symlinks — it sees them as symlinks, not directories.

The fix is to create a real directory with a symlink to Extensions inside:

mkdir -p ~/.config/google-chrome/Default
ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Default/Extensions" \
      ~/.config/google-chrome/Default/Extensions

3. Native messaging host manifest (should already exist)

claude --chrome writes this automatically to ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json, but verify it exists and points to ~/.claude/chrome/chrome-native-host.

Result

After these steps, claude --chrome detects the extension and connects to Windows Chrome. The MCP tools (navigate, click, screenshot, etc.) work.

Root causes

1. The .bat native host points to claude.exe (Windows binary) but needs to call into WSL when Claude Code runs there
2. readdir({withFileTypes: true}) treats cross-filesystem symlinks as non-directories, so the extension detection fails silently

---

Made it into a script as well: https://gist.github.com/bgr/31a25707f026abd34b2deb587ee74466

reg delete "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension" /f

this worked thanks!

I gave Claude the honor of writing the following comment, he wrote it from WSL2 by typing into Chrome input field via claude --chrome (I already had it set up and working with Claude Code installed in Windows, he patched that up to work from WSL2): Got claude --chrome working from WSL2 (Windows 10, no WSLg) connecting to Windows Chrome. Here's what it took: ### 1. Bridge the native host to WSL Edit %USERPROFILE%\.claude\chrome\chrome-native-host.bat to call into WSL instead of the Windows binary: @echo off REM Chrome native host wrapper script - modified to bridge to WSL wsl.exe -d Ubuntu-22.04 -- /home/<user>/.local/bin/claude --chrome-native-host REM Original: REM "C:\Users\<user>\.local\bin\claude.exe" --chrome-native-host (Replace Ubuntu-22.04 and paths with your actual distro/user.) ### 2. Fix extension detection The detection code in claude --chrome uses readdir with withFileTypes: true and filters on .isDirectory(). On WSL, it checks ~/.config/google-chrome/ for Chrome profiles with the extension installed. Since Chrome is on Windows, we need to make the Windows Chrome data visible at the Linux path. A simple symlink to the Windows Chrome Default folder won't work because Node's readdir({withFileTypes: true}) returns isDirectory: false for cross-filesystem symlinks — it sees them as symlinks, not directories. The fix is to create a real directory with a symlink to Extensions inside: mkdir -p ~/.config/google-chrome/Default ln -s "/mnt/c/Users/<user>/AppData/Local/Google/Chrome/User Data/Default/Extensions" \ ~/.config/google-chrome/Default/Extensions ### 3. Native messaging host manifest (should already exist) claude --chrome writes this automatically to ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json, but verify it exists and points to ~/.claude/chrome/chrome-native-host. ### Result After these steps, claude --chrome detects the extension and connects to Windows Chrome. The MCP tools (navigate, click, screenshot, etc.) work. ### Root causes 1. The .bat native host points to claude.exe (Windows binary) but needs to call into WSL when Claude Code runs there 2. readdir({withFileTypes: true}) treats cross-filesystem symlinks as non-directories, so the extension detection fails silently Made it into a script as well: https://gist.github.com/bgr/31a25707f026abd34b2deb587ee74466

I followed your steps. But I still can't make it work.

I followed your steps. But I still can't make it work.

Try running the script from the gist link at the end of the message.

> I followed your steps. But I still can't make it work. Try running the script from the gist link at the end of the message.

Did that with 2.1.50, will try on the new version. Do you have the Claude in the Windows (not inside WSL) as well?

Also, I feel like this should not be a closed issue since technically we still have to do some workarounds. Otherwise, the CLI will just display "WSL is still not supported"

EDIT: I managed to make it work by having to fork this script to flip the tengu_copper_bridge. I didn't apply the others as it is not needed.

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.