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.

To install the CLI and run your first command, see the Quickstart guide.

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 or SonarQube Cloud 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.

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 is better suited to terminal workflows, 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 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, so don't treat them 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. 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).
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 so checks run before you commit or push:

• A pre-commit hook scans staged files and catches secrets as early as possible.
• A pre-push hook scans files in unpushed commits and runs one batched check before you push.

See Git hooks.

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, 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 doesn't collect:

• Source code or file contents
• File paths or filenames
• Project names or keys (only server-side UUIDs)
• Command arguments, flag values, or output
• Token or credential values

To turn it off, run sonar config telemetry --disabled. For more detail, see Telemetry and privacy.