> 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/using-sonarqube-cli/commands.md).

# Commands reference

A complete reference for SonarQube CLI commands, with arguments, options, defaults, and examples.

This page documents every SonarQube CLI command. Find the full SonarQube CLI command reference, including options and examples, at [sonarsource.com/sonarqube/cli](https://sonarsource.com/sonarqube/cli/). A machine-readable version of the command reference is also available as JSON at [sonarsource.com/sonarqube/cli/data/commands.json](https://sonarsource.com/sonarqube/cli/data/commands.json).

Each entry includes a description, the arguments and options it accepts (with types, defaults, and whether they're required), and runnable examples.

Some commands have a shortcut alias. Root help shows them as `command|alias` (for example, `quality-gate|qg`). Either form runs the same command.

For longer guides on how to use these commands, see the [Overview](/sonarqube-cli/integrations/integrations.md), [Overview](/sonarqube-cli/analysis/analysis.md), and [Overview](/sonarqube-cli/administration/administration.md) pages.

## Commands at a glance

| Group              | Commands                                                                                            |
| ------------------ | --------------------------------------------------------------------------------------------------- |
| **Authentication** | `sonar auth login`, `logout`, `status`                                                              |
| **Integrations**   | `sonar import`, `integrate`, `integrate claude`, `copilot`, `codex`, `cursor`, `antigravity`, `git` |
| **Analysis**       | `sonar analyze`, `analyze secrets`, `analyze agentic`, `analyze dependency-risks`, `remediate`      |
| **Information**    | `sonar list issues`, `list projects`, `quality-gate status` (`qg`), `api`, `context`                |
| **Configuration**  | `sonar link`, `config telemetry`, `config stats`                                                    |
| **Maintenance**    | `sonar system status`, `system reset`, `update`, `update status` (standalone builds only)           |

| Command                     | Description                                                                                                                                                                                                                                              |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sonar auth`                | Manage authentication tokens and credentials.                                                                                                                                                                                                            |
| `sonar api`                 | Make authenticated API requests to SonarQube.                                                                                                                                                                                                            |
| `sonar integrate`           | Set up SonarQube integration for AI coding agents, Git, and others.                                                                                                                                                                                      |
| `sonar import`              | Import GitHub or Azure DevOps repositories into SonarQube Cloud (Beta).                                                                                                                                                                                  |
| `sonar list`                | List issues and projects from SonarQube.                                                                                                                                                                                                                 |
| `sonar quality-gate` (`qg`) | Fetch quality gate status from SonarQube Cloud or Server.                                                                                                                                                                                                |
| `sonar context`             | Augment AI agents with context from your codebase.                                                                                                                                                                                                       |
| `sonar remediate`           | Trigger AI agent remediation for eligible issues.                                                                                                                                                                                                        |
| `sonar analyze`             | Run secrets detection and [Sonar Vortex analysis](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-analysis.md) on the local change set (default when no subcommand is given); subcommands cover SCA and targeted scans. |
| `sonar link`                | Link a project to the active connection in `.sonar-config.json`.                                                                                                                                                                                         |
| `sonar config`              | Configure CLI settings.                                                                                                                                                                                                                                  |
| `sonar system`              | System diagnostics and maintenance (status, reset).                                                                                                                                                                                                      |
| `sonar update`              | Update SonarQube CLI to the latest version (standalone builds only).                                                                                                                                                                                     |

***

## `sonar auth`

Manage authentication tokens and credentials.

### `sonar auth login`

Authenticate via browser or an existing token, then save credentials in the system keychain. The browser flow must be completed in a terminal; AI agents cannot finish it. To save a token you already have, pass `--with-token` and pipe or redirect it from a file. For CI/CD and automation, use [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md) instead.

The CLI validates the token against the server before saving it. A rejected token is not stored; generate a new user token and try again. If the server cannot be reached during validation, the command fails; check your network connection and retry.

> **Warning:** If environment-variable authentication is already active, browser `sonar auth login` warns that this login will not take effect until you unset those variables. It then asks whether to continue (default No). Declining cancels the login before the CLI contacts the server (exit code `1`). If you continue, the token is saved to the keychain, but the CLI keeps using the environment variables until you unset `SONARQUBE_CLI_TOKEN`. `--with-token` does not prompt: it fails immediately (exit code `1`) and does not save the token. Unset `SONARQUBE_CLI_TOKEN` and `SONARQUBE_CLI_SERVER` or `SONARQUBE_CLI_ORG` first. Run [`sonar auth status`](#sonar-auth-status) to see which credentials are in use.

**Options:**

| Option           | Type    | Required | Description                                                                                                                                                                                                                                                                                                                    | Default |
| ---------------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |
| `--server`, `-s` | string  | No       | Your SonarQube Server URL, SonarQube Cloud EU (`https://sonarcloud.io`), or SonarQube Cloud US (`https://sonarqube.us`). Must be an absolute `http` or `https` URL with a host. Required with `--with-token`. For browser login, when omitted, the CLI prompts you to choose server and region.                                | -       |
| `--org`, `-o`    | string  | No       | Your SonarQube Cloud organization key. Required with `--with-token` when `--server` is a SonarQube Cloud URL. For browser login, if omitted when authenticating to SonarQube Cloud, the CLI auto-selects your organization when you belong to exactly one, or prompts you to choose when you belong to multiple organizations. | -       |
| `--with-token`   | boolean | No       | Read an existing user token from standard input and save it in the keychain. Skips the browser and all prompts. Pipe or redirect the token; a terminal (TTY) is rejected (exit code `2`). The CLI validates the token before saving it and does not print it. Replaces any existing keychain token for that connection.        | -       |

**Examples:**

Interactive login (prompts for server type, region, and organization):

```bash
sonar auth login
```

Interactive login with a pre-selected server (skips the server and region prompts):

```bash
# SonarQube Server (self-hosted)
sonar auth login --server <YourSonarQubeServerURL>
# Also works with SonarQube Cloud EU or US region URLs
sonar auth login --server "https://sonarcloud.io"
sonar auth login --server "https://sonarqube.us"
```

Save an existing token without opening a browser. Put the user token in a file (one line, no extra text), then redirect it. `--server` is required. For SonarQube Cloud, `--org` is also required:

```bash
# SonarQube Server
sonar auth login --with-token --server <YourSonarQubeServerURL> < token.txt
# SonarQube Cloud
sonar auth login --with-token --server "https://sonarcloud.io" --org <YourOrganizationKey> < token.txt
sonar auth login --with-token --server "https://sonarqube.us" --org <YourOrganizationKey> < token.txt
```

`--with-token` rejects a terminal as standard input. Pipe or redirect a token; do not type it at a prompt or pass it as a command-line argument.

Use an absolute `http` or `https` URL with a host for `--server`, the server prompt, and a saved connection. A path, a port, and a trailing slash are allowed. The CLI rejects any other scheme and any value that contains a control character, such as a line break or a tab. An invalid `--server` value or saved connection fails with exit code `2`. When a saved connection fails this check, run `sonar auth logout`, then `sonar auth login`.

When you omit `--server`, the CLI uses a server URL from project configuration, such as `sonar.host.url` in `sonar-project.properties` or `serverUrl` in `.sonar-config.json`, only when that URL meets the same rule. It ignores an invalid value. If no valid server URL remains, it prompts you for a server.

For CI/CD pipelines and headless environments, use [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md) instead of `sonar auth login`.

***

### `sonar auth logout`

Remove the active connection token from the keychain. The CLI also best-effort revokes the token server-side when it was created via the interactive browser flow. Tokens imported with `--with-token` are removed locally only; they stay valid on the server.

Logout applies only to a saved keychain connection. If you authenticate only with [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md) and never ran `sonar auth login`, the command reports that you're already logged out. Unset `SONARQUBE_CLI_TOKEN` and its companion variables instead. If a keychain token exists from a previous login, logout still removes it even when those variables are currently in use.

**Examples:**

```bash
sonar auth logout
```

***

### `sonar auth status`

Show the active authentication connection and verify the token against the server.

**Options:**

| Option     | Type   | Required | Description                     | Default |
| ---------- | ------ | -------- | ------------------------------- | ------- |
| `--format` | string | No       | Output format (`text`, `json`). | `text`  |

Text output prints a connection summary. When the server cannot be reached, it prints the underlying network or TLS error (for example, a connection timeout) alongside the remediation hint.

If your account is not a member of the configured organization, text output prints that the organization is not accessible with this token and still exits `0` because the token itself is valid. Regenerate a user token from **My Account > Access Tokens**, or ask an organization administrator to add your account. `--format json` does not print that warning. It reports `status` `connected` (with `server`, `org`, and `source`) and still exits `0`.

`--format json` prints one JSON object on stdout and omits the text summary, spinner, and remediation hint. A failed check sets exit code `1` without extra error text, which lets a script parse stdout cleanly. `status` is `connected`, `not_authenticated`, `token_missing`, `token_invalid`, or `unreachable`. A saved connection also includes `server`, and `org` when an organization is configured. A successful check includes `source` (the keychain or environment variables). `unreachable` includes `message` with the network or TLS error.

**Examples:**

```bash
sonar auth status
sonar auth status --format json
```

***

## `sonar integrate`

Set up SonarQube integration for AI coding agents, Git, and other tools. Every integration installs globally on this machine (in your user home). Agent integrations have no project-scoped install. `sonar integrate git --local` is a workaround that installs the Git hook for the current repository only. The CLI does not accept `--project` / `-p` on `sonar integrate`. `-g` / `--global` is still accepted on each subcommand for compatibility. It has been deprecated since 1.9.0 and will be removed in a future version. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without the flag. On `sonar integrate git`, `--global` and `--local` cannot be used together (invalid-options error, exit code `2`). For step-by-step setup guides, see [Overview](/sonarqube-cli/integrations/integrations.md).

Running `sonar integrate` with no subcommand lists agents detected on this machine and tools already integrated, warns when Claude Code is detected alongside Cursor or Copilot (those pairs can conflict in hook execution), then prompts you to select one integration. To configure another tool, run `sonar integrate` again. Alternatively, call a subcommand directly (for example, `sonar integrate claude`). There's no bulk install of every detected agent.

**Options:**

| Option              | Type    | Required | Description                                                                                            | Default |
| ------------------- | ------- | -------- | ------------------------------------------------------------------------------------------------------ | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts). Requires an explicit agent subcommand; invalid on the bare command. | -       |

> **Note:** `sonar integrate --non-interactive` with no subcommand fails with an invalid-options error (exit code `2`). Run `sonar integrate <agent> --non-interactive` instead, for example `sonar integrate claude --non-interactive`. The flag works before or after the agent name.

**Examples:**

```bash
sonar integrate
sonar integrate claude --non-interactive
sonar integrate --non-interactive claude
```

### `sonar integrate claude`

Installs secrets-detection hooks and the [SonarQube MCP server](https://docs.sonarsource.com/sonarqube-mcp-server/) in `~/.claude`. On a connection with a Vortex subscription, also offers Vortex: one install that sets up Vortex analysis and [Vortex context](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-context.md). See [Claude Code](/sonarqube-cli/integrations/claude-code.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                           | Default |
| ------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                    | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without this flag. | -       |

**Examples:**

```bash
sonar integrate claude
sonar integrate claude --non-interactive
```

***

### `sonar integrate copilot`

Set up the SonarQube integration for GitHub Copilot CLI. Installs secrets-detection hooks and the SonarQube MCP server in `~/.copilot`. On a connection with a Vortex subscription, also offers Vortex: one install that sets up Vortex analysis and [Vortex context](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-context.md). See [GitHub Copilot CLI](/sonarqube-cli/integrations/github-copilot-cli.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                           | Default |
| ------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                    | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without this flag. | -       |

**Examples:**

```bash
sonar integrate copilot
sonar integrate copilot --non-interactive
```

***

### `sonar integrate codex`

Set up the SonarQube integration for OpenAI Codex. Installs a `UserPromptSubmit` secrets hook, secrets-on-read instructions, and MCP configuration in `~/.codex`. On a connection with a Vortex subscription, also offers Vortex: one install that sets up Vortex analysis and [Vortex context](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-context.md). See [OpenAI Codex](/sonarqube-cli/integrations/codex.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                           | Default |
| ------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                    | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without this flag. | -       |

**Examples:**

```bash
sonar integrate codex
sonar integrate codex --non-interactive
```

***

### `sonar integrate cursor`

Set up the SonarQube integration for Cursor. Installs `beforeSubmitPrompt`, `beforeReadFile`, and `preToolUse` secrets hooks, and MCP configuration in `~/.cursor`. On a connection with a Vortex subscription, also offers Vortex: one install that sets up Vortex analysis and [Vortex context](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-context.md). Cursor's cloud and background agents only pick up project-level hooks, not these global ones. See [Cursor](/sonarqube-cli/integrations/cursor.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                           | Default |
| ------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                    | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without this flag. | -       |

**Examples:**

```bash
sonar integrate cursor
sonar integrate cursor --non-interactive
```

***

### `sonar integrate antigravity`

Set up the SonarQube integration for Google Antigravity. Installs a `PreToolUse` secrets hook, prompt-secrets rules, and MCP configuration under `~/.gemini/`. On a connection with a Vortex subscription, also offers Vortex analysis. Antigravity has no session-start hook; therefore, the CLI integration installs Vortex analysis only. To use Vortex context with Antigravity, set up a [self-hosted MCP server](/sonarqube-mcp-server/setup/quickstart-guides/antigravity.md#set-up-a-self-hosted-mcp-server). See [Google Antigravity](/sonarqube-cli/integrations/antigravity.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                           | Default |
| ------------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                    | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. Use the command without this flag. | -       |

**Examples:**

```bash
sonar integrate antigravity
sonar integrate antigravity --non-interactive
```

***

### `sonar integrate git`

Install a Git pre-commit hook that scans staged files for secrets and dependency risks before each commit, or a Git pre-push hook that scans committed files for secrets before each push. By default the command installs globally: it writes hook scripts under `~/.sonar/sonarqube-cli/hooks/` and sets `git config --global core.hooksPath` to that directory. Pass `--local` to install the hook for this repository only, as a workaround when a global hook does not fit (for example, an existing Husky setup). There's no interactive prompt for `--local`; you must pass the flag. In an interactive terminal, it prompts separately for each code scanning hook type. See [Git hooks](/sonarqube-cli/integrations/git-hooks.md).

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                              | Default |
| ------------------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |
| `--hook`            | string  | No       | Hook to install: `pre-commit` (scan staged files) or `pre-push` (scan files in unpushed commits).                                                                        | -       |
| `--force`           | boolean | No       | Overwrite an existing hook if it's not from `sonar integrate git`.                                                                                                       | -       |
| `--non-interactive` | boolean | No       | Non-interactive mode (no prompts).                                                                                                                                       | -       |
| `--local`           | boolean | No       | Install the hook for this repository only, instead of globally (workaround when a global hook does not fit, for example Husky).                                          | -       |
| `--global`, `-g`    | boolean | No       | Deprecated since 1.9.0. The install is already global; using the flag prints a warning and does not change the installation scope. It cannot be combined with `--local`. | -       |

**Examples:**

```bash
sonar integrate git
sonar integrate git --hook pre-push
sonar integrate git --non-interactive
sonar integrate git --hook pre-push --non-interactive
sonar integrate git --local
sonar integrate git --hook pre-commit --local --non-interactive
```

***

## `sonar import`

Import repositories from the GitHub or Azure DevOps organization on your active SonarQube Cloud connection. This command is Beta: root help shows a `[BETA]` tag. The first time you run it after you install or upgrade the CLI, you'll see a one-time notice on stderr that the command is in beta and may change. See [Beta, alpha, and deprecated commands](/sonarqube-cli/support/help.md#beta-alpha-and-deprecated-commands).

`sonar import` runs on SonarQube Cloud only. Authenticate first (`sonar auth login` or [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)), and connect to a SonarQube Cloud organization. You must be an administrator of that organization. The CLI uses the organization on the active connection. It does not ask you to pick a different one. If the organization is bound to a DevOps platform other than GitHub or Azure DevOps, the command stops before it lists repositories.

The command creates a SonarQube Cloud project for each repository you select. A repository is eligible when it has not already been imported and its visibility is allowed by the organization's project visibility settings.

Pass exactly one of `--repo`, `--all`, or `--regex`. Omit all three to choose in a prompt:

* `--repo` selects repositories by slug (the interactive **Manual** choice).
* `--all` imports every eligible repository (the interactive **Recommended** choice).
* `--regex` imports eligible repositories whose DevOps platform name matches a regular expression. The match uses the repository name, not the slug (the interactive **By pattern** choice).

Passing more than one of those flags fails with an invalid-options error (exit code `2`). `--non-interactive` skips prompts and requires one of the three flags. On success, the CLI prints how many repositories it imported and a link to that organization's project list. If one or more repositories fail, the command exits with an error and reports how many imports succeeded and how many failed.

**Options:**

| Option              | Type    | Required | Description                                                                                                                                                                                                              | Default |
| ------------------- | ------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |
| `--repo`            | string  | No       | DevOps platform repository slug (for example, `my-org/my-repo`). Repeat the flag, or separate slugs with commas, to import more than one repository. Cannot be combined with `--all` or `--regex`.                       | -       |
| `--all`             | boolean | No       | Import every eligible repository (not already imported, and allowed by the organization's project visibility settings). Cannot be combined with `--repo` or `--regex`.                                                   | -       |
| `--regex`           | string  | No       | Regular expression matched against the DevOps platform repository name, not the slug. Case-sensitive unless you wrap it as `/pattern/flags` (for example, `/^archived-/i`). Cannot be combined with `--repo` or `--all`. | -       |
| `--non-interactive` | boolean | No       | Skip prompts. Requires `--repo`, `--all`, or `--regex`.                                                                                                                                                                  | -       |

**Examples:**

```bash
sonar import
sonar import --repo my-org/my-repo
sonar import --repo my-org/api,my-org/web
sonar import --all
sonar import --regex "^test-"
sonar import --regex "/^archived-/i" --non-interactive
```

***

## Analysis

### `sonar analyze`

Run every analysis the CLI supports on your local change set: secrets detection first, then Vortex analysis when your connection has a Vortex subscription. This is the recommended command before a commit or pull request. See [Analyzing local changes](/sonarqube-cli/analysis/analyzing-local-changes.md).

`sonar verify` is a hidden compatibility alias for this command. It has been deprecated since 0.14 and will be removed in a future version. Use `sonar analyze` instead.

**Options:**

| Option            | Type    | Required | Description                                                                                  | Default |
| ----------------- | ------- | -------- | -------------------------------------------------------------------------------------------- | ------- |
| `--file`          | string  | No       | Analyze specific file(s) instead of the git change set (repeatable).                         | -       |
| `--staged`        | boolean | No       | Analyze staged files only (`git diff --cached`).                                             | -       |
| `--base`          | string  | No       | Analyze files changed vs a branch or ref (e.g. `main`).                                      | -       |
| `--depth`         | string  | No       | Analysis depth (`STANDARD`, `DEEP`). Default: `STANDARD` for one `--file`; `DEEP` otherwise. | -       |
| `--project`, `-p` | string  | No       | SonarQube project key (overrides auto-detected project).                                     | -       |
| `--force`         | boolean | No       | Skip the large change-set confirmation prompt.                                               | -       |
| `--format`        | string  | No       | Output format (`text`, `json`).                                                              | `text`  |

> **Note:** `--branch` is available on `sonar analyze agentic` but not on the bare `sonar analyze` command. When you omit `--branch`, the CLI auto-detects your current git branch. Use `sonar analyze agentic` when you need to set or override branch context.

**Examples:**

```bash
sonar analyze
sonar analyze --staged
sonar analyze --file src/a.ts --file src/b.ts
sonar analyze --base main --format json
sonar analyze --project my-org_my-app
```

***

### `sonar analyze secrets`

Scan files or standard input for hardcoded secrets.

**Arguments:**

| Argument   | Description                                  |
| ---------- | -------------------------------------------- |
| `[paths…]` | File or directory paths to scan for secrets. |

**Options:**

| Option    | Type    | Required | Description                                | Default |
| --------- | ------- | -------- | ------------------------------------------ | ------- |
| `--stdin` | boolean | No       | Read from standard input instead of paths. | -       |

**Exit behavior:** exits with code `51` when secrets are found, `0` when none are found. See [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md).

**Examples:**

Scan a file:

```bash
sonar analyze secrets src/config.ts
```

Scan a directory:

```bash
sonar analyze secrets src/
```

Scan stdin:

```bash
cat .env | sonar analyze secrets --stdin
```

#### Custom secret rules from SonarQube Server

When the SonarQube CLI is authenticated, `sonar analyze secrets` automatically downloads and executes custom secret rules (instances of rule template **S6784**) defined on the connected SonarQube Server instance. Rules are cached locally and refreshed on each run. If the download fails, the SonarQube CLI falls back to a stale cache with a warning. No CLI flag is required. Custom secret rules are not yet available on SonarQube Cloud; support is planned.

***

### `sonar analyze agentic`

Run server-side [Vortex analysis](/agent-centric-development-cycle/inside-your-agent-the-agentic-loop/sonar-vortex-analysis.md) on local changes. Requires a Vortex subscription (available with SonarQube Cloud Team or Enterprise plan, or SonarQube Server 2026.5 or newer Enterprise and Data Center editions). Limitations apply; see [Vortex on sonarsource.com](https://www.sonarsource.com/products/sonar-vortex/).

Integrate commands check subscription status, not consumption. If your connection has a Vortex subscription but has reached its usage limit, hooks and instructions are still installed; analysis through this command is unavailable until usage resets. On HTTP 403, the CLI re-checks subscription status and reports usage-limit exhaustion separately from a revoked subscription. See [integrations/README.md](/sonarqube-cli/integrations/integrations.md) for hook behavior and notice throttling.

**Options:**

| Option            | Type    | Required | Description                                                                                  | Default |
| ----------------- | ------- | -------- | -------------------------------------------------------------------------------------------- | ------- |
| `--file`          | string  | No       | Analyze specific file(s) instead of the git change set (repeatable).                         | -       |
| `--staged`        | boolean | No       | Analyze staged files only (`git diff --cached`).                                             | -       |
| `--base`          | string  | No       | Analyze files changed vs a branch or ref (e.g. `main`).                                      | -       |
| `--branch`        | string  | No       | Branch name sent to SonarQube (auto-detected from git when omitted).                         | -       |
| `--depth`         | string  | No       | Analysis depth (`STANDARD`, `DEEP`). Default: `STANDARD` for one `--file`; `DEEP` otherwise. | -       |
| `--project`, `-p` | string  | No       | SonarQube project key (overrides auto-detected project).                                     | -       |
| `--force`         | boolean | No       | Skip the large change-set confirmation prompt.                                               | -       |
| `--format`        | string  | No       | Output format (`text`, `json`).                                                              | `text`  |

> **Notes:**
>
> * The CLI prompts for confirmation when the change set exceeds 50 files. Pass `--force` to skip the prompt, or use `--format json` (which suppresses the prompt automatically).
> * Agentic analysis sends your change set in a single multi-file request, letting a `DEEP` analysis catch cross-file issues. If the request is too large, the CLI splits the files into smaller batches and sends them automatically (which can reduce cross-file context for that run).

**Exit behavior:** exits with code `51` when issues are reported. See [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md).

**Examples:**

```bash
sonar analyze agentic                       # local change set (DEEP)
sonar analyze agentic --file src/app.ts     # single file (STANDARD)
sonar analyze agentic --file src/a.ts --file src/b.ts  # multi-file (DEEP)
sonar analyze agentic --depth DEEP --file src/app.ts  # force DEEP on one file
sonar analyze agentic --staged              # staged files only
sonar analyze agentic --base main           # changes vs main
```

***

### `sonar analyze dependency-risks`

Run Software Composition Analysis (SCA) against the project's dependencies and report unresolved dependency risks (vulnerabilities, malware, and prohibited licenses). Requires SonarQube Advanced Security with SCA enabled on the project (SonarQube Cloud, or SonarQube Server 2026.4 or later). For the full workflow, see [Software Composition Analysis (SCA)](/sonarqube-cli/analysis/sca.md).

**Options:**

| Option            | Type   | Required | Description                                                                                                                                                                                                                                                                                          | Default        |
| ----------------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- |
| `--project`, `-p` | string | No       | Project key (auto-detected when omitted).                                                                                                                                                                                                                                                            | -              |
| `--format`        | string | No       | Output format (`table`, `json`, `toon`); see [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md).                                                                                                                                                                                 | `table`        |
| `--statuses`      | string | No       | Filter by status. Accepts presets (`active` → `NEW,OPEN,CONFIRM`; `to_fix` → `NEW,OPEN,CONFIRM,ACCEPT`; `all` → `NEW,OPEN,CONFIRM,ACCEPT,SAFE,FIXED`) and raw statuses (`NEW`, `OPEN`, `CONFIRM`, `ACCEPT`, `SAFE`, `FIXED`). Comma-separated; case-insensitive; result is the union of every token. | `active`       |
| `--min-severity`  | string | No       | Minimum severity to include (`BLOCKER`, `HIGH`, `MEDIUM`, `LOW`, `INFO`). Risks below the threshold are excluded. Case-insensitive.                                                                                                                                                                  | all severities |

**Exit behavior:** exits with code `51` when unresolved risks are found, `1` on analysis errors, `0` otherwise. See [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md).

> **Note:** **First run downloads scanner binaries.** SonarQube CLI fetches the `sca-scanner-cli` and `sonar-secrets` binaries from `binaries.sonarsource.com` and caches them under `~/.sonar/sonarqube-cli/bin/`. Subsequent runs reuse the cached binaries.

> **Note:** Dependency manifest files (for example, `package-lock.json` or `pom.xml`) are uploaded to SonarQube for analysis. Before the SCA scan, manifest files are pre-scanned for hardcoded secrets; if any are found, the command aborts. See `sonar analyze dependency-risks --help` for the upload notice and [Supported languages and package managers](https://docs.sonarsource.com/sonarqube-server/advanced-security/analyzing-projects-for-dependencies#supported-languages-and-package-managers) in the SonarQube Advanced Security documentation.

**Examples:**

```bash
sonar analyze dependency-risks                                        # auto-detect project, active risks
sonar analyze dependency-risks -p my-project                          # explicit project, table output
sonar analyze dependency-risks -p my-project --format json            # JSON for scripts
sonar analyze dependency-risks -p my-project --format toon            # TOON for AI agents
sonar analyze dependency-risks -p my-project --statuses to_fix        # only what needs fixing
sonar analyze dependency-risks -p my-project --statuses all           # include accepted and safe
sonar analyze dependency-risks -p my-project --min-severity HIGH      # HIGH and BLOCKER only
```

***

### `sonar remediate`

Trigger AI-agent remediation for eligible issues. Eligibility is determined server-side: only issues the [Remediation Agent](/agent-centric-development-cycle/in-your-long-living-branches-the-code-maintenance-loop/remediation-agent.md) can fix are surfaced.

**Options:**

| Option            | Type   | Required | Description                                                                                           | Default |
| ----------------- | ------ | -------- | ----------------------------------------------------------------------------------------------------- | ------- |
| `--project`, `-p` | string | No       | SonarQube Cloud project key (overrides auto-detected project).                                        | -       |
| `--issues`        | string | No       | Comma-separated issue keys to remediate non-interactively (max 20). Required when stdin is not a TTY. | -       |

**Examples:**

Pick issues interactively:

```bash
sonar remediate -p my-project
```

Non-interactively remediate specific issues (suitable for scripts):

```bash
sonar remediate -p my-project --issues issue-key-1,issue-key-2
```

**Exit behavior:** exits with code `0` when your organization is not eligible for or has not enabled the Remediation Agent (the CLI prints an informational message instead of failing). Exits with code `1` on other errors. See [AI remediation](/sonarqube-cli/analysis/ai-remediation.md) and [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md).

***

## Information

### `sonar list issues`

Search for issues in a SonarQube project. By default, only `OPEN` and `CONFIRMED` issues are listed. Pass `--statuses` to include other states such as `FIXED`, `FALSE_POSITIVE`, or `ACCEPTED`. Pass `--new-code` to limit results to issues on new code.

When you omit `--project`, the CLI auto-detects the project key (see [Project key auto-detection](/sonarqube-cli/integrations/integrations.md#project-key-auto-detection)). It prints the chosen key to stderr (`Using auto-detected project key: …`).

When you omit both `--branch` and `--pull-request`, the CLI tries to match your current local git branch to a pull request that SonarQube has already analyzed for the project. If exactly one pull request matches, it lists issues for that pull request and prints `Using pull request <id> (auto-detected from branch <branch>)` to stderr. Otherwise it leaves both options unset (for example, when you're not on a named git branch, no pull request matches, more than one pull request matches the same branch, or the server does not support pull request analysis). The server then applies its own default. Pass `--branch` or `--pull-request` to skip auto-detection.

The lookup uses your existing SonarQube connection. You do not need extra DevOps-platform credentials. Because SonarQube's pull request list does not distinguish open from merged pull requests, a recently merged pull request can still match while its branch exists locally.

**Options:**

| Option            | Type    | Required | Description                                                                                                                                                                                                                  | Default          |
| ----------------- | ------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| `--project`, `-p` | string  | No       | Project key (auto-detected when omitted; see [Project key auto-detection](/sonarqube-cli/integrations/integrations.md#project-key-auto-detection)).                                                                          | -                |
| `--statuses`      | string  | No       | Filter by status (comma-separated list of: `OPEN`, `CONFIRMED`, `FALSE_POSITIVE`, `ACCEPTED`, `FIXED`).                                                                                                                      | `OPEN,CONFIRMED` |
| `--severities`    | string  | No       | Filter by severity. Valid values depend on the connected server's mode—Multi-Quality Rule (MQR) mode: `INFO`, `LOW`, `MEDIUM`, `HIGH`, `BLOCKER`; Standard Experience mode: `INFO`, `MINOR`, `MAJOR`, `CRITICAL`, `BLOCKER`. | -                |
| `--format`        | string  | No       | Output format (`json`, `toon`, `table`, `csv`); see [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md).                                                                                                  | `json`           |
| `--branch`        | string  | No       | Branch name. Cannot be combined with `--pull-request`.                                                                                                                                                                       | -                |
| `--pull-request`  | string  | No       | Pull request ID. Cannot be combined with `--branch`.                                                                                                                                                                         | -                |
| `--file`          | string  | No       | Limit results to one file, or to a directory's own files (not its subdirectories). Pass a full path from the project root, or just a name if it matches only one file or directory.                                          | -                |
| `--new-code`      | boolean | No       | Only show issues on new code.                                                                                                                                                                                                | -                |
| `--page-size`     | number  | No       | Page size (1-500).                                                                                                                                                                                                           | `500`            |
| `--page`          | number  | No       | Page number.                                                                                                                                                                                                                 | `1`              |

> **Note:** `--branch` and `--pull-request` are mutually exclusive. Passing both fails with an invalid-options error (exit code `2`).

When `--file` names a directory, results include issues on files in that directory only, not in nested subdirectories. If a bare name matches more than one file or directory, the command exits with code `2` and asks you to pass the full path from the project root.

**Examples:**

List open and confirmed issues (auto-detects the project key and a pull request for your current git branch when possible):

```bash
sonar list issues
```

List open and confirmed issues in a specific project:

```bash
sonar list issues -p my-project
```

Limit results to one file:

```bash
sonar list issues -p my-project --file src/app.ts
```

Limit results to files in one directory:

```bash
sonar list issues -p my-project --file src/api
```

Include fixed issues:

```bash
sonar list issues -p my-project --statuses FIXED
```

List issues on new code:

```bash
sonar list issues --new-code
sonar list issues -p my-project --new-code
```

Output issues in TOON format for AI agents:

```bash
sonar list issues -p my-project --format toon
```

***

### `sonar list projects`

Search for projects the active token can access.

**Options:**

| Option          | Type   | Required | Description                                                                                                  | Default |
| --------------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------ | ------- |
| `--query`, `-q` | string | No       | Search query to filter projects by name or key.                                                              | -       |
| `--format`      | string | No       | Output format (`json`, `table`). See [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md). | `json`  |
| `--page`        | number | No       | Page number.                                                                                                 | `1`     |
| `--page-size`   | number | No       | Page size (1-500).                                                                                           | `500`   |

The default is JSON: a `projects` array of `key` and `name`, plus `paging` (`pageIndex`, `pageSize`, `total`, and `hasNextPage`). Pipe it through `jq` if you need to transform it. `--format table` prints `KEY` and `NAME` columns for the current page, or `No projects found` when that page is empty. The table does not include paging.

**Examples:**

```bash
sonar list projects
sonar list projects -q my-project
sonar list projects --page 2 --page-size 50
sonar list projects --format table
```

***

### `sonar quality-gate status`

Show the quality gate verdict for a project on SonarQube Cloud or SonarQube Server. The `qg` alias works the same way (for example, `sonar qg status`). Pass an optional file or directory path to show conditions for that path instead of the whole project. By default, only failing conditions are listed; pass `--all` to include passing conditions as well.

When you omit both `--branch` and `--pull-request`, the CLI tries to match your current local git branch to a pull request that SonarQube has already analyzed for the project. If exactly one pull request matches, the command reports that pull request's quality gate. Otherwise it reports the project's default branch (for example, when you are not on a named git branch, no pull request matches, more than one pull request matches the same branch, or the server does not support pull request analysis).

Table output always names the scope that was used, for example `Branch: main (default)` or `Pull Request: 42 (auto-detected from branch feature-x)`. JSON uses `qualityGate.branch` or `qualityGate.pullRequest` for the same scope; auto-detection is not a separate JSON field. Pass `--branch` or `--pull-request` to skip auto-detection.

The lookup uses your existing SonarQube connection. You do not need extra DevOps-platform credentials. Because SonarQube's pull request list does not distinguish open from merged pull requests, a recently merged pull request can still match while its branch exists locally.

When a coverage, duplications, issues, security, or dependency-risks condition fails, the command lists the worst entries for that metric. Coverage conditions are Coverage, Line Coverage, Branch Coverage, and the corresponding new-code metrics. Duplications conditions are Duplicated Lines (%), Duplicated Blocks, Duplicated Files, Duplicated Lines, and the corresponding new-code metrics. Issues conditions cover the Issues, Reliability, and Maintainability domains: Issues, Bugs, Reliability Rating, Code Smells, Maintainability Rating, and the corresponding new-code metrics. Security conditions cover the Security domain: Vulnerabilities, Security Rating, and the corresponding new-code metrics (security hotspots and Security Review ratings are not included). Dependency-risks conditions are Software Composition Analysis (SCA) count, rating, and severity conditions for malware, prohibited licenses, vulnerabilities, and combined any-issue or any-security variants, overall and on new code. By default it includes up to 500 entries per condition (`--top`): files for coverage and duplications, issues for the issues category, vulnerabilities for the security category, or unresolved risks for the dependency-risks category. Files that cannot contribute further (100% coverage, or 0% / 0 duplications) are omitted.

Table output nests those entries under the failing condition. Duplications rows may include a block count and peer files, for example `src/checkout.ts (1 block, dup: src/other.ts)`. Issues and security rows are a flat list of `file:line`, issue key, rule, and message (Reliability conditions list bugs; Maintainability conditions list code smells; the Issues metric lists both; security conditions list vulnerabilities). Dependency-risks rows are a flat list of `package@version`, severity, type, and a vulnerability ID such as a CVE when present. A condition for one risk kind lists only that kind (for example, a vulnerability condition does not include license risks). If more entries exist, it adds a `… N more` line (and may suggest a higher `--top`). JSON attaches a `breakdown` object on that condition with `category` (`coverage`, `duplications`, `issues`, `security`, or `dependency-risks`), `totalCount`, `fetchedCount`, and `entries`. Coverage and duplications entries include `path`, `value`, and `formattedValue`. Duplications entries also include `blockCount` and `duplicatesWith` when that detail is available. Issues and security entries include `file`, `line` (when the issue has a line), `key`, `rule`, and `message`. Dependency-risks entries include `package`, `version`, `severity`, `type`, `key`, and `vulnerabilityId` when present. Passing conditions and conditions outside these categories omit the breakdown. Pass `--category coverage`, `--category duplications`, `--category issues`, `--category security`, or `--category dependency-risks` to attach a breakdown only to failing conditions in that category; other failing conditions still appear without a breakdown. If no failing condition matches `--category`, the CLI warns on stderr and still prints a valid quality gate.

Pass a file or directory path to evaluate conditions against that path's own values. Use a full path from the project root, or a name that matches only one file or directory. A missing or ambiguous path exits with code `2`.

File and directory drill-down covers coverage, duplications, issues, and security. Dependency-risks conditions are not evaluated at this scope. Conditions with no measure for the path are omitted, even with `--all`.

On a file, coverage and duplications show the file's value against the threshold. On a directory, those conditions use the directory's aggregated value and list the worst files in that directory (up to `--top`). Issues and security list issues on the file, or on files in that directory (not nested subdirectories).

On a file, `--category coverage` and `--category duplications` have no nested breakdown. `--category dependency-risks` has none at file or directory scope. The CLI warns on stderr and still prints the conditions.

Table output uses `Quality Gate · <path>`. When no conditions apply, the verdict is `[· Not applicable]` (exit code `0`). When applicable conditions all pass, the table says `All applicable conditions are passing (use --all to show them).` JSON uses `qualityGate.file` instead of `qualityGate.project`, and `qualityGate.status` can be `NOT_APPLICABLE`.

**Arguments:**

| Argument | Description                                                                  |
| -------- | ---------------------------------------------------------------------------- |
| `[file]` | File or directory path to show conditions for, instead of the whole project. |

**Options:**

| Option            | Type    | Required | Description                                                                                                                                         | Default |
| ----------------- | ------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `--project`, `-p` | string  | No       | Project key (auto-detected when omitted; see [Project key auto-detection](/sonarqube-cli/integrations/integrations.md#project-key-auto-detection)). | -       |
| `--format`        | string  | No       | Output format (`json`, `table`); see [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md).                                        | `table` |
| `--branch`        | string  | No       | Branch name. Cannot be combined with `--pull-request`.                                                                                              | -       |
| `--pull-request`  | string  | No       | Pull request ID. Cannot be combined with `--branch`.                                                                                                | -       |
| `--all`           | boolean | No       | Also show passing conditions. By default only failing conditions are shown.                                                                         | -       |
| `--category`      | string  | No       | Only show the breakdown for one category of failing conditions (`coverage`, `duplications`, `issues`, `security`, or `dependency-risks`).           | -       |
| `--top`           | integer | No       | Number of entries to include in the breakdown, per condition (1–500).                                                                               | `500`   |

> **Note:** `--branch` and `--pull-request` are mutually exclusive. Passing both fails with an invalid-options error (exit code `2`). `--category` accepts `coverage`, `duplications`, `issues`, `security`, or `dependency-risks`; other values also fail with exit code `2`. `--top` must be an integer from 1 through 500. A `[file]` argument that does not match exactly one file or directory also fails with exit code `2`.

**Examples:**

Check the quality gate (auto-detects a pull request for your current git branch when possible):

```bash
sonar quality-gate status -p my-project
sonar qg status -p my-project
```

Check a feature branch:

```bash
sonar quality-gate status -p my-project --branch feature-x
```

Check a pull request:

```bash
sonar quality-gate status -p my-project --pull-request 42
```

Check a single file:

```bash
sonar quality-gate status src/checkout.ts -p my-project
```

Check a directory:

```bash
sonar quality-gate status src/checkout -p my-project
```

Output JSON for scripting:

```bash
sonar quality-gate status -p my-project --format json
```

Attach a breakdown only to failing duplications conditions:

```bash
sonar quality-gate status -p my-project --category duplications
```

Attach a breakdown only to failing issues, reliability, and maintainability conditions:

```bash
sonar quality-gate status -p my-project --category issues
```

Attach a breakdown only to failing security conditions:

```bash
sonar quality-gate status -p my-project --category security
```

Attach a breakdown only to failing dependency-risks conditions:

```bash
sonar quality-gate status -p my-project --category dependency-risks
```

**Exit behavior:** exits with code `0` when the quality gate passes (or, for a file or directory, when no conditions apply), `51` when it fails, `2` when a file argument cannot be resolved, and `1` when the verdict cannot be computed (for example, no analysis on the requested branch or pull request) or on other errors. See [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md).

***

### `sonar api`

Make authenticated requests to any SonarQube Web API endpoint. Useful for advanced workflows that are not covered by other commands.

**Arguments:**

| Argument     | Description                                                              |
| ------------ | ------------------------------------------------------------------------ |
| `<method>`   | HTTP method (`get`, `post`, `patch`, `put`, `delete`).                   |
| `<endpoint>` | API endpoint path. Must start with `/` and can contain query parameters. |

**Options:**

| Option            | Type    | Required | Description                                                  | Default |
| ----------------- | ------- | -------- | ------------------------------------------------------------ | ------- |
| `--data`, `-d`    | string  | No       | JSON string for the request body; see Request body encoding. | -       |
| `--verbose`, `-v` | boolean | No       | Print request and response details for debugging.            | -       |

> **Note:** **Request body encoding.** The CLI picks an encoding based on the endpoint path:
>
> * Endpoints starting with `/api/v2/`, or endpoints that do not start with `/api/`, receive a JSON body (`Content-Type: application/json`).
> * All other endpoints (the SonarQube Web API v1, paths under `/api/`) receive URL-encoded form data (`Content-Type: application/x-www-form-urlencoded`).
>
> This matches what each Web API endpoint expects. You do not need to override it.

> **Note:** Both SonarQube Cloud and SonarQube Server expose web API v1 (paths under `/api/`) and v2 (paths under `/api/v2/`) endpoints. The CLI automatically picks the correct host and routing based on the endpoint path you provide.
>
> On SonarQube Cloud, v2 endpoints live on the API host (`api.<domain>`) without the `/api/v2` prefix that SonarQube Server uses. When you connect to SonarQube Cloud and pass a server-style `/api/v2/...` path, the CLI strips that prefix and routes the request to the API host. Paths copied from SonarQube Server documentation work unchanged against SonarQube Cloud (for example, `/api/v2/sca/issues-releases`).
>
> On SonarQube Server, `/api/v2/...` paths are sent as-is.

**Examples:**

List favorite projects:

```bash
sonar api get "/api/favorites/search"
```

Search for rules in an organization:

```bash
sonar api get "/api/rules/search?organization=my-org&languages=ts"
```

Generate a new user token:

```bash
sonar api post "/api/user_tokens/generate" --data '{"name":"my-new-token"}'
```

Accept an issue:

```bash
sonar api post "/api/issues/do_transition" --data '{"issue":"AYx1z2","transition":"accept"}'
```

Debug a request:

```bash
sonar api get "/api/system/status" --verbose
```

Get the current analysis engine JAR info (V2 API):

```bash
sonar api get "/analysis/engine"
```

List SCA issue releases (server-style `/api/v2` path works on SonarQube Cloud too):

```bash
sonar api get "/api/v2/sca/issues-releases?projectKey=my-project"
```

Revoke a user token:

```bash
sonar api post "/api/user_tokens/revoke" --data '{"name":"my-token"}'
```

***

### `sonar context`

Augment AI agents with context from your codebase.

Forwards all arguments to the locally-installed `sonar-context-augmentation` binary. Install the binary first via `sonar integrate claude`, `sonar integrate copilot`, `sonar integrate cursor`, or `sonar integrate codex`. `sonar integrate antigravity` does not install Vortex context. If Vortex context is not installed, the CLI prints an error and points you back to `sonar integrate`. To use Vortex context with Antigravity, set up a [self-hosted MCP server](/sonarqube-mcp-server/setup/quickstart-guides/antigravity.md#set-up-a-self-hosted-mcp-server).

Integrate commands check subscription status, not consumption. If your connection has a Vortex subscription but has reached its consumption limit, the session-start hook and binary are still installed; tool calls through this command may be denied at runtime until usage is available again.

**Arguments:**

| Argument    | Description                                                   |
| ----------- | ------------------------------------------------------------- |
| `[action]`  | Action forwarded to sonar-context-augmentation.               |
| `[args...]` | Additional arguments forwarded to sonar-context-augmentation. |

**Examples:**

```bash
sonar context help
sonar context init
```

***

## Configuration

### `sonar link`

Link the current repository to a SonarQube project by writing `.sonar-config.json` at the repository root. The CLI reads this file first when it auto-detects a project key (see [Project key auto-detection](/sonarqube-cli/integrations/integrations.md#project-key-auto-detection)). When a command cannot determine a project key, it suggests `--project` or this command. You must be authenticated (`sonar auth login` or [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)).

The command supports one project per repository. Monorepo support is coming soon.

Server URL and organization come from the active connection, not from flags. If `.sonar-config.json` already has a `project` entry, the command overwrites it.

**Arguments:**

| Argument       | Description            |
| -------------- | ---------------------- |
| `<projectKey>` | SonarQube project key. |

**Options:**

| Option   | Type   | Required | Description                                                                                                     | Default |
| -------- | ------ | -------- | --------------------------------------------------------------------------------------------------------------- | ------- |
| `--path` | string | No       | Path to the project root, relative to the repository root. Must be an existing directory inside the repository. | `.`     |

**Examples:**

Link the repository root to a project:

```bash
sonar link my-org_my-app
```

Link a subdirectory as the project root:

```bash
sonar link my-org_my-app --path services/api
```

On success, the CLI prints the linked directory and the full path of `.sonar-config.json`. In a git repository, it also tells you to commit the file, which lets teammates share the same binding.

If you run the command outside a git repository, it warns and writes `.sonar-config.json` in the current directory instead.

***

### `sonar config telemetry`

Enable or disable the collection of anonymous usage statistics and crash reports. See [Telemetry and privacy](/sonarqube-cli/administration/telemetry-and-privacy.md) for what's collected.

**Options:**

| Option       | Type    | Required | Description                                       | Default |
| ------------ | ------- | -------- | ------------------------------------------------- | ------- |
| `--enabled`  | boolean | No       | Enable collection of anonymous usage statistics.  | -       |
| `--disabled` | boolean | No       | Disable collection of anonymous usage statistics. | -       |

**Examples:**

```bash
sonar config telemetry --enabled
sonar config telemetry --disabled
```

***

### `sonar config stats`

Enable or disable local stats collection. The record stays on your machine and is never transmitted. It's independent of telemetry and of `DO_NOT_TRACK`. See [Telemetry and privacy](/sonarqube-cli/administration/telemetry-and-privacy.md#local-stats-stay-on-your-machine).

Run the command with no flag to print whether collection is currently enabled. Collection stays enabled until you pass `--disabled`. The `stats` key is written to `state.json` only after you pass `--enabled` or `--disabled`. Pass only one of those flags. The command exits with code 2 if you pass both.

**Options:**

| Option       | Type    | Required | Description                     | Default |
| ------------ | ------- | -------- | ------------------------------- | ------- |
| `--enabled`  | boolean | No       | Enable local stats collection.  | -       |
| `--disabled` | boolean | No       | Disable local stats collection. | -       |

**Examples:**

```bash
sonar config stats
sonar config stats --enabled
sonar config stats --disabled
```

***

## System

System diagnostics and maintenance commands for the SonarQube CLI installation. See [Check system status](/sonarqube-cli/administration/system-status.md) and [Reset the CLI](/sonarqube-cli/administration/system-reset.md) for guides.

### `sonar system status`

Show a diagnostic overview of authentication, resolved network configuration (proxy, custom CA certificate, and client certificate), installed binaries, cache directories, integrations, MCP server health, Antigravity secrets hook health, and Vortex subscription and usage. Does not require authentication. See [Check system status](/sonarqube-cli/administration/system-status.md) for details.

**Options:**

| Option     | Type    | Required | Description                                                                                   | Default |
| ---------- | ------- | -------- | --------------------------------------------------------------------------------------------- | ------- |
| `--format` | string  | No       | Output format (`text`, `json`).                                                               | `text`  |
| `--json`   | boolean | No       | Deprecated since 1.9. Prints the same JSON as `--format json` and writes a warning to stderr. | -       |

> **Note:** `--json` has been deprecated since 1.9 and will be removed in a future version. Use `--format json` instead. Passing `--json` selects JSON even when `--format` is also set.

**Examples:**

```bash
sonar system status
sonar system status --format json
```

***

### `sonar system reset`

Reset the CLI to factory defaults: remove saved tokens, downloaded binaries, `sonar integrate` installs, CLI caches, and the local stats database. Telemetry preferences and the local stats collection preference are preserved. Does not remove the `sonar` binary. See [Reset the CLI](/sonarqube-cli/administration/system-reset.md) for details.

**Options:**

| Option    | Type    | Required | Description                                                      | Default |
| --------- | ------- | -------- | ---------------------------------------------------------------- | ------- |
| `--force` | boolean | No       | Skip the interactive confirmation prompt (required for scripts). | -       |

**Examples:**

```bash
sonar system reset
sonar system reset --force
```

***

## Maintenance

### `sonar update`

Update SonarQube CLI to the latest version. Re-uses the install script that put `sonar` on your system; your saved state and credentials are preserved. After an upgrade, leftover project-scoped agent integrations are migrated to global scope. `sonar update` retries that migration even when the CLI is already up to date. A version check does not. See [Updating the CLI](/sonarqube-cli/administration/self-update.md#migrate-project-scoped-agent-integrations) for details.

`sonar self-update` is a hidden compatibility alias. It has been deprecated since 1.4 and will be removed in a future version. It still runs the same logic but prints a warning; use `sonar update` instead. `sonar self-update --status` still checks without installing.

**Options:**

| Option     | Type    | Required | Description                                                                                                             | Default |
| ---------- | ------- | -------- | ----------------------------------------------------------------------------------------------------------------------- | ------- |
| `--status` | boolean | No       | Deprecated since 1.9. Check for a newer version without installing. Does not migrate integrations or accept `--format`. | -       |
| `--force`  | boolean | No       | Install the latest version even if already up to date.                                                                  | -       |

> **Note:** `--status` has been deprecated since 1.9 and will be removed in a future version. Use [`sonar update status`](#sonar-update-status) instead. The flag still checks without installing and prints a warning.

**Examples:**

```bash
sonar update
sonar update --force
```

***

### `sonar update status`

Check for a newer version without installing. Does not migrate integrations. Standalone builds only. See [Updating the CLI](/sonarqube-cli/administration/self-update.md) for details.

**Options:**

| Option     | Type   | Required | Description                     | Default |
| ---------- | ------ | -------- | ------------------------------- | ------- |
| `--format` | string | No       | Output format (`text`, `json`). | `text`  |

Text output prints `Checking for updates...`, then the installed version and the latest stable version (each with a `v` prefix). The latest version omits any build number. When you're already on that release, the command prints `Already up to date`. When a newer release exists, it prints `Update available` and tells you to run `sonar update`.

`--format json` prints one JSON object on stdout and omits the text summary. `currentVersion` is the installed version, `latestVersion` is the latest stable version without a build number (neither field has a `v` prefix), and `upToDate` is `true` when no newer stable release is available.

**Examples:**

```bash
sonar update status
sonar update status --format json
```

## Related pages <a href="#related-pages" id="related-pages"></a>

* [Environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)
* [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md)
* [Exit codes](/sonarqube-cli/using-sonarqube-cli/exit-codes.md)


---

# 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/using-sonarqube-cli/commands.md?ask=<question>&goal=<user_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.
