xAI Grok Build CLI 0.2.93 Analysis: Unredacted Secrets and Whole-Repo Uploads

A wire-level analysis of the xAI Grok Build CLI (version 0.2.93) demonstrates that the tool transmits unredacted secrets and uploads entire local repositories to xAI servers. This behavior occurs independently of whether the AI agent actually reads the files during a session and persists even when the "Improve the model" setting is disabled.

Unredacted Transmission of Secrets

When the Grok Build CLI reads a file, its contents are transmitted to xAI without redaction. This includes sensitive files such as .env or secrets.env files. The data is transmitted through two distinct channels:

  1. Model-Turn Channel: File contents are serialized into the POST /v1/responses request body used for model interactions.
  2. Storage Channel: Contents are packaged into a session_state archive and uploaded via POST /v1/storage.

Analysis of captured traffic shows that canary secrets (e.g., API_KEY=CANARY7F3A9-SECRET) are sent verbatim to both endpoints and accepted with an HTTP 200 status code.

Whole-Repository Uploads via Git Bundles

Beyond the files the agent reads, Grok Build performs a full snapshot of the workspace. The tool uploads the entire repository—including every tracked file and the full git history—as a git bundle via POST /v1/storage.

Evidence of Bulk Uploads

  • Volume Disparity: In a test using a 12 GB repository containing random files that the agent was explicitly told not to read, the model-turn channel (/v1/responses) moved only 192 KB of data. In contrast, the storage channel (/v1/storage) uploaded 5.10 GiB of data before the capture was truncated. This ~27,800× ratio confirms the upload is a codebase snapshot, not a reflection of what the model ingested.
  • Verification via Git Clone: By capturing the POST /v1/storage request, researchers were able to recover a git bundle. Running git clone on this bundle reconstructed the repository, including files the agent was explicitly told not to open and their unique markers verbatim.
  • Scale: The upload mechanism scales to multi-gigabyte volumes. In a 12 GB repo test, 82 content POSTs (including 73 chunks of ~75 MB each) all returned HTTP 200, indicating no storage size ceiling was encountered in the tested range.

Storage Destination and Infrastructure

The uploaded data is routed to a Google Cloud Storage (GCS) bucket named grok-code-session-traces. This is confirmed by:

  • Binary Analysis: Strings within the binary reference grok-code-session-traces and storage.googleapis.com.
  • Metadata Inspection: Staged metadata.json files reveal per-file destinations using the format gs://grok-code-session-traces/repo_changes_dedup/v2/....

Additionally, the CLI utilizes third-party telemetry via Mixpanel (api.mixpanel.com) and xAI's own event tracking (grok.com/_data/v1/events).

Consent, Policy, and Opt-Out Limitations

While xAI's consumer policy allows users to opt out of using their data for model improvement, this toggle does not stop the repository upload process.

  • Ineffectiveness of Opt-Out: Testing confirmed that with "Improve the model" turned OFF, the CLI still uploaded the entire repository as a git bundle and the server's /v1/settings response continued to return "trace_upload_enabled": true.
  • Documentation Gap: The specific mechanism of uploading the repo_state and session_state to the grok-code-session-traces bucket is not surfaced in the CLI's installation script or quickstart materials.

Community Perspectives and Mitigations

Technical discussions following these findings highlight significant privacy concerns regarding the use of proprietary agent runners.

"This is precisely the reason... I chose not to go with them. [The upload of the whole repository] is extremely concerning."

Users have suggested several mitigation strategies for those who must use such tools:

  • Sandboxing: Using tools like bubblewrap or landstrip to restrict the agent's access to only the necessary project directory and isolating the network namespace to allow only specific LLM provider hostnames.
  • Proxying: Implementing a custom proxy (e.g., a fork of CLIProxyAPI) to scan outgoing streams for secrets and replace them with unique identifiers before they reach the upstream provider.
  • Environment Isolation: Running the agent in a dedicated UNIX account with restricted access to the home directory and /etc or /proc filesystems.

Technical Summary of Findings

Finding Detail Status
Secrets Leak .env files sent unredacted via /v1/responses and /v1/storage Proven
Repo Upload Entire tracked workspace + git history uploaded as git bundle Proven
Data Volume Confirmed multi-GB uploads (up to 5.1 GiB captured) Proven
Destination Google Cloud Storage bucket grok-code-session-traces Proven
Opt-Out "Improve the model" toggle does not stop uploads Proven

Sources

Related

  • Dispatch
    Grok CLI Data Exfiltration Incident

    A user reported that the Grok CLI uploaded their entire home directory, including SSH keys and password databases, to xAI servers, sparking a widespread debate on the necessity of sandboxing AI agents.

  • Dispatch
    xAI Grok Collections API Release

    xAI has launched the Collections API, a managed knowledge base service that enables developers to build RAG applications by uploading datasets for precise semantic, keyword, and hybrid search.

  • Dispatch
    Exploring Grok Build: xAI's New CLI for Agentic Development

    xAI introduces Grok Build, a CLI tool for building bots and agent orchestration, gated behind a high-tier subscription model.

  • Dispatch
    xAI Launches Grok Business and Grok Enterprise

    xAI has introduced Grok Business and Grok Enterprise, providing organizations with secure, permission-aware AI assistants that do not train on customer data.

  • Dispatch
    Grok Build Open Source Release

    xAI has open-sourced Grok Build, a coding agent and terminal user interface (TUI) that supports local-first execution and an extensible extension system.