TL;DR: do not debug this from the UI message, it is generic by design. Turn on verbose logging in the SonarQube for IDE extension, reproduce the failure once, and read the HTTP status in the log: that one number splits the problem into authentication (401), permission (403), proxy authentication (407), a wrong or intercepted URL (404 or an unexpected-body error), or a version mismatch. Then fix only that branch, in this order: confirm the credential is a User token (not a Project Analysis or Global Analysis token), confirm the same account can see the project in the server web UI, confirm the connection URL matches the browser URL character for character, and only then chase proxy, TLS, and version problems. Verbatim errors (the search that created the source thread, plus the two UI messages this family produces): ```text SonarQube connected mode error Loading the projects from the server failed Project was not found ``` Symptoms: the connection itself is created successfully and the connection name lights up, but selecting a project fails with the loading message, the project list stays empty, or binding by a manually entered project key reports the project was not found, even when the key was copied straight from the server. ## Steps ### 1. Turn on verbose logs and read the HTTP status first The UI messages hide the real error. In Visual Studio, open Extensions, then SonarQube, then Options, then General, and set the logging level to Verbose, then check the Output window for SonarQube. In IntelliJ and Eclipse, open the SonarQube for IDE tool window, open its settings, and enable Verbose output, then read the Log tab. In VS Code, open the Output panel and select SonarQube for IDE, and raise the extension log level in settings if the lines are too thin. Reproduce the failure exactly once and find the failing request line. Expected output: a log line naming the request and its status, for example a status request to the server api system status path returning 200, followed by a projects request that fails. Success check: you can name one status code for the failure (401, 403, 404, 407, a certificate error, or an unexpected-body error) before changing any setting. Every later step keys off that code. ### 2. Fix a 401 by replacing the token with a User token Connected mode requires a User token for your own account. Project Analysis tokens and Global Analysis tokens are for scanner runs and do not work for this flow, no matter how broad they look. On the server, open My Account, then Security, generate a token of type User, delete the old connection in the IDE, and create the connection again with the new token. Do not edit the token inside the broken connection; a clean connection rules out a stale saved credential. Expected output: the connection validates and the projects request returns 200 in the verbose log. Success check: the project list populates without restarting the server. If a fresh User token still returns 401, the saved credential store is suspect, not the token; see the when-this-does-not-apply section for the Visual Studio 11.0.0 case. ### 3. Fix a 403 by checking Browse permission in the web UI, outside the IDE Sign in to the SonarQube Server or SonarQube Cloud web UI in a browser with the same account the token belongs to, not an admin account, and open the Projects list. If the project is not visible there, the IDE will never list or bind it: a project administrator must grant that account the Browse permission on the project (and, for SonarQube Cloud, the account must belong to the organization the project lives in). Making the project public is not a substitute for checking the account, and testing with a full admin account masks this failure for end users, because admins see everything. Expected output: the project appears in the web UI Projects list for that account. Success check: back in the IDE, refresh the connection and the same project now appears in the picker; a manual key entry with the exact project key from the project Information page binds instead of reporting not found. ### 4. Fix a 404 or empty response by matching the server URL exactly Compare the URL saved in the IDE connection with the URL you actually use in the browser: scheme, host, port, and any context path must all match, and a stray trailing slash or a missing context path (for example a server served under a /sonar style path) sends the API calls to the wrong place and produces 404s or empty lists that look like permission problems. Correct the connection URL to the browser URL, character for character, and re-validate the connection. Expected output: the verbose log shows the status request hitting the same base URL you browse to and returning 200. Success check: the projects request that follows returns 200 as well, not just the status check. ### 5. Fix a 407, certificate error, or unexpected-body error at the proxy and TLS layer A 407 in the log means a corporate proxy between the IDE machine and the server is demanding authentication the IDE did not supply; configure the proxy in the IDE or OS network settings rather than retrying the connection. A certificate error means the server certificate (often a private CA or a load balancer doing TLS bridging) is not trusted by the IDE runtime; import the CA into the trust store the IDE extension uses and restart the IDE. An unexpected-body error in the log, where the status check returned 200 but the projects call failed on its response body, usually means something in the path answered with HTML instead of API JSON: a login banner, a smartcard or SSO intercept page, or a load balancer error page. Open the exact API URL from the log in a browser on the same machine and confirm you get the server response, not an intercept page; clear the intercept with your network team before touching the IDE again. Expected output: the projects request in the verbose log returns 200 with no proxy, certificate, or body error. Success check: the failure survives no restart test, meaning you restart the IDE, reopen the solution or project, and the binding is still connected. ### 6. Rule out a version mismatch between the IDE extension and the server Connected mode requires a SonarQube Server project on an active, supported server version, and an IDE extension that is current enough to talk to it. A server past end of life breaks connected features in misleading ways (older servers, for example, cannot serve the token-generation page newer extensions open, which surfaces as a page-not-found in the browser during connection setup), and a very old IDE extension against a current server fails to connect even with the right URL and token. Record both versions from the log header, update the IDE extension first, and if the server is past end of life, follow the server upgrade path (long-term active release to long-term active release) before debugging the binding further. Expected output: extension and server are both on supported versions. Success check: with versions aligned, the connection setup completes end to end, including the browser token step, with no page-not-found. ### 7. Bind with the project open and only one candidate project in play For the no-matching-project variant during automatic binding: open the project in the IDE first, and close other projects or IDE windows that are not the one you are binding, because the extension can pick the wrong open project and report no match. For SonarQube Cloud in VS Code, check the saved connection in the workspace or user settings file includes the organization key for the organization that owns the project; a connection without it validates against the wrong scope and lists nothing. Then run the update-bindings action for your IDE (Update all project bindings in VS Code, IntelliJ, and Eclipse; Manage Binding under Connected Mode in Visual Studio) so quality profiles, rules, and issue suppressions sync from the server. Expected output: the binding shows the server project key and a synchronized state. Success check: an issue that is marked accepted or resolved on the server shows the same state in the IDE, which proves the sync, not just the connection, is working. ## When this applies - SonarQube for IDE (formerly called SonarLint) in Visual Studio, VS Code, IntelliJ, or Eclipse, bound to SonarQube Server, SonarQube Cloud, or SonarQube Community Build - The connection can be created, but Loading the projects from the server failed appears, the project list is empty, or a manual project key reports Project was not found - The verbose log shows a 401, 403, 404, or 407, a certificate error, or an unexpected-body error on the projects request ## When this does not apply - Visual Studio 11.0.0 shows the bar saying the token for the server connection is invalid right after the extension update, and re-entering a valid SonarQube Cloud token never clears it. That is a separate, confirmed credential-store bug in that build with its own fix; this skill is not it. - The failure is in a CI scanner run (the scanner CLI or a build pipeline failing to analyze or upload). That is scanner configuration, not IDE connected mode. - Analysis runs but the quality gate fails, or local results differ from server results. Connected mode is working in those cases; the problem is rules, scope, or gate conditions. - The token is simply expired and a fresh User token fixes it in one try. That is routine renewal, step 2 only. ### Variant: Project was not found on a manually entered key Same family, binding path instead of list path. The key was copied correctly in the reported case and it still failed, which points back to steps 3 to 5: the account cannot browse the project, the URL points at a different server or context path than the one the key came from, or an intercept page answered the lookup. Do not retype the key repeatedly. ### Variant: No matching project found during automatic binding That is step 7: the target project was not the open one, or several projects were open in different windows. Open only the target project and bind manually if automatic matching still fails. ### Variant: the connection worked until the server was upgraded Treat it as step 6 first: an extension that matched the old server may not match the new one, and the log header versions will show the gap. Update the extension before recreating connections. ### Variant: no matching issue found for an issue opened from the server Different symptom, usually not a connection failure at all: you are on a different branch than the analyzed branch, or the issue was already fixed and the local code differs from the analyzed version. Check the branch before redoing the connection. ## Why it happens The picker and the binding dialog make two different server calls, list projects and look up one project, and both sit behind the same generic UI error text, so several unrelated failures look identical on screen. Underneath, connected mode is just authenticated API access from the IDE: it needs a credential of the right type (a User token, because it acts as you), an account that can browse the project, a URL that reaches the real API base, a network path that returns the API response untouched, and client and server versions that still speak the same connected-mode protocol. Each step above removes exactly one of those layers, and the verbose log is the only place that tells you which layer is actually failing. ## Edge cases and pitfalls - Do not debug with an admin account and then ship the setup to end users: admin visibility hides the Browse permission failure that will hit everyone else. Always re-test with an account that has only the permissions end users get. - Changing a project from private to public does not diagnose this: in the reported case it changed nothing, because the failure was in the connection path, not project visibility. - A 200 on the server status check does not prove the connection is healthy: in the reported log the status request returned 200 while the projects request failed on its response body. Read the projects line, not just the first success. - Shared or team binding files committed to the repo do not fix a broken personal connection; the log line saying the shared binding configuration file was not found is informational, and binding still works per-developer once the connection itself is fixed. - Recreating the connection repeatedly without reading the log destroys evidence: each retry looks the same in the UI. Capture one verbose reproduction first, then change one thing at a time.