> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-cli/support/faq.md). # Frequently asked questions Answers to common questions about the SonarQube CLI: how it compares to other Sonar tools, what it can do, and how to get started. This page answers common questions about the SonarQube CLI: how it compares to other Sonar tools, what it can do, and how to get started. To install the CLI and run your first command, see the [Quickstart guide](/sonarqube-cli/quickstart-guide.md). ## Who is the CLI for? The CLI is well suited for: * Developers who work heavily in the terminal * Teams adopting AI coding assistants * Platform, DevSecOps, and engineering teams that want lightweight verification earlier in the workflow * Organizations that already use SonarQube and want terminal-based access to analysis, issue lookup, and automation ## How is the SonarQube CLI different from the SonarScanner CLI? They solve different problems. The SonarScanner CLI sends full project analysis to SonarQube from your CI/CD pipeline; it's a build step, not a developer tool. See the SonarScanner CLI docs for [SonarQube Server](https://docs.sonarsource.com/sonarqube-server/analyzing-source-code/scanners/sonarscanner/) or [SonarQube Cloud](/sonarqube-cloud/analyzing-source-code/scanners/sonarscanner-cli.md) for the complete details. The SonarQube CLI is for local developer use: browsing issues, running secrets detection, configuring AI agent integrations, and getting context for remediation without leaving the terminal. If you're looking for a way to run a full project scan from a script, a Python package, or an npm package, those are wrappers around the SonarScanner CLI. The links above are the right starting point. ## Is it the same as a full SonarQube scan? No. The CLI is designed for local agentic workflows and works on your current local changes, not your full project. For full project analysis, run the SonarScanner CLI in your CI/CD pipeline. ## Why use the CLI if you already use SonarQube for IDE? They're complementary. SonarQube for IDE is best when you want feedback directly in the editor while you code, and for reviewing and committing changes from the IDE. The CLI covers workflows the IDE does not reach: terminal sessions, scripts, Git hooks, and AI coding sessions. ## Do you need both MCP and the CLI? Not necessarily. Use the CLI when you or your coding agents need to run SonarQube actions directly from the terminal. Use the [About the MCP Server](/sonarqube-mcp-server/about-the-mcp-server.md) when you want your AI coding assistant to access SonarQube (Server, Cloud) data as one of multiple tools in an agentic workflow. ## Is there feature parity between MCP and the CLI? No. The CLI and MCP support related but different workflows and cannot be treated as one-to-one equivalents. ## How fast is it, and what's the impact on your machine? The CLI is built to give you fast local feedback. Runtime depends on the size of your repository, the command you run, the scope of your local changes, and whether the workflow relies on SonarQube Cloud capabilities. ## What's the simplest way to get started? Follow the [Quickstart guide](/sonarqube-cli/quickstart-guide.md). It's the fastest path to get up and running. In short: 1. Install the CLI with Homebrew, Mise, or the official install script (see the [quickstart guide](/sonarqube-cli/quickstart-guide.md)). 2. Authenticate with `sonar auth login`. 3. Confirm the connection with `sonar auth status`. 4. Run your first command, such as `sonar list projects`, `sonar analyze secrets`, or `sonar analyze --staged`. ## Can it run as a pre-commit or pre-push hook? Yes. The CLI can install Git hooks that run checks before you commit or push: * A pre-commit hook scans staged files and catches secrets as early as possible. * A pre-push hook scans the commits a push would transfer and runs one batched check before you push. A native or Husky install reads those commits from git and names the commit that introduced a secret. See [Git hooks](/sonarqube-cli/integrations/git-hooks.md). ## What telemetry does the CLI collect? By default, the SonarQube CLI collects two kinds of data: anonymous usage telemetry and crash reports for unhandled exceptions. Telemetry covers which commands you run, which flags and positional arguments you passed, whether they succeed, the CLI version, your operating system, and which SonarQube connection the command ran against. Crash reports scrub personal paths before they're sent. It does not collect: * Source code or file contents * File paths or filenames * Project names or keys (only server-side UUIDs) * Free-form flag values and free-form positional argument values * Command output * Token or credential values To turn it off, run `sonar config set telemetry.enabled false`. For more detail, see [Telemetry and privacy](/sonarqube-cli/administration/telemetry-and-privacy.md). Local stats about analyzer runs are separate from telemetry. They stay on your machine and are never transmitted. Collection stays on when telemetry is off and when `DO_NOT_TRACK` is set. Turn it off with `sonar config set stats.enabled false`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.sonarsource.com/sonarqube-cli/support/faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.