[FEATURE] Support Claude in Chrome on WSL (native Linux Chrome via WSLg works today)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's Chrome integration (claude --chrome) is currently blocked on WSL. The /chrome UI hard-blocks WSL environments, so users get a "not supported in WSL" message or a "Claude in Chrome is not connected" error. This forces WSL users to either switch to a Windows-native workflow or give up on browser automation from the CLI.

The root cause is that Claude Code and Chrome communicate over Chrome's native-messaging protocol, and a Linux process inside WSL cannot reach the native-messaging host launched by a Windows Chrome, since they sit on opposite sides of the OS boundary.

Proposed Solution

Officially support the Chrome integration on WSL. This already works today when Chrome runs as a native Linux GUI app via WSLg: because Claude Code, the Claude in Chrome extension, and the native-messaging host are all Linux-side, native messaging becomes ordinary local process-to-process communication.

The main change needed is to drop the isWSL hard-block in the /chrome gate (keeping the subscription gating) and treat "WSL + native Linux Chrome" as a first-class supported path, rather than requiring the CLAUDE_CODE_ENABLE_CFC=1 environment variable as a bypass.

Alternative Solutions

Working workaround I'm currently using, documented here: https://github.com/vrfox/claude-code-wsl-native-chrome

In short: install Chrome-for-Linux inside WSL (per the Microsoft WSLg tutorial), install the Claude in Chrome extension in that Linux Chrome and sign in there, then run:

export CLAUDE_CODE_ENABLE_CFC=1
claude --chrome

Verified working end-to-end. The other known approach is a Windows-Chrome native-messaging bridge (see related issue #41625), which is significantly more complex to set up.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Example scenario:

1. I develop entirely inside WSL (Ubuntu) with Claude Code as my CLI.
2. 2. I want Claude to test and verify a web app I'm building by driving a real browser.
3. 3. I install Google Chrome as a native Linux app via WSLg, add the Claude in Chrome extension there, and sign in.
4. 4. I run export CLAUDE_CODE_ENABLE_CFC=1 && claude --chrome, and Claude Code connects to the extension and drives the Linux Chrome successfully.

This works today with the env-var bypass; making it a supported, documented path would remove the friction for WSL users. Full write-up: https://github.com/vrfox/claude-code-wsl-native-chrome

Additional Context

_No response_