> 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/administration/telemetry-and-privacy.md).
# Telemetry and privacy
What the SonarQube CLI sends home, what it does not, and how to opt out for an individual developer or across a fleet.
The SonarQube CLI collects two kinds of data:
* Anonymous usage telemetry: which commands are run, on what platform, and whether they succeeded.
* Crash reports via [Sentry](https://sentry.io): unhandled exceptions, scrubbed of personal paths.
Both are enabled by default. They share a single opt-out and transmit no source code, no file contents, and no secrets.
## What telemetry collects
Telemetry helps us understand how the CLI is used so we can prioritize improvements, catch regressions, and decide which platforms and integrations to invest in. At a high level, events capture which commands are run, whether they succeed, the CLI version and operating system, and (when you're authenticated) which SonarQube connection the command ran against. For project-scoped commands, `CliCommandExecuted` also carries the project's server-side UUID (`project_uuid`)—not the project key or name. We also record which AI coding agent invoked the CLI when one is detectable, so we can invest in the right integrations. When an agent exposes a session identifier (for example through agent-native environment variables or hook payloads), events may also include an opaque `agent_session_id` that correlates multiple CLI invocations within the same agent conversation. This is not prompt text, file paths, or project metadata.
Every `CliCommandExecuted` event also carries `arguments`: a space-separated list of the flags and positional arguments you passed, or `null` when you passed none. Boolean flags and free-form options are recorded by name only (for example `--project`, never the project key). Options with a fixed set of choices include the value (for example `--format=json`). Positional arguments with a fixed set of choices include the value (for example `key=log.level` when you run `sonar config get log.level`). Free-form positional arguments are recorded by name only (for example `file`), never the path or other value. A value you pass to `sonar config set` is free-form, so telemetry records the argument name `value` and not what you stored. Flags you did not pass, including defaults, are omitted.
Events are buffered locally in `~/.sonar/sonarqube-cli/telemetry/telemetry-events.ndjson` and flushed asynchronously to SonarSource's telemetry endpoint. Your installation ID stays in `state.json`, and your telemetry preference is the `telemetry.enabled` key in `cli-config.properties`. Only the event queue uses the separate file. A stable anonymous user ID (a UUID) is stored separately at `~/.sonar/user` so it can be shared across Sonar products on the same machine. See [State and storage](/sonarqube-cli/administration/state-and-storage.md) for the full on-disk layout.
### Sample events
The CLI emits three event types. The following JSON samples show representative payloads; IDs are examples only.
#### Command executed
```json
{
"metadata": {
"event_id": "eb93b2b4-f7b0-4b5c-9460-50893968c264",
"source": { "domain": "CLI" },
"event_type": "Analytics.Cli.CliCommandExecuted",
"event_timestamp": "1740670309173"
},
"event_payload": {
"cli_installation_id": "b1f2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
"machine_id": "9d0cf582-219e-4bab-8311-d599c55c4ce2",
"cli_version": "1.6.0",
"invocation_id": "3e44541a-124b-4c56-9d78-0a2f395e71bd",
"os": "linux",
"connection_type": "sqs",
"user_uuid": null,
"organization_uuid_v4": null,
"sqs_installation_id": "47c92694-6739-4fb0-8112-9840a2f39561",
"caller_agent": null,
"agent_session_id": null,
"command": "auth",
"subcommand": "login",
"result": "success",
"distribution": "standalone",
"project_uuid": null,
"arguments": null
}
}
```
`project_uuid` and `arguments` appear on `CliCommandExecuted` only. `CliAnalysisCompleted` and `CliIntegrationConfigured` join to the command event on `invocation_id`.
#### Analysis completed
```json
{
"metadata": {
"event_id": "eb93b2b4-f7b0-4b5c-9460-50893968c261",
"source": { "domain": "CLI" },
"event_type": "Analytics.Cli.CliAnalysisCompleted",
"event_timestamp": "1740670312415"
},
"event_payload": {
"cli_installation_id": "b1f2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
"machine_id": "9d0cf582-219e-4bab-8311-d599c55c4ce2",
"cli_version": "1.6.0",
"invocation_id": "3e44541a-124b-4c56-9d78-0a2f395e71bd",
"os": "linux",
"connection_type": "sqc",
"user_uuid": "7a349181-6417-4164-8c89-46e113b5824c",
"organization_uuid_v4": "c3b587a4-2990-4b0e-8f65-a56a3ef30e0e",
"sqs_installation_id": null,
"caller_agent": "claude",
"agent_session_id": "claude-sess-example",
"caller_command": "analyze secrets",
"analyzer": "sonar-secrets",
"analysis_id": "d21d2069-7190-4b0e-8f06-891f7eb0c4ee",
"findings_count": 3,
"exit_code": 51,
"errors_count": 0,
"failures_count": 0,
"scan_duration_ms": 272,
"details": "{\"counts_by_rule\":{\"secrets:S6689\":1,\"secrets:S6731\":1,\"secrets:S6732\":1},\"files_with_findings_count\":1,\"source\":\"files\"}"
}
}
```
#### Integration configured
```json
{
"metadata": {
"event_id": "5a824c5e-71bd-4c4e-8e17-2299261d7801",
"source": { "domain": "CLI" },
"event_type": "Analytics.Cli.CliIntegrationConfigured",
"event_timestamp": "1740670318907"
},
"event_payload": {
"cli_installation_id": "b1f2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
"machine_id": "9d0cf582-219e-4bab-8311-d599c55c4ce2",
"cli_version": "1.6.0",
"invocation_id": "3e44541a-124b-4c56-9d78-0a2f395e71bd",
"os": "win32",
"connection_type": "sqc",
"user_uuid": "7a349181-6417-4164-8c89-46e113b5824c",
"organization_uuid_v4": "c3b587a4-2990-4b0e-8f65-a56a3ef30e0e",
"sqs_installation_id": null,
"caller_agent": null,
"agent_session_id": null,
"integration_id": "claude-code",
"repo_id": "3e2b4c1d0a9f8e7d6c5b4a39281706f5e4d3c2b1a0f9e8d7c6b5a4938271605f",
"features_installed": [
"sonar-secrets-hooks",
"sonar-sqaa-hook",
"sqaa-instructions",
"mcp-server",
"context-augmentation"
],
"features_declined": [],
"features_uninstalled": [],
"is_global": false,
"is_interactive": true,
"is_from_router": false
}
}
```
## What telemetry does not collect
* File contents
* File paths or filenames inside your repositories.
* Project names or keys (only server-side UUIDs).
* Free-form flag values and free-form positional argument values (project keys, branches, file paths, tokens, search queries, and values stored with `sonar config set`).
* Command output
* Any token or credential value.
## What crash reports contain
Sentry is used for crash reporting only. When the CLI hits an unhandled exception, it sends:
* The exception type and message.
* The stack trace, *with your home directory path scrubbed* before transmission.
* The CLI version and OS.
Crash reports are tied to the same opt-out as telemetry; turning off telemetry also turns off Sentry.
## Disable telemetry and crash reporting
Turn telemetry off on one machine:
```bash
sonar config set telemetry.enabled false
```
Turn it back on:
```bash
sonar config set telemetry.enabled true
```
To return to the default, remove the stored value. Collection stays enabled when the key is not set:
```bash
sonar config unset telemetry.enabled
```
The setting is stored in `~/.sonar/sonarqube-cli/cli-config.properties`. [`sonar config get telemetry.enabled`](/sonarqube-cli/using-sonarqube-cli/commands.md#sonar-config-get) prints the stored value, or `(not set)` when you are on the default.
After you update the CLI, the next command copies an existing opt-out from `state.json` into that file when `telemetry.enabled` is not already set, then removes `telemetry.enabled` from `state.json`.
To disable telemetry and crash reporting for the current shell session without changing the stored setting, set:
```bash
export DO_NOT_TRACK=1
```
## Rolling out an opt-out across a fleet
Use either of these approaches for a scaled rollout where policy requires telemetry off by default:
* Run `sonar config set telemetry.enabled false` from your developer-environment bootstrap (Ansible, Chef, a dotfiles repo, or an IT-managed onboarding script). This writes the setting to `cli-config.properties` on every machine.
* Or set `DO_NOT_TRACK=1` in your shared developer environment to disable both telemetry and crash reporting without changing persisted configuration.
The opt-out is per-machine. No central org-level switch exists yet.
## Local stats stay on your machine
The CLI can also keep a local record of secrets detection, Vortex analysis, and dependency-risk analysis runs in `~/.sonar/sonarqube-cli/db/stats/`. That record is for you only. It's never transmitted, and it is not part of telemetry or crash reports.
Collection stays enabled until you opt out. `DO_NOT_TRACK` does not turn it off, and turning off telemetry does not turn it off.
```bash
sonar config set stats.enabled false
```
To turn it back on:
```bash
sonar config set stats.enabled true
```
When `stats.enabled` is not set, collection stays enabled. The setting is stored in `cli-config.properties`. After you update, the next command copies an existing opt-out from `state.json` when `stats.enabled` is not already set, then removes the `stats` object from `state.json`.
[`sonar system reset`](/sonarqube-cli/administration/system-reset.md) deletes the local stats database. It keeps `telemetry.enabled` and `stats.enabled` unless you pass `--all`.
## Related pages
* [State and storage](/sonarqube-cli/administration/state-and-storage.md)
* [Environment variables](/sonarqube-cli/using-sonarqube-cli/environment-variables.md)
* [`sonar config set`](/sonarqube-cli/using-sonarqube-cli/commands.md#sonar-config-set)
* [`sonar config get`](/sonarqube-cli/using-sonarqube-cli/commands.md#sonar-config-get)
---
# 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/administration/telemetry-and-privacy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.