How to fix Cline Browser Automation in WSL in 2026

• Current docs explicitly describe a WSL setup path instead of marking WSL unsupported.
• The two first-pass fixes are a Windows firewall rule for port 9222 and the Windows Chrome executable path.
• That setup problem is separate from Web Tools provider gating.
• If Browser Automation fails in WSL, fix the browser connection path before you start blaming the provider layer.

If your question is whether Browser Automation still fits an OpenRouter workflow, continue with Does Cline Browser Automation work with OpenRouter? If your missing feature is web_search or web_fetch, read why Cline Web Tools do not work with OpenRouter instead.

• your editor can be running inside Linux
• the usable Chrome app is often installed on Windows
• Browser Automation still depends on Chrome's debugging connection

That is why the docs tell WSL users to expose the Windows Chrome debugging port and point Cline to the Windows Chrome binary instead of assuming a normal local Linux browser path.

Run this in PowerShell as Administrator on Windows:

New-NetFirewallRule -DisplayName "WSL Chrome Debug" -Direction Inbound -LocalPort 9222 -Protocol TCP -Action Allow

This matters because the docs call out port 9222 specifically for the WSL flow. If Windows blocks that inbound connection, Browser Automation can fail before a page ever opens.

• verify the rule exists if you created it earlier
• check whether local security policy replaced it with something stricter
• retry a small browser task after the rule is confirmed

1. Open your editor settings and search for Cline: Chrome Executable Path.
2. Set it to the Windows Chrome executable.
3. Use a full Windows path rather than a Linux path inside WSL.

The docs show this example path:

C:\Program Files\Google\Chrome\Application\chrome.exe

If you point Cline at the wrong side of the Windows-plus-WSL split, Browser Automation can fail even though Chrome is installed and the provider configuration is fine.

• open a simple public page and describe the layout
• check a local app on localhost
• take a screenshot of the loaded page
• open a page and report any console errors

If the simple test works, the core environment issue is probably resolved and any remaining failure is more likely to be task-specific.

Problem type	What it usually means	Where to look first
WSL Browser Automation failure	Chrome connection path or firewall issue	Port 9222, Windows Chrome path, simple browser test
Missing web_search or web_fetch	Provider-boundary issue	Current Web Tools docs and provider choice

Use this rule: if Cline cannot launch or control Chrome in WSL, troubleshoot the WSL setup first. If you are missing text-based Web Tools, that is a separate provider question.

Using the wrong Chrome path

Do not point Cline to a Linux-side browser path if the documented WSL flow depends on Windows Chrome.

Forgetting the firewall rule

If port 9222 is blocked, Browser Automation can fail even when the rest of your setup looks correct.

Treating Browser Automation and Web Tools as one feature

They are documented separately, so fixing one does not automatically fix the other.

Testing with a complex task first

Start with one page load, one screenshot, or one basic interaction so you can isolate the setup issue quickly.

Assuming WSL means the feature is unsupported

The current docs do not say that. They include a WSL-specific configuration section instead.

1. Confirm you are troubleshooting Browser Automation, not missing web_search or web_fetch.
2. Add or verify the Windows firewall rule for TCP port 9222.
3. Set Cline: Chrome Executable Path to the Windows Chrome executable.
4. Retry with a minimal browser task.
5. If the browser opens and completes a simple task, move on to task-specific debugging.

That keeps the troubleshooting path aligned with the highest-confidence fixes the docs actually support.

• For Browser Automation fit on BYOK, read Does Cline Browser Automation work with OpenRouter?
• For missing web_search or web_fetch, read why Cline Web Tools do not work with OpenRouter
• For the broader provider setup path, read How to use Cline with your own model provider

Does Cline Browser Automation support WSL?

The current docs checked on April 19, 2026 support a careful yes. They include a dedicated WSL Configuration section rather than saying Browser Automation is unavailable in WSL.

What port does Cline Browser Automation use in WSL?

The current Browser Automation docs specifically reference port 9222 for the Windows firewall rule used in the WSL setup flow.

What should I set for Cline Chrome Executable Path in WSL?

The docs say to set it to the Windows Chrome executable path, with C:\Program Files\Google\Chrome\Application\chrome.exe shown as the example path.

Why is Browser Automation still failing even though OpenRouter works?

Because provider setup and browser setup are different problems. Your model provider can be configured correctly while the WSL-to-Chrome connection is still broken.

Is this the same issue as missing Web Tools in Cline?

No. Missing web_search or web_fetch is a provider-boundary issue in current Cline docs. A broken Chrome connection in WSL is an environment setup issue.