SonarQube for IntelliJ on Windows 11 cannot analyze projects opened from WSL2 path and incorrectly rewrites \\wsl.localhost\... to C:\wsl.localhost\...
Operating system:
Windows 11 Enterprise 25H2
OS build 26200.7985
Windows Feature Experience Pack 1000.26100.275.0
SonarQube for IntelliJ plugin version:
SonarQube for IDE 12.0.1.84418
IntelliJ version:
WebStorm 2026.1
Build #WS-261.22158.274, built on March 25, 2026
Runtime version: 25.0.2+1-b329.72 amd64 (JCEF 137.0.17-261-b65)
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Programming language youāre coding in:
TypeScript / JavaScript
Is connected mode used:
No.
I am using the plugin in standalone mode only, with no login and no connection to SonarQube Cloud / Server.
SonarQube Cloud, SonarQube Server, or SonarQube Community Build? (if one of the latter two, which version?):
None.
This is standalone local analysis only.
Thorough description of the problem / question:
I am reporting what appears to be a clear path-handling bug in SonarQube for IntelliJ on Windows when the project is opened directly from a WSL2 filesystem path.
My setup is:
-
WebStorm is installed on Windows 11
-
The project is stored inside WSL2 Ubuntu
-
The project is opened from this path:
\\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-api\
This setup works correctly with WebStorm itself and with other IDE functionality. TypeScript integration, WSL-based Node runtime, project indexing, editing, and other IDE features work. The only component that fails is SonarQube for IntelliJ.
I also explicitly configured a valid Windows Node.js runtime for SonarQube for IDE, and the plugin detects it correctly. So this is not a Node detection problem in this context.
The issue is that during analysis, the plugin / JS bridge rewrites the WSL UNC path into an invalid Windows local path:
-
Expected base directory:
\\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-api -
Actual path used by the bridge:
C:\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-api
That converted path does not exist, and analysis fails with:
java.util.concurrent.CompletionException: java.lang.RuntimeException: Received error from bridge: {ācodeā:āGENERAL_ERRORā,āmessageā:āENOENT: no such file or directory, opendir āC:\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-apiāā,āstackā:āError: ENOENT: no such file or directory, opendir āC:\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-apiāā}
This looks like a bug in path normalization / UNC handling in the plugin or in the JavaScript bridge layer. The plugin should preserve the original UNC path or otherwise handle WSL-backed paths correctly, instead of transforming them into C:\wsl.localhost\....
This is especially important because this is not an exotic setup for JetBrains users on Windows. Opening projects directly from WSL2 paths is a normal workflow, and the rest of WebStorm works correctly in that mode.
I am not looking for JetBrains Gateway / Remote Development as a workaround. In my environment, that is not an acceptable solution due to additional UI latency and performance overhead over Windows remote desktop / VDI. The issue here is that standard local WebStorm on Windows already works with WSL2 paths, and SonarQube for IntelliJ should support the same workflow.
Root symptom
The plugin fails because it treats a valid WSL UNC path as if it were under C:\, which produces a nonexistent directory and causes the JS bridge to fail with ENOENT.
Why this looks like a plugin BUG
-
WebStorm can open and work with the project from
\\wsl.localhost\Ubuntu-22.04\... -
Other IDE features work
-
SonarQube for IDE detects the configured Windows Node correctly
-
The failure happens specifically when Sonarās bridge tries to open the project root
-
The failing path is not the original path; it is a broken transformation of it
Reproduction steps
-
Install WebStorm on Windows 11.
-
Install SonarQube for IntelliJ / SonarQube for IDE plugin.
-
Keep a TypeScript project inside WSL2 Ubuntu.
-
Open the project in WebStorm using a UNC WSL path such as:
\\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-api -
Configure SonarQube for IDE to use a valid Windows Node.js executable.
-
Open a TypeScript file and trigger analysis.
Actual result
Analysis fails with bridge errors and ENOENT, because the plugin tries to use:
C:\wsl.localhost\Ubuntu-22.04\home\alex\projects\mmh-api
instead of the original UNC path.
Expected result
The plugin should analyze files successfully when the project is opened from a WSL UNC path, and it should not rewrite:
\wsl.localhost\Ubuntu-22.04...
into:
C:\wsl.localhost\Ubuntu-22.04...
Attachments
-
The SonarQube for IDE settings screenshot shows that the plugin correctly sees the Windows Node.js executable.
-
The WebStorm TypeScript settings screenshot shows that the IDE itself works correctly with WSL2 paths and WSL Node / TypeScript.
Flight Recorder: