> 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`, `org`, `logout`, `status`                                                                                                 |
| **Integrations**   | `sonar import`, `integrate`, `integrate claude`, `copilot`, `codex`, `cursor`, `antigravity`, `opencode`, `devin`, `pi`, `git`                |
| **Analysis**       | `sonar analyze`, `analyze secrets`, `analyze agentic`, `analyze dependency-risks`, `remediate`                                                |
| **Information**    | `sonar list issues`, `list projects`, `list orgs` (alias `list org`), `quality-gate status` (`qg`), `api`, `context`, `architecture` (`arch`) |
| **Configuration**  | `sonar link`, `link list`, `config get`, `config list`, `config set`, `config unset`, `allowlist secrets`                                     |
| **Maintenance**    | `sonar system status`, `system reset`, `update` (install-script copy), `update status`                                                        |

| 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 repositories from your organization's DevOps platform into SonarQube Cloud (Beta).                                                                                                                                                                |
| `sonar list`                  | List issues, projects, and SonarQube Cloud organizations.                                                                                                                                                                                                |
| `sonar quality-gate` (`qg`)   | Fetch quality gate status from SonarQube Cloud or Server.                                                                                                                                                                                                |
| `sonar context`               | Augment AI agents with context from your codebase.                                                                                                                                                                                                       |
| `sonar architecture` (`arch`) | Read and set the architecture of a project. `install-skill` is Beta.                                                                                                                                                                                     |
| `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`, or list the projects around a path.                                                                                                                                                     |
| `sonar config`                | Configure CLI settings.                                                                                                                                                                                                                                  |
| `sonar allowlist`             | Manage local allowlists for SonarQube analyzers.                                                                                                                                                                                                         |
| `sonar system`                | System diagnostics and maintenance (status, reset).                                                                                                                                                                                                      |
| `sonar update`                | Update the install-script copy of SonarQube CLI. Check for a newer version from any install.                                                                                                                                                             |

***

## `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.        | -       |

When you belong to more than one SonarQube Cloud organization and you omit `--org`, each choice shows the same name, key, and status as [`sonar list orgs`](#sonar-list-orgs): `active` for the organization on your current connection (listed first), `Admin` when you administer another organization, or `Member` otherwise.

On SonarQube Cloud, `sonar auth login` accepts an organization only when you are a member of it, the same rule as [`sonar auth status`](#sonar-auth-status). The check covers `--org`, `--with-token`, an organization read from project configuration, and a key you type after you choose **Enter organization key manually**. A public organization is rejected when you are not a member.

Passing an organization you do not belong to with `--org` or `--with-token` fails with exit code `1` and prints `You are not a member of organization '<key>'.` Choose an organization you belong to, then try again. If you belong to no organization, login fails before it shows a list or asks for a key. The message is `You are not a member of any organization.` Join a SonarQube Cloud organization, then try again. When browser login fails the membership check, the CLI revokes the token it just created. `--with-token` does not save the supplied token and does not revoke it on the server.

When you omit `--org`, login uses an organization from project configuration when you are a member. If you are not a member, it warns `You are not a member of organization '<key>' from project config.` and continues with your memberships. It selects the only organization you belong to, or prompts you when you belong to several. In a terminal, a typed key you do not belong to is asked again. When standard input is not a terminal, login stops on the first rejection. If SonarQube Cloud cannot confirm membership, login stops and prints `Could not verify organization '<key>'.` Check your network connection and the server status, then try again.

**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, a username or password in the URL, and any value that contains a control character, such as a line break or a tab. A saved SonarQube Cloud connection must use the host `sonarcloud.io` or `sonarqube.us`. If a saved Cloud host is not recognized, the error names `sonarcloud.io` and `sonarqube.us`. 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`.

Browser login reuses a saved token only when a connection is already recorded for the same server and the keychain still has that token. The same server means the same scheme, host, port, and base path. The organization is not compared. A trailing slash does not count as a different URL. The CLI then prints `Token already exists for:` followed by the server, then `You are already authenticated`. A different scheme, port, or base path starts a new browser login, even when that host already has a saved token. Environment-variable authentication does not record a connection, so it does not change this check. The keychain account is the hostname, so signing in to another URL on that host replaces the shared token. See [Where tokens are stored](/sonarqube-cli/administration/state-and-storage.md#where-tokens-are-stored).

When you pass `--org` and login reuses that saved token, it also prints `The stored token was reused. Next time, run 'sonar auth org <org>' to switch organization without logging in again.` A login that omits `--org`, and a login that creates a new token, do not print that hint. See [`sonar auth org`](#sonar-auth-org).

When you sign in again to the same server with a different token, the CLI tries to revoke the previous token on the server if it stored that token's name. The organization is not compared. A URL that differs only by a trailing slash is the same server. Login continues either way. A warning appears when the revoke fails. If the previous token was imported with `--with-token`, it has no stored name, so the CLI cannot revoke it on the server. A revoked token stops working in every tool that uses it.

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. When `sonar-project.properties` sets `sonar.projectKey` and `sonar.organization` and omits `sonar.host.url`, the CLI uses SonarQube Cloud. `sonar.region` `US` selects `https://sonarqube.us`. Any other region, or no region, selects `https://sonarcloud.io`. When several projects in `.sonar-config.json` match your directory, login uses their server only when they all name the same server and organization. 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 org`

Switch the active SonarQube Cloud organization without logging in again. The saved token stays in the keychain, and [`sonar auth logout`](#sonar-auth-logout) can still revoke a token that browser login created. The new organization stays active across terminal sessions until the next switch or logout. The command updates the saved connection in `state.json` only. It does not rewrite files that [`sonar integrate`](#sonar-integrate) already installed.

**Arguments:**

| Argument | Type   | Required | Description                                                                                                                                                                                                                                                                                                                        | Default |
| -------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `[org]`  | string | No       | SonarQube Cloud organization key. When you omit it and you belong to exactly one organization, the CLI selects that organization. When you belong to more than one, it prompts you to choose. Each choice shows the same name, key, and status as [`sonar list orgs`](#sonar-list-orgs), plus **Enter organization key manually**. | -       |

Pass a key to switch directly. The CLI checks that your token belongs to that organization before it changes the connection. When the organization is already active, the command prints `Already using organization: <key>` and exits `0`. A successful switch prints `Switched to organization: <key>` and exits `0`.

The command fails with exit code `1` and leaves the active organization unchanged in these cases:

* You are not logged in. Run `sonar auth login`.
* Environment-variable authentication is already active. Set `SONARQUBE_CLI_ORG` to the organization you want. Those variables override the saved connection, so a switch has no effect while they are set.
* The active connection is SonarQube Server. The message is `Organizations are only applicable to SonarQube Cloud connection.`
* You are not a member of the organization you named. A missing organization produces the same result. The message is `You are not a member of organization '<key>'.`
* The CLI cannot verify membership. The message starts with `Could not verify organization '<key>':`.
* The CLI cannot list your organizations. The message starts with `Could not list your organizations:`.
* You belong to no organization. The message is `You are not a member of any organization.`

For a membership or listing failure, check your network connection and SonarQube Cloud, then try again. This command does not read an organization from project configuration. Use the argument, or answer the prompt.

**Examples:**

```bash
sonar auth org
sonar auth org <YourOrganizationKey>
```

***

### `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 login. If you authenticate only with [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md) and have no saved login, the command reports that you are already logged out and does not delete a keychain entry. Unset `SONARQUBE_CLI_TOKEN` and its companion variables to stop using environment credentials. A connection created by `sonar auth login` stays in place when those variables are set, and logout still removes that saved token while the variables are in use. If the keychain cannot be read or updated during logout, the CLI still removes the saved connection and prints a warning. Delete the remaining keychain entry yourself when the warning says the local token could not be deleted.

**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.

On SonarQube Cloud, a valid token can still lack membership in the configured organization. Text output prints that the token resolves no membership for that organization and that the organization is not accessible with this token, then the command fails with exit code `1`. Ask an organization administrator to add your account, or check which account the token was created with. The hint tells you to verify your account and organization access, then run `sonar auth status` again. `--format json` reports `status` `organization_inaccessible` (with `server`, `org`, and `source`) and exits `1`. The same text and JSON results apply to a saved token and to environment-variable credentials.

If the membership check itself fails, text output prints that organization membership could not be verified, then the command fails with exit code `1`. Check network connectivity and SonarQube Cloud availability, then run `sonar auth status` again. `--format json` reports `status` `organization_membership_unverified` (with `server`, `org`, `source`, and `message`) and exits `1`.

When text output reports that you are connected, the CLI compares that connection with the project in the current directory. The same server means the same scheme, host, port, and base path. A trailing slash does not make the URL different. The organization is not compared. If the project records a different server, text output adds a warning titled **This project expects a different connection**, even when that host already has a saved token. `sonar context` does not use your current credentials for the other URL. The warning names the recorded server and organization. Point your credentials at the recorded connection, or run `sonar integrate` from the project so it records the connection you are authenticated with. The CLI omits the warning when the server matches, including when only the organization differs, when you are not in a linked project, when project discovery fails, and when you pass `--format json`. The command still exits `0`.

`--format json` prints one JSON object on stdout and omits the text summary, spinner, remediation hint, and project-connection warning. 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`, `unreachable`, `organization_inaccessible`, or `organization_membership_unverified`. 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. `organization_membership_unverified` includes `message` with the reason the membership check failed.

**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. When Claude Code is detected with Cursor, Copilot, or Devin, it prints one note that names every detected agent in those pairs and states that they may conflict at the hook level, 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 opencode`

Set up the SonarQube integration for OpenCode 2.0. Installs a secrets-scanning plugin at `~/.config/opencode/plugins/sonar-secrets.ts` and the SonarQube MCP Server in `~/.config/opencode/opencode.json`. A read of a file or folder that contains a secret is blocked. Secrets in a message are masked, a `[Sonar]` notice is added, and the message is still sent. 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). Vortex analysis is a plugin on each `edit` or `write`, plus end-of-turn instructions in `~/.config/opencode/AGENTS.md`. Vortex context is a skill at `~/.config/opencode/skills/sonar-context-augmentation/SKILL.md` and instructions in that same file. In a repository with several SonarQube projects, those instructions say to run `sonar context` from inside one project's directory. OpenCode has no session-start hook. If `opencode --version` reports a version before 2.0, the command still finishes setup and prints one warning that the plugins stay inactive until you upgrade to OpenCode 2.0. It does not ask you to run the command again. Choose OpenCode from the bare `sonar integrate` menu, or run the subcommand directly. See [OpenCode](/sonarqube-cli/integrations/opencode.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 opencode
sonar integrate opencode --non-interactive
```

***

### `sonar integrate devin`

Set up the SonarQube integration for Devin. Installs a `PreToolUse` secrets hook on `read`, a `UserPromptSubmit` secrets hook, secrets-on-read instructions, and MCP configuration in `~/.config/devin` on macOS and Linux, or `%APPDATA%\devin` on Windows. 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). Vortex analysis is a `PostToolUse` hook on `edit` and `write`, plus end-of-turn instructions in `AGENTS.md`. Vortex context is a `SessionStart` hook, plus a `PreToolUse` hook on `run_subagent` that prepends the context announcement to the subagent task. Choose Devin from the bare `sonar integrate` menu, or run the subcommand directly. When Claude Code and Devin are both detected, the bare command includes them in one note that names every detected agent in a conflicting pair and states that they may conflict at the hook level. See [Devin](/sonarqube-cli/integrations/devin.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 devin
sonar integrate devin --non-interactive
```

***

### `sonar integrate pi`

Set up the SonarQube integration for Pi. Installs a secrets-scanning extension at `~/.pi/agent/extensions/sonar-secrets.ts` and the SonarQube MCP Server in `~/.pi/agent/mcp.json`. File reads that contain secrets are blocked. Secrets in a message are masked, and the message is still sent. 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). Vortex analysis is an extension on each `edit` or `write`, plus an end-of-turn reminder to run `DEEP` analysis. Vortex context is a session-start extension that injects context once per session. Pi does not write a skill file or an `AGENTS.md` snippet. Choose Pi from the bare `sonar integrate` menu, or run the subcommand directly. See [Pi](/sonarqube-cli/integrations/pi.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 pi
sonar integrate pi --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. A native or Husky pre-push hook reads those commits from git, so your working tree does not change the result. 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 shows the recommended hooks, then asks you to install them or customize the selection. 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 the commits being pushed).                                                                         | -       |
| `--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 DevOps platform bound to the 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. It lists repositories from the DevOps platform bound to that organization, including GitHub, GitLab, Azure DevOps, and Bitbucket.

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) inside the current directory instead of the git change set (repeatable). A path outside the projects in scope fails Vortex analysis. | -       |
| `--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. When you omit `--project`, Vortex analysis assigns each file to the project that owns it. See [Files and the project root](/sonarqube-cli/analysis/analyzing-local-changes.md#files-and-the-project-root).

**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 (annual) 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) inside the current directory instead of the git change set (repeatable). A path outside the projects in scope fails the command. | -       |
| `--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).
> * Within one project, Vortex analysis sends that project's files in one request, so a `DEEP` analysis can catch cross-file issues. Files that belong to several projects are sent as one request per project. If a request is too large, the CLI splits that project's files into smaller batches (which can reduce cross-file context for that project).
> * When you omit `--project`, each file goes to the project that owns it. From the repository root, one command covers every linked project under that directory. A `--file` path outside the current directory, or outside the projects in scope, fails with exit code `2`. A change-set file that the active connection leaves out is ignored. See [Files and the project root](/sonarqube-cli/analysis/analyzing-local-changes.md#files-and-the-project-root).

**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 newer). 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).

When you omit `--project`, the CLI uses the one project that covers the current directory and scans that project's root. It prints `Using auto-detected project key: …` to stderr. With `.sonar-config.json`, a directory that several projects cover, or that none of them cover, exits with code `1`. Run the command from one project's directory, or pass `--project`. An explicit key scans the root of the linked project with that key, including from the repository root, and prints `Using project key: …`. A key that is not linked scans the current directory.

On SonarQube Cloud, when your connection includes an organization, the CLI checks that the project belongs to that organization before it checks SCA availability or scans. A project in the active organization continues as usual. When the project belongs to a different organization, the command exits with code `1`. The message is `Project '<project>' belongs to organization '<organization>', but the active organization is '<active>'.` The hint is `Run 'sonar auth org <organization>' to switch to that organization.` When the project cannot be found, is not accessible, or the lookup is forbidden, the command exits with code `1`. The message is `Project '<project>' could not be found or is not accessible.` The hint is `Run 'sonar list org' to check your organization membership.` SonarQube Server, and a Cloud connection with no organization, skip this check. Any other lookup failure, including a server or network error, also stops the command before the scan.

> **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).

On SonarQube Cloud, when your connection includes an organization, the CLI checks that the project belongs to that organization before it checks eligibility or submits a job. The messages match [`sonar analyze dependency-risks`](#sonar-analyze-dependency-risks): a different organization names that organization and tells you to run `sonar auth org <organization>`, and a missing or inaccessible project tells you to run `sonar list org`. Both exit with code `1`. SonarQube Server skips this check.

***

## 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: …`).

On SonarQube Cloud, when your connection includes an organization, the CLI checks that the project belongs to that organization before it searches for issues. A project in the active organization continues as usual, including an empty result, which still exits with code `0`. When the project belongs to a different organization, the command exits with code `1` and does not print an issue list. The message is `Project '<project>' belongs to organization '<organization>', but the active organization is '<active>'.` The hint is `Run 'sonar auth org <organization>' to switch to that organization.` When the project cannot be found, is not accessible, or the lookup is forbidden, the command exits with code `1` and does not print an issue list. The message is `Project '<project>' could not be found or is not accessible.` The hint is `Run 'sonar list org' to check your organization membership.` SonarQube Server, and a Cloud connection with no organization, skip this check. Any other lookup failure, including a server or network error, also stops the command before it prints an issue list. [`sonar analyze dependency-risks`](#sonar-analyze-dependency-risks) and [`sonar remediate`](#sonar-remediate) use the same check.

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 to 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 to 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 list orgs`

List the SonarQube Cloud organizations you can access. `sonar list org` is an alias and prints the same list. To switch the organization on the saved connection, run [`sonar auth org`](#sonar-auth-org). Listing organizations does not change the active one.

On SonarQube Server, the command fails with exit code `1` and prints `Organizations are only applicable to SonarQube Cloud connection.` When you are not authenticated, it fails with exit code `1` and tells you to run `sonar auth login`.

**Options:**

| Option        | Type   | Required | Description                                                                                                  | Default |
| ------------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------ | ------- |
| `--format`    | string | No       | Output format (`json`, `table`). See [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md). | `table` |
| `--page`      | number | No       | Page number.                                                                                                 | `1`     |
| `--page-size` | number | No       | Page size (1 to 500).                                                                                        | `500`   |

The default is a table with no header row: name, key, and status. The organization on your active connection is listed first and marked `active`, even when you're also an admin of it. Each other organization is `Admin` when you're an admin of it, and `Member` otherwise. An empty page prints `No organizations found`. The table does not include paging.

`--format json` prints an `organizations` array (`key`, `name`, `isAdmin`, and `isActive`) plus `paging` (`pageIndex`, `pageSize`, `total`, and `hasNextPage`). JSON keeps the server's order. Only the table moves the active organization to the first row. `isActive` is `true` for the organization key on your active connection. `isAdmin` is `true` when you're an admin of that organization.

`--page` must be an integer of `1` or greater. `--page-size` must be an integer from `1` through `500`. Any other value fails with exit code `2`. An unknown `--format` also fails with exit code `2`.

**Examples:**

```bash
sonar list orgs
sonar list org
sonar list orgs --format json
sonar list orgs --page 2 --page-size 50
```

***

### `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 checks your current local git branch and picks the scope in this order:

1. If SonarQube has already analyzed exactly one pull request that matches the branch, the command reports that pull request's quality gate.
2. If no single pull request matches, but the project has analysis for your current branch and that branch is not the project's default branch, the command reports that branch.
3. In all other cases, the command reports the project's default branch. This happens when you are not on a named git branch, you have the default branch checked out, the branch has no analysis, or more than one pull request matches a branch that has no analysis of its own.

Table output always names the scope that was used, for example `Branch: main (default)`, `Branch: feature-x (auto-detected from the current git branch)`, 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 to 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 or an analyzed branch 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.

**Output:**

A successful request prints the response body to stdout.

A failed HTTP response exits with code `1`, leaves stdout empty, and prints `SonarQube API error: <status> <status text> - <response body>` to stderr. The CLI prints the response body as the server returned it and does not parse it as JSON. When the body is empty, that message omits the separator and the body.

On HTTP 429, the CLI also prints `Wait a moment and try again.` On HTTP 503, it also prints `Check your network connection and try again later.`

**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`, `sonar integrate codex`, `sonar integrate opencode`, `sonar integrate devin`, or `sonar integrate pi`. `sonar integrate antigravity` does not install Vortex context. If Vortex context is not installed, `sonar context` 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).

`sonar context` uses your current credentials when the recorded server matches the active connection. The same server means the same scheme, host, port, and base path. A trailing slash does not make the URL different. The organization is not compared, and the command does not look up a separate stored token.

When the recorded server is different, the command does not read a saved token, including a token saved for the same host. It fails with `Not authenticated for the recorded Vortex Context connection` and names the recorded server. If you authenticate with environment variables, the message says those credentials point at the active server. Set `SONARQUBE_CLI_SERVER` to the recorded server and a matching `SONARQUBE_CLI_TOKEN`. When the project records an organization, also set `SONARQUBE_CLI_ORG` to that key. You can instead unset `SONARQUBE_CLI_TOKEN`, `SONARQUBE_CLI_SERVER`, and `SONARQUBE_CLI_ORG`, then run `sonar auth login --server` for the recorded server. If you authenticate with a saved login, run `sonar auth login --server` for the recorded server first.

When `.sonar-config.json` links projects, `sonar context` uses the one project that covers your current directory. A project covers the directory when it is at that directory, under it, or encloses it. Run the command from a directory that belongs to exactly one project.

If that file is present and the directory is not covered by exactly one project, a command that needs a project exits `1` and does not start Vortex context. The message is `Could not determine a single SonarQube project for <path>.` The hint names one of these cases:

* Several projects are linked at or under the directory. Run [`sonar link list --path <path>`](#sonar-link-list) for the file or directory you want. When one project matches, run `sonar context` again from a directory that belongs only to that project. A directory that contains another linked project, including the outer project's own directory, is still more than one project.
* The directory is inside two or more nested projects. Nested project directories are not supported yet. Run `sonar link list`, then work from a directory that belongs to only one project.
* The directory is not inside any project linked in `.sonar-config.json`. Run `sonar link list` from the repository root to see where the projects are.

`sonar context` has no `--path` option. Change to the project's directory instead. Help and version still run without a single project. That includes `sonar context` with no action, `--help`, `-h`, `--version`, `-V`, and any command that includes `--help` or `-h`. `sonar context tool` also runs. Session start in a multi-project directory is described in [Vortex context in a monorepo](/sonarqube-cli/integrations/integrations.md#vortex-context-in-a-monorepo).

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
```

***

### `sonar architecture`

Read and set the architecture of a project. `arch` is an alias, so `sonar arch` runs the same command. Root help lists it as `architecture|arch`. Authenticate first (`sonar auth login` or [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)).

The command uses SonarQube's public Architecture API. When SonarQube refuses access, the CLI says that architecture needs SonarQube Cloud Team or Enterprise, or the Architecture feature on SonarQube Server. A refused change also says that changing the architecture needs the Administer Architecture permission on the project.

If the CLI cannot determine a project key, it exits `1` with `Could not determine project key.` Pass `-p` or `--project`, run the command from a linked project directory, or run [`sonar link`](#sonar-link).

On SonarQube Cloud, these commands use the organization on your connection and the project's analyzed main branch. A connection with no organization fails with `No SonarQube Cloud organization is configured.` and tells you to run `sonar auth login --org <org>`. A project with no analyzed main branch fails with `Project '<project>' has no analyzed main branch.` and tells you to analyze the main branch first. On SonarQube Server, `current get` uses that main branch. `intended get` and `intended set` fail with `Intended architecture is not available yet on SonarQube Server`, because the public API needs a project UUID the CLI cannot discover yet.

#### `sonar architecture current get`

Print the current architecture. Across languages, the response includes at most 150 nodes, 20 dependencies, and 5 feedback pairs. When the slice is larger, the output says what was omitted and prints drill-down commands that pass `--component`.

When SonarQube returns no current architecture, the CLI warns `No current architecture was returned for '<project>'.` That warning does not say whether analysis is missing or architecture data is unavailable.

**Options:**

| Option          | Type    | Required | Description                                                                                           | Default                                |
| --------------- | ------- | -------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------- |
| `-p, --project` | string  | No       | Project key                                                                                           | Auto-detected                          |
| `--component`   | string  | No       | Node key to start below, copied from a previous `current get`                                         | Top level                              |
| `--depth`       | integer | No       | Levels below the start node. Must be an integer of 1 or greater                                       | `1`                                    |
| `--language`    | string  | No       | Limit the read to `java`, `cs`, `js`, `ts`, or `py`                                                   | All languages                          |
| `--format`      | string  | No       | `text`, `toon`, or `json`. See [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md) | `text` on a terminal, otherwise `toon` |

#### `sonar architecture intended get`

Print the intended architecture. Save `--format json` without `--component` or `--depth` when you need a file for [`intended set`](#sonar-architecture-intended-set). `--component` and `--depth` print a partial view, and `intended set` rejects that file. `--language` exports only that language and keeps a language scope on the file. When you set that file with `intended set`, the other languages stay as saved. Omit `--language` when the file is for MCP `architecture_set`, which does not accept a language scope.

When nothing is saved, the CLI warns `No intended architecture yet for '<project>'.`

**Options:**

| Option          | Type    | Required | Description                                                                                           | Default                                |
| --------------- | ------- | -------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------- |
| `-p, --project` | string  | No       | Project key                                                                                           | Auto-detected                          |
| `--component`   | string  | No       | Group key to start below, such as `Domain/Billing`                                                    | All groups                             |
| `--depth`       | integer | No       | Levels of groups below the start group. Must be an integer of 1 or greater                            | All levels                             |
| `--language`    | string  | No       | Limit the export to `java`, `cs`, `js`, `ts`, or `py`                                                 | All languages                          |
| `--format`      | string  | No       | `text`, `toon`, or `json`. See [Output formats](/sonarqube-cli/using-sonarqube-cli/output-formats.md) | `text` on a terminal, otherwise `toon` |

#### `sonar architecture intended set`

Replace the intended architecture with a JSON file shaped like `intended get --format json`. The write replaces the complete model, so omitted content is removed. A file that names one language leaves the other languages as saved. An empty `models` array on a full export clears the intended architecture. Removing the last remaining language from a single-language file clears it too.

`--dry-run` validates the file and prints the diff, removals first, without writing. The CLI then prints `Dry run: nothing was written.`

A file that already matches prints that nothing was written. Creating a model prints `Created`. Replacing an existing model prints `Updated` and saves the previous export under `~/.sonar/sonarqube-cli/architecture/backups/`. Clearing prints `Cleared` and saves the same kind of backup. The success message includes the backup path. SonarQube applies the change from the next analysis. A failed write is not rolled back. The error names the backup and the `intended set --file` command that restores it. [`sonar system reset`](#sonar-system-reset) does not delete these backups.

A file exported with `--component` or `--depth` fails with `The file is a partial view; nothing was changed.` Export again without those flags.

When the file includes a revision and SonarQube has changed since that read, nothing is written. The message is `The intended architecture of '<project>' changed since the file was read; nothing was changed.` Run `intended get --format json` again and reapply your edits. A file with no revision still writes, and the CLI warns that it could not detect changes made in SonarQube since the file was written.

**Options:**

| Option          | Type    | Required | Description                                                  | Default       |
| --------------- | ------- | -------- | ------------------------------------------------------------ | ------------- |
| `--file`        | string  | Yes      | Intended architecture JSON file                              | -             |
| `--dry-run`     | boolean | No       | Validate and print the diff, removals first, without writing | -             |
| `-p, --project` | string  | No       | Project key                                                  | Auto-detected |

#### `sonar architecture install-skill`

Install the architecture skill for Claude Code and Cursor. This command is Beta: root help shows a `[BETA]` tag on `install-skill`. 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).

In a git repository, the command writes `<git-root>/.claude/skills/sonar-architecture/SKILL.md` and `<git-root>/.agents/skills/sonar-architecture/SKILL.md`. Outside a git repository, the current directory is the root. `--global` writes those same paths under your home directory.

The skill reads architecture data and applies intended-model edits you specify. It does not cover architectural diagnosis, model design, recommendations, or code navigation. It tells the agent to start from `sonar architecture --help`.

The command refuses to replace a `SKILL.md` it did not write unless you pass `--force`. A file that already matches prints `Already up to date: <path>`. A new or replaced file prints `Installed <path>`. The skill is not recorded as an integration, so [`sonar system reset`](#sonar-system-reset) leaves the files in place.

**Options:**

| Option     | Type    | Required | Description                                                 | Default    |
| ---------- | ------- | -------- | ----------------------------------------------------------- | ---------- |
| `--global` | boolean | No       | Install under your home directory instead of the repository | Repository |
| `--force`  | boolean | No       | Replace a `SKILL.md` that this command did not write        | -          |

**Examples:**

```bash
sonar architecture current get
sonar arch current get --project my-project --language java --depth 2
sonar architecture intended get --format json > intended.json
sonar architecture intended set --file intended.json --dry-run
sonar architecture intended set --file intended.json
sonar architecture install-skill
sonar architecture install-skill --global
```

***

## 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)).

List the projects around a path with [`sonar link list`](#sonar-link-list). That command prints JSON and does not change the file.

Without `--monorepo`, the command writes one `project` entry. Linking again replaces that entry and leaves every other field, including `projects`. When `projects` is already present, the CLI still saves the `project` entry, then warns that the array takes precedence and the new link is ignored. It exits `0` and does not print the success summary. The warning tells you to run `sonar link --monorepo`.

Use `--monorepo` to add or update one directory in the `projects` array. The command leaves an existing `project` entry in place. When both are present, the CLI uses `projects` and ignores `project`. Link that earlier directory with `--monorepo` if you still want it. Linking the same directory again replaces that mapping and keeps the others. A path such as `./services/api/` is stored as `services/api`. The success line ends with `(monorepo mapping)`. If `projects` is present but is not an array, the command fails and leaves the file unchanged.

Server URL and organization come from the active connection, not from flags. On `https://sonarcloud.io` and `https://sonarqube.us`, the file stores `region` (`eu` or `us`) and `organization`. On a non-default port, it stores `serverUrl` and `organization` instead, so the CLI keeps that host. Paths are relative to the repository root. Outside a git repository, they are relative to the current directory.

**Arguments:**

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

**Options:**

| Option       | Type    | Required | Description                                                                                                     | Default |
| ------------ | ------- | -------- | --------------------------------------------------------------------------------------------------------------- | ------- |
| `--monorepo` | boolean | No       | Add or update this directory in the `projects` array instead of replacing the single `project` link.            | -       |
| `--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
```

Link several directories in one repository:

```bash
sonar link api_project --monorepo --path services/api
sonar link web_project --monorepo --path services/web
```

On success, the CLI prints the linked directory and the full path of `.sonar-config.json`. A `--monorepo` link adds `(monorepo mapping)` to that line. In a git repository, it also tells you to commit the file, which lets teammates share the same binding. The ignored single-project write described above does not print this summary.

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

***

### `sonar link list`

List the SonarQube projects at, under, or enclosing a file or directory. The command prints JSON and does not change `.sonar-config.json`. Use it when the file links many projects and you need the ones around one path. You must be authenticated (`sonar auth login` or [environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)).

`--path` is an existing file or directory. The default is the current directory. When you pass a file, discovery starts in that file's directory, and the list is scoped to the file.

The CLI discovers projects the same way as other commands, starting from that directory (see [Project key auto-detection](/sonarqube-cli/integrations/integrations.md#project-key-auto-detection)). It keeps projects at the path, projects under it, and projects that enclose it. Other projects are left out. The closest projects come first. When two projects are the same distance from the path, they're ordered by `projectRoot`.

`contains` is `true` when the project root is the path or encloses it. It's `false` when the project sits under the path.

`--pattern` is a case-insensitive regular expression. A project matches when the pattern matches its key, or its directory relative to the repository root. Outside a git repository, that directory is relative to the current directory. Passing `--path` does not change this base. Directories in the match use `/`. The pattern is not matched against the absolute path.

The command prints one JSON object. There's no `--format` option. `projects` lists the current page. Each entry has `projectRoot` (the absolute linked directory), `projectKey`, `serverUrl`, and `contains`. `organization` is present when the stored link has one. SonarQube Cloud links include it, and SonarQube Server links omit it. `paging` has `pageIndex`, `pageSize`, `total`, and `hasNextPage`. `total` counts every match, not only this page.

`--page` defaults to `1` and must be an integer of `1` or greater. `--page-size` defaults to `20` and must be an integer from `1` through `100`. A path with no matches prints an empty `projects` array and exits `0`. A missing `--path`, an invalid `--pattern`, or a page value outside those limits fails with exit code `2`.

**Options:**

| Option        | Type   | Required | Description                                                                   | Default           |
| ------------- | ------ | -------- | ----------------------------------------------------------------------------- | ----------------- |
| `--path`      | string | No       | Existing file or directory to list projects for.                              | Current directory |
| `--pattern`   | string | No       | Case-insensitive regular expression on the project key or relative directory. | -                 |
| `--page`      | number | No       | Page number.                                                                  | `1`               |
| `--page-size` | number | No       | Page size (1 to 100).                                                         | `20`              |

**Examples:**

```bash
sonar link list
sonar link list --path services/api
sonar link list --path services/api/src/index.ts
sonar link list --pattern "^services/"
sonar link list --page 2 --page-size 20
```

A SonarQube Cloud project that encloses `services/api`:

```json
{
  "projects": [
    {
      "projectRoot": "/path/to/repo/services/api",
      "projectKey": "my-org_api",
      "serverUrl": "https://sonarcloud.io",
      "organization": "my-org",
      "contains": true
    }
  ],
  "paging": {
    "pageIndex": 1,
    "pageSize": 20,
    "total": 1,
    "hasNextPage": false
  }
}
```

***

### `sonar config get`

Print the value stored for one known SonarQube CLI configuration key. Does not require authentication.

Store a value with [`sonar config set`](#sonar-config-set). Remove it with [`sonar config unset`](#sonar-config-unset). List every key with [`sonar config list`](#sonar-config-list).

An unknown key fails with exit code `1`. The message starts with `error: command-argument value '<key>' is invalid for argument 'key'. Allowed choices are` and then lists the known keys.

Text output is the default. It shows the stored value for a non-sensitive key, `***` for a sensitive key that is set (the real value stays hidden), and `(not set)` when nothing is stored for that key.

A terminal prints `***` and `(not set)` in gray. Piped output keeps the same text without color.

`--format json` prints one JSON object on stdout. `key` is the key you passed. `sensitive` is `true` or `false`. `set` is `true` when a value is stored, and `false` when nothing is stored. `value` is included only for a non-sensitive key that is set. A sensitive key omits `value`.

Non-sensitive values are read from `~/.sonar/sonarqube-cli/cli-config.properties`. Sensitive values are read from the OS keychain. See [State and storage](/sonarqube-cli/administration/state-and-storage.md). `sonar system reset --all` removes that file and those keychain entries. See [Reset the CLI](/sonarqube-cli/administration/system-reset.md).

A stored `telemetry.enabled` or `stats.enabled` is the preference the CLI applies. When the key is not set, that collection stays enabled, and text output prints `(not set)`. That is not the same as `false`. Set `DO_NOT_TRACK=1` to turn telemetry and crash reporting off for the current process without changing the stored value. That variable does not change local stats collection. The CLI applies a stored `network.*` key when no higher-priority source overrides it. A `SONAR_*` environment variable overrides that stored key. For proxy and CA certificate settings, the stored key overrides the generic environment variable. See [Advanced network configuration](/sonarqube-cli/administration/advanced-network-configuration.md). Stored `mcp.container.network`, `mcp.container.addHost`, `mcp.container.serverUrl`, and `mcp.container.autoNetwork` apply when the CLI starts the MCP container for SonarQube Server or SonarQube Community Build. SonarQube Cloud ignores them. When `mcp.container.autoNetwork` is not set, automatic routing stays off. See [Reach a SonarQube Server on the same machine](/sonarqube-cli/administration/advanced-network-configuration.md#reach-a-sonarqube-server-on-the-same-machine). A stored `log.level` sets the file log level at startup unless `LOG_LEVEL` overrides it. See [Environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md#logging). `sonar config get` prints the stored entry, which can differ from the value in effect.

**Arguments:**

| Argument | Description                                                         |
| -------- | ------------------------------------------------------------------- |
| `<key>`  | Config key to read. Run `sonar config list` to see every valid key. |

**Options:**

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

**Keys:**

| Key                            | When set, text output |
| ------------------------------ | --------------------- |
| `network.proxy.https`          | `***`                 |
| `network.proxy.http`           | `***`                 |
| `network.tls.clientPassphrase` | `***`                 |
| `network.proxy.noProxy`        | Stored value          |
| `network.tls.caCert`           | Stored value          |
| `network.tls.clientCert`       | Stored value          |
| `network.tls.clientKey`        | Stored value          |
| `log.level`                    | Stored value          |
| `telemetry.enabled`            | Stored value          |
| `stats.enabled`                | Stored value          |
| `mcp.container.network`        | Stored value          |
| `mcp.container.addHost`        | Stored value          |
| `mcp.container.serverUrl`      | Stored value          |
| `mcp.container.autoNetwork`    | Stored value          |

**Examples:**

```bash
sonar config get log.level
sonar config get log.level --format json
sonar config get network.tls.clientPassphrase
```

Output when `log.level` has no stored value (`--format json`):

```json
{
  "key": "log.level",
  "sensitive": false,
  "set": false
}
```

A stored sensitive key with `--format json`:

```json
{
  "key": "network.tls.clientPassphrase",
  "sensitive": true,
  "set": true
}
```

***

### `sonar config list`

Print every known SonarQube CLI configuration key and the value stored for it. Does not require authentication.

Store a value with [`sonar config set`](#sonar-config-set). Read one key with [`sonar config get`](#sonar-config-get). Remove a value with [`sonar config unset`](#sonar-config-unset).

The command prints the stored entry, which can differ from the value in effect. See [`sonar config get`](#sonar-config-get).

Text output is the default. Each line is `<key>=<value>`. The value is the stored value for a non-sensitive key, `***` for a sensitive key that is set (the real value stays hidden), or `(not set)` when nothing is stored for that key.

A terminal prints `***` and `(not set)` in gray. Piped output keeps the same text without color.

`--format table` prints a `KEY` and `VALUE` table with those same values.

`--format json` prints a JSON array on stdout. Each object has `key`, `sensitive` (`true` or `false`), and `set` (`true` when a value is stored). `value` is included only for a non-sensitive key that is set. A sensitive key omits `value`.

`--only-set` limits the output to keys that currently have a value. When no key is set, text and table output print `No config values are set.` JSON prints `[]`.

`--help` lists every key, whether it's sensitive, and a short description. The keys are the same as for [`sonar config get`](#sonar-config-get).

**Options:**

| Option       | Type    | Required | Description                                 | Default |
| ------------ | ------- | -------- | ------------------------------------------- | ------- |
| `--format`   | string  | No       | Output format (`text`, `table`, `json`).    | `text`  |
| `--only-set` | boolean | No       | Only show keys that currently have a value. | -       |

**Examples:**

```bash
sonar config list
sonar config list --only-set
sonar config list --format table
sonar config list --format json
```

A stored non-sensitive key with `--only-set --format json`:

```json
[
  {
    "key": "log.level",
    "sensitive": false,
    "set": true,
    "value": "DEBUG"
  }
]
```

A stored sensitive key with `--only-set --format json` omits `value`:

```json
[
  {
    "key": "network.tls.clientPassphrase",
    "sensitive": true,
    "set": true
  }
]
```

***

### `sonar config set`

Store a value for one known SonarQube CLI configuration key. Does not require authentication.

On success, the CLI prints `Saved '<key>'.` and replaces any value already stored for that key.

An unknown key fails with exit code `1` and stores nothing. The message starts with `error: command-argument value '<key>' is invalid for argument 'key'. Allowed choices are` and then lists the known keys.

A value outside the allowed list fails with exit code `2` and stores nothing. The message names the rejected value and the allowed values.

The CLI trims leading and trailing whitespace before it stores the value. An empty or whitespace-only value fails with exit code `2`, stores nothing, and tells you to run [`sonar config unset`](#sonar-config-unset).

Omit `[value]` on an interactive terminal to type it at a masked prompt (`Value for '<key>':`). The prompt does not echo what you type, so the value is not saved in shell history. Cancel the prompt to exit with code `1` and store nothing.

On a non-interactive terminal, omitting the value fails with exit code `1` and stores nothing. Pass the value on the command line in that case.

Non-sensitive values are written to `~/.sonar/sonarqube-cli/cli-config.properties`. Sensitive values are written to the OS keychain. See [State and storage](/sonarqube-cli/administration/state-and-storage.md). `sonar system reset --all` removes that file and those keychain entries. See [Reset the CLI](/sonarqube-cli/administration/system-reset.md).

When the OS keychain is unavailable, such as in many containers and CI jobs, the CLI cannot read a stored sensitive key and treats it as unset. Set the matching `SONAR_*` environment variable instead: `SONAR_HTTPS_PROXY_URL`, `SONAR_HTTP_PROXY_URL`, or `SONAR_TLS_CLIENT_PASSPHRASE`. See [Advanced network configuration](/sonarqube-cli/administration/advanced-network-configuration.md).

The CLI applies a stored `network.*` key when no higher-priority source overrides it. See [Advanced network configuration](/sonarqube-cli/administration/advanced-network-configuration.md). Stored `mcp.container.*` keys tell the MCP container how to reach SonarQube Server or SonarQube Community Build. `mcp.container.autoNetwork` accepts only `true` or `false`. See [Reach a SonarQube Server on the same machine](/sonarqube-cli/administration/advanced-network-configuration.md#reach-a-sonarqube-server-on-the-same-machine). A stored `log.level` sets the level of `~/.sonar/sonarqube-cli/logs/sonarqube-cli.log` the next time the CLI starts. Set `LOG_LEVEL` to `DEBUG`, `INFO`, `WARN`, `ERROR`, or `SILENT` to override it for that process. See [Environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md#logging). When neither source supplies a recognized level, the level is `INFO`. This setting does not change terminal output. Storing `telemetry.enabled` as `false` turns off anonymous usage telemetry and crash reporting. Storing `stats.enabled` as `false` turns off local stats collection. The two settings are independent. `DO_NOT_TRACK=1` still turns telemetry off for the current process without changing the stored value, and it does not turn off local stats. When either key is unset, that collection stays enabled. See [Telemetry and privacy](/sonarqube-cli/administration/telemetry-and-privacy.md).

Use the masked prompt for a sensitive key (`network.proxy.https`, `network.proxy.http`, or `network.tls.clientPassphrase`).

**Arguments:**

| Argument  | Description                                                                               |
| --------- | ----------------------------------------------------------------------------------------- |
| `<key>`   | Config key to store. Must be one of the keys for [`sonar config get`](#sonar-config-get). |
| `[value]` | Value to store. Omit it on an interactive terminal to type it without echoing.            |

**Allowed values:**

| Key                         | Allowed values                                |
| --------------------------- | --------------------------------------------- |
| `log.level`                 | `DEBUG`, `INFO`, `WARN`, `ERROR`, or `SILENT` |
| `telemetry.enabled`         | `true` or `false`                             |
| `stats.enabled`             | `true` or `false`                             |
| `mcp.container.autoNetwork` | `true` or `false`                             |
| Every other key             | Any non-empty string                          |

**Examples:**

```bash
sonar config set log.level DEBUG
sonar config set telemetry.enabled false
sonar config set stats.enabled false
sonar config set network.tls.caCert /etc/ssl/corp-ca.pem
sonar config set network.tls.clientPassphrase   # type the value at a masked prompt (interactive terminal only)
sonar config set mcp.container.autoNetwork true
sonar config set mcp.container.serverUrl http://sonarqube:9000
```

***

### `sonar config unset`

Remove the stored value for one known SonarQube CLI configuration key. Does not require authentication.

On success, the CLI prints `Removed '<key>'.`

When the key is known but nothing is stored, the command exits with code `0`, prints `'<key>' is not set; nothing to remove.`, and writes nothing.

An unknown key fails with exit code `1` and writes nothing. The message starts with `error: command-argument value '<key>' is invalid for argument 'key'. Allowed choices are` and then lists the known keys.

Non-sensitive values are removed from `~/.sonar/sonarqube-cli/cli-config.properties`. Sensitive values are removed from the OS keychain. See [State and storage](/sonarqube-cli/administration/state-and-storage.md). `sonar system reset --all` removes that file and those keychain entries. See [Reset the CLI](/sonarqube-cli/administration/system-reset.md).

Removing `log.level` takes effect the next time the CLI starts. A recognized `LOG_LEVEL` still overrides it, and otherwise the level is `INFO`. See [Environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md#logging). Removing a stored `network.*` key lets the next lower-priority source apply. See [Advanced network configuration](/sonarqube-cli/administration/advanced-network-configuration.md). Removing `telemetry.enabled` or `stats.enabled` returns that collection to the default, which is enabled. `DO_NOT_TRACK=1` still turns telemetry off for the current process.

**Arguments:**

| Argument | Description                                                                                |
| -------- | ------------------------------------------------------------------------------------------ |
| `<key>`  | Config key to remove. Must be one of the keys for [`sonar config get`](#sonar-config-get). |

**Examples:**

```bash
sonar config unset log.level
sonar config unset telemetry.enabled
sonar config unset network.tls.clientPassphrase
```

***

## `sonar allowlist`

Manage local allowlists for SonarQube analyzers. The only allowlist is for secrets detection. See [Secrets detection](/sonarqube-cli/analysis/secrets-detection.md#allow-a-known-safe-value).

### `sonar allowlist secrets show`

List entries in the local sonar-secrets allowlist. The CLI installs the secrets analyzer if it is missing, then prints the analyzer's own list.

**Examples:**

```bash
sonar allowlist secrets show
```

***

### `sonar allowlist secrets add`

Add a secret value to the local sonar-secrets allowlist. Use it for a value you have reviewed as safe, such as a test fixture or a sample token.

The command requires a real interactive terminal. It cannot be run by an agent or a script, and there is no flag to skip that check. When standard input is not a terminal, the command fails and tells you to open a terminal and run it there.

**Examples:**

```bash
sonar allowlist secrets add
```

***

### `sonar allowlist secrets remove`

Remove one entry from the local sonar-secrets allowlist by its key. The command runs without a confirmation prompt. The CLI installs the secrets analyzer if it is missing. If the key is not in the allowlist, the command fails. A key can start with `-`. Put `--` before that key. The CLI then reads it as the key.

**Arguments:**

| Argument | Description                                  |
| -------- | -------------------------------------------- |
| `<key>`  | Unique key of the allowlist entry to remove. |

**Examples:**

```bash
sonar allowlist secrets remove sample-token
sonar allowlist secrets remove -- -sample-token
```

***

### `sonar allowlist secrets clear`

Remove every entry from the local sonar-secrets allowlist. The CLI installs the secrets analyzer if it is missing. At an interactive terminal, the command asks you to confirm once before it deletes entries. Pass `--force` to skip that prompt. When the command is not running in an interactive terminal and the allowlist is not empty, you must pass `--force`. If the allowlist is already empty, the command succeeds either way.

**Options:**

| Option    | Type    | Required | Description                                                                                    | Default |
| --------- | ------- | -------- | ---------------------------------------------------------------------------------------------- | ------- |
| `--force` | boolean | No       | Skip the interactive confirmation prompt. Required for non-interactive use when entries exist. | -       |

**Examples:**

```bash
sonar allowlist secrets clear
sonar allowlist secrets clear --force
```

***

## 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, the container runtime when an MCP server is configured, Antigravity secrets hook health, the recorded Codex installation, and Vortex subscription and usage. For Codex, text output reports **INSTALLED** with the recorded path, and lists managed Sonar hook events when a managed requirements file contains them. 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. `sonar config` settings, including `telemetry.enabled` and `stats.enabled`, are kept unless you pass `--all`. 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).                                                                            | -       |
| `--all`   | boolean | No       | Also remove `sonar config` settings, including `telemetry.enabled` and `stats.enabled`. Collection is enabled again until you set the keys. | -       |

**Examples:**

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

***

## Maintenance

### `sonar update`

Update the CLI installed by the install script, at `~/.local/share/sonarqube-cli/bin/sonar` on macOS and Linux or `%LOCALAPPDATA%\sonarqube-cli\bin\sonar.exe` on Windows. Your saved state and credentials are preserved. After an upgrade, leftover project-scoped agent integrations are migrated to global scope. On that copy, `sonar update` retries the migration even when the CLI is already up to date. A version check does not. A Homebrew cask exits with code 1 before the version check, including with `--force`, and tells you to run `brew upgrade --cask sonarqube-cli`. Mise, an MDM deployment, or any other copy exits with code 1 and tells you to update through your organization, package manager, or the method used to install the CLI. See [Updating the CLI](/sonarqube-cli/administration/self-update.md) 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       | Reinstall the latest version even if already up to date. Does not update a CLI that is not the install-script copy.     | -       |

> **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. Works from any installation. Does not migrate integrations. 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`. An install-script copy then tells you to run `sonar update`. A Homebrew cask tells you to run `brew upgrade --cask sonarqube-cli`. Any other install tells you to update through your organization, package manager, or the method used to install it.

`--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.
