Unable to launch chrome and use browser actions with VS code in remote wsl mode

Cline Surface

VSCode Extension

Cline Version

v4.0.12

Beta version

• I am using a beta version of Cline

What happened?

Trying to use the built in browser testing with a Windows side Chrome but in remote WSL VS code dev mode. Spent ages with no joy - used cline and Deep seek pro v4 pro to debug (luckily is cheep as chips in your provider). I expect to have cline detect run time errors with its edits and also run manual testing with cline seeing the errors. FYI using WSL mainly as sandbox for safety.

Here's what we got (3 related issues):

browser_action not available — remote webtools flag defaults to false, Chrome launch fails on WSL

Repo: https://github.com/cline/cline

Summary

The browser_action tool never appears in Cline's available tool list, even with "Disable Browser Tool Use" unchecked. After source-diving the extension code (saoudrizwan.claude-dev-4.0.12/dist/extension.js) and testing, I've identified three issues.

Issue 1: Remote feature flag webtools defaults to false (root cause)

browser_action is gated by three conditions combined with AND:

// In the task context construction (~line 7541):
clineWebToolsEnabled: this.stateManager.getGlobalSettingsKey("clineWebToolsEnabled") 
                     && Gp.getWebtoolsEnabled()

Gp.getWebtoolsEnabled() checks a remote feature flags cache:

getBooleanFlagEnabled("webtools") {
    return this.cache.get("webtools") === !0
}

The default fallback flag map (jqt) hardcodes:

jqt = {
  webtools: !1,              // defaults to FALSE
  "worktree-exp": !1,
  onboarding_models: ...,
  "remote-banners": ...,
  ...
}

Even when the user correctly unchecks "Disable Browser Tool Use" in the Browser Settings UI, the feature stays disabled unless Cline's remote config server explicitly returns webtools: true for that installation.

There is zero UI indication that a remote flag is silently blocking the feature.

Issue 2: "Launch Chrome" button fails on WSL (incorrect path translation)

Running Cline via VS Code Remote on WSL2 (Ubuntu). Chrome is running on the Windows side:

chrome.exe --remote-debugging-port=9222 --user-data-dir=C:\temp\chrome-debug-profile

The "Launch Chrome" button in Cline's Browser Settings page fails — likely because it tries to spawn Chrome from the Linux/WSL side using a Windows-style path (C:\...) without translating it via /init or wslpath. Actually chrome throws up an error about cannot read/write the profile '/temp/chrome-debug-profile' - ie either missing the ./mnt/c' prefix or incorrectly a posix path

Issue 3: Browser settings don't seem to write through or apply

After configuring the --profile path in the browser settings , they did not appear to take effect. This may be caused by the webtools remote flag short-circuiting before the settings are even evaluated. also is confusing they are below the launch chrome button.

Expected behavior

1. webtools flag should default to true, or the UI should clearly explain why browser is unavailable
2. Chrome launch from WSL should use proper path translation (/init /mnt/c/Program Files/...)
3. Browser Settings UI should work and be respected regardless of remote flags, or be greyed out with an explanation

Environment

• Cline version: 4.0.12
• Platform: WSL2 (Ubuntu) via VS Code Remote Server
• Chrome: Windows Chrome 150 running with --remote-debugging-port=9222
• Provider: Cline (standard)

Steps to reproduce

1. unset disable browser tool setting
2. set use remote browser
3. try launch button
4. manual launch chrome with correct options (debug and temp profile)
5. ask cline to use browser_actions

Provider/Model

No response

IDE / CLI Diagnostics

No response

System Information

No response