Hello Community!
This week we were pleased to announce that we’re extending our Advanced Security solution to SonarCloud Team plan users. You can now enjoy SCA (and other features) in your organization. Excuses to ship insecure code are running out! On the SonarQube CLI front, things are still advancing really fast with the release of v1.1. Your AI agent of choice will be delighted with the new features packed into this version.
So now, like every week, we’d like to take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.
SonarQube for IDE
@gquerret flagged a “Duplicate configuration scope registered” message appearing in the SonarQube for IDE output tab in VS Code whenever editor focus shifts between panes. It looks alarming at INFO level, but it’s harmless. We’ve noted a fix to lower the log level, which will roll out with upcoming releases. Thanks for the clear report!
@benjaminbartsch spotted a race condition in the SonarQube for IDE Eclipse plugin: rapidly clicking between issues in the report list while analysis is running throws a “Failed to retrieve finding details” error. For now you simply have to wait for analysis to finish before interacting with the list. We’ve tracked the fix internally and will update the thread when it ships.
Two independent reports landed about C/C++ analysis silently failing when source paths contain special characters. @leCapi (1) reported that a source directory named src/c++/ becomes src/c%2B%2B/ in VS Code file URIs, causing the CFamily sensor to look for a path that doesn’t exist on disk. @ragnarmargus (2) hit the same class of problem in CLion: the @ in a home directory path encodes differently across file URIs and build-wrapper output, so files never match. Both trace back to the same root cause, and a fix is on the way. Nice catch!
@gian1200 pointed out two things at once: a typo in our connected mode docs, and a valid concern about committing .vscode/settings.json to source control. For now, our recommendation is to not version that file at all. We’ve opened an internal ticket to explore a cleaner solution. What a keen eye!
C# analysis in Rider has been silently returning 0 issues and “File to analyze was not found in the file system” errors for several users. @MF-Bridgefield, @julient, and @smailund all reported the same problem: OmniSharp 1.39.15 doesn’t play nicely with .NET SDK 10, and the failure affects even net8.0 projects if SDK 10 is installed alongside older ones. Two fixes are in the pipeline: one to make sure the plugin passes the correct SDK version to OmniSharp, and another to surface a clear error message instead of silently returning no issues. Thanks for the detailed logs and test projects!
SonarQube Cloud
@lrozenblyum noticed that encoding warnings in SonarQube Cloud don’t respect the current branch: fixing the encoding issue on a feature branch still shows the main branch’s warning on every branch and PR. You’re right that this is wrong 
We confirmed a regression and a fix is on the way.
A Microsoft hosted-agent update (ubuntu image 20260615) caused CveReachabilitySensor to throw an exception. @chan-buchi, @Bruno_Novais, and @milbrandt all reported being affected, including on self-hosted Windows agents. We temporarily disabled the feature to stop the errors while a fix was deployed. Thank you for the quick reports!
Scanners
Multi-module Gradle builds using JaCoCo can flood CI logs with “File <filename> not found in project sources” warnings for generated files covered by JaCoCo but excluded from sonar.sources. @Bug let us know this was making their logs unusable. Community member @rkrisztian came through with a clean fix: exclude the generated files from JaCoCo coverage using classDirectories.setFrom() in the JaCoCo report task. We’re working on getting this into our docs so the next person doesn’t have to dig for it. Thanks @rkrisztian for the great answer!
@dfraser reported that PR analyses were landing on the main branch instead of the PR when running SonarScanner for Maven via Jenkins with Bitbucket Cloud and SonarQube Cloud. This combination doesn’t support automatic PR detection, so certain configuration properties must be passed manually. @dfraser confirmed it worked after trying that, and we’ve updated the docs to call out this limitation. Thanks for closing the loop!
Thanks again to everyone mentioned here - and to anyone we may have missed - for your ongoing contributions in making this community stronger and helping us improve Sonar products.
If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!