Environment
- macOS, Apple Silicon
- SonarQube Cloud, EU region, Connected Mode, bound project
- Node.js v24.14.0
- SonarQube for VS Code 5.8.1 (darwin-arm64)
- SonarQube for IntelliJ in WebStorm 2026.2.0.1 (sonarlint-core 11.9.0.86162)
- JavaScript/TypeScript/CSS analyzer 13.6.0.44263 — shared by both
Reproduction: open any project whose absolute path contains a space (mine is …/DCT Web App/DCT Code) and analyse an HTML or JS file.
Observed — identical in both IDEs:
Execute Sensor: JavaScript/TypeScript/CSS analysis
File ignored due to analysis scope filters: /Users/…/DCT%20Web%20App/…
Error: “/Users/…/DCT%20Web%20App/DCT%20Code/tools” is not nested under
topDir “/Users/…/DCT Web App/DCT Code”
at mer (…/eslint-bridge/package/bin/server.cjs:1780:377192)
Failed to analyze file […/tools/DCT_AccessCodeGenerator.html]
Analysis detected 0 issues and 0 Security Hotspots
One side of the comparison is URL-encoded (%20), the other is a plain filesystem path, so the nesting check fails and the file is refused.
Related symptom, same encoding: fatal: Invalid path '/Users/…/DCT%20Web%20App': No such file or directory from native git blame.
Impact — the reason I’m reporting rather than working around it: the failure surfaces as 0 issues with a green Findings panel. A file with known server-side findings appears clean, and the only evidence is a line in a verbose log. A user with no reason to be suspicious would read this as a passing file. Since the HTML sensor doesn’t use the bridge, Web:* rules still report normally — which makes the tool look like it’s working while JavaScript and CSS analysis is silently absent.
Verbose logs from both IDEs available on request.