Gemini CLI sends a persistent installation ID to Google by default.
What we found.
Gemini CLI's configuration reference says: "To help us improve Gemini CLI, we collect anonymized usage statistics." In our runs, "In all 14 main runs with default settings, Gemini CLI sent usage statistics to play.googleapis.com/log". "We decoded 93 usage events. Every one of them carried a client_install_id equal to the UUID in ~/.gemini/installation_id, a file the CLI creates in the HOME directory." "77 of the 93 events (every event type except "ripgrep_fallback") also carried the host's CPU model string, CPU core count and total memory."
The same installation ID also rode along on every model API request: 46 of 46 requests carried it as the header x-gemini-api-privileged-user-id, in the same HTTP request as the API key. We found no documentation of that header.
"With privacy.usageStatisticsEnabled = false as the only opt-out, no usage statistics were sent, no installation_id file was created, and none of the 6 model requests carried the x-gemini-api-privileged-user-id header (all 6 received HTTP 200)." This note describes behaviour; it does not make claims about intent or legality.
What the usage statistics carried.
What we tested, and what we saw.
We tested Gemini CLI 0.61.0 (@google/gemini-cli from npm), on 27 September 2026, with "a Gemini Developer API key (security.auth.selectedType = "gemini-api-key")". "Main set, 16 test runs: 14 with default settings apart from the authentication type (headless and interactive; some of these passed an approval-mode, allowed-tools or yolo flag on the command line), and 2 that set privacy.usageStatisticsEnabled, telemetry.enabled, general.enableAutoUpdate and general.enableAutoUpdateNotification to false." The isolation set added runs with the one setting as the only opt-out, plus a control run with default settings.
Set-up: "a fresh throwaway Linux container per run with a new in-memory HOME, a TLS-intercepting proxy the client trusted, and a full packet capture."
- "That value stayed the same across separate CLI invocations and sessions sharing a HOME directory (in one run, three invocations with two different session IDs all carried the same installation ID). Each fresh HOME produced a new value (14 HOME directories, 14 distinct values)."
- "The "startup_stats" event also carried the operating system and the kernel release (for example "6.14.0-29-generic")."
- "For fairness: the 16 requests to play.googleapis.com/log that carried these 77 events each received an HTTP 400 (Bad Request) response. The other 16 requests, carrying the 16 "ripgrep_fallback" events (installation ID included, no hardware fields), received HTTP 200." "We do not know the cause of the 400 responses, and we report what the CLI sent, not what was accepted."
- "We found no prompt text, file contents, tool arguments or our test canary values in any usage event. That matches the documentation's list of what is not collected."
Where they differ.
| Google's documentation says | What we observed |
|---|---|
| Configuration reference, section "Usage statistics": "To help us improve Gemini CLI, we collect anonymized usage statistics." | In our runs the statistics carried "a client_install_id equal to the UUID in ~/.gemini/installation_id". The value "stayed the same across separate CLI invocations and sessions sharing a HOME directory", which we would describe as "pseudonymous rather than anonymized". |
| The same section lists "What we collect" as tool calls, API requests and "Session information: We collect information about the configuration of the CLI, such as the enabled tools and the approval mode." | "77 of the 93 events" also "carried the host's CPU model string, CPU core count and total memory". The "startup_stats" event also carried the operating system and the kernel release. None of these fields appear in that list. |
| We searched the configuration reference, the observability page, the Gemini API reference and the gemini-cli repository for the header. "We found no documentation of this header." | "the same installation ID value was sent as the request header x-gemini-api-privileged-user-id, in the same HTTP request as the x-goog-api-key header that carries the API key", on 46 of 46 model requests with default settings. |
One setting stopped all of it in our runs.
Set privacy.usageStatisticsEnabled to false. "Setting privacy.usageStatisticsEnabled to false on its own stopped the usage statistics in our runs."
"With privacy.usageStatisticsEnabled = false as the only opt-out, no usage statistics were sent, no installation_id file was created, and none of the 6 model requests carried the x-gemini-api-privileged-user-id header (all 6 received HTTP 200)." The two main-set runs with all four settings off showed the same result.
The OpenTelemetry observability feature is a different switch and does not control this; in the documentation "that feature is off by default (telemetry.enabled = false)".
What we are not claiming.
- "We are not claiming a security vulnerability, and we found no prompts, code, file contents or credentials in the usage statistics."
- "We do not know how this data is used, how long it is kept, or whether the installation ID is linked to an API key or account after receipt, and we make no claim about that. The installation ID and the API key arrive in the same request; what happens to them after receipt is not something we can observe."
- "We do not know whether Google keeps data from the usage-statistics requests that received HTTP 400."
- "We tested Gemini Developer API key mode only. We make no claim about Google account sign-in, Gemini Code Assist or Vertex AI."
- "The isolation set is 2 runs plus 1 control, on one version, on one day."
- We tested one version, Gemini CLI 0.61.0, on 27 September 2026. We make no claim about versions we have not tested.
Disclosure of interest: "Agentic Thinking also owns AgentProtect, commercial AI agent governance software."
Disclosure timeline.
- 27 Sep 2026: reported to security@google.com, the contact in Google's security.txt, as a documentation and privacy matter under our disclosure policy: "about 30 days for documentation matters".
- 27 Sep 2026: the only reply we have received is an automated notice from
security-noreply@google.com, which states: "This e-mail address is not monitored by humans." It points vulnerability reports to bughunters.google.com. We have received no substantive reply. - 27 October 2026: this note published, stating the tested version only.
Any response will be added here. Evidence and reproduction steps are available to Google and to researchers on request: research@agenticthinking.uk.