xAI Grok Build CLI 0.2.93 Wire-Level Analysis

xAI Grok Build CLI 0.2.93 Wire-Level Analysis

Executive Summary

Analysis of the xAI Grok Build CLI (version 0.2.93) demonstrates that the tool transmits entire local repositories—including git history and unredacted secrets files—to xAI servers. This data is persisted in a Google Cloud Storage (GCS) bucket named grok-code-session-traces, and the upload occurs independently of whether the AI agent actually reads the files or whether the user has disabled the "Improve the model" setting.

Unredacted Transmission of Secrets

Grok Build transmits the contents of files it reads, including .env and secrets files, verbatim and without redaction.

When the CLI reads a file to provide context to the model, the content is sent through two distinct channels:

  1. Model-Turn Channel: The content is serialized into the POST /v1/responses request body.
  2. Storage Channel: The content is packaged into a session_state archive and uploaded via POST /v1/storage.

Wire-level captures confirm that canary secrets (e.g., API_KEY=CANARY7F3A9-SECRET) placed in a .env file were transmitted in plain text and accepted by the server with an HTTP 200 status code.

Whole-Repository Exfiltration

The Grok Build CLI uploads a complete snapshot of the workspace, including all tracked files and full git history, regardless of what the agent reads.

Evidence from wire captures shows a massive disparity between the data sent for model responses and the data sent for storage. In one test involving a 12 GB repository of random files that the agent was explicitly told not to read, the model-turn channel moved only 192 KB, while the storage channel (/v1/storage) moved over 5.10 GiB of data.

Verification via Git Bundles

To prove that unread files are uploaded, the researcher used a "canary" file (src/_probe/never_read_canary.txt) containing a unique marker. Despite prompting the agent to "Reply with exactly: OK. Do not read or open any files," the CLI uploaded the entire repository as a git bundle via POST /v1/storage. A git clone of the captured bundle recovered the canary file and its unique marker verbatim, along with the full git history.

Infrastructure and Telemetry

The destination for these uploads is a Google Cloud Storage bucket, not AWS S3.

Analysis of the binary strings and captured metadata.json files reveals the following:

  • Destination Bucket: gs://grok-code-session-traces/
  • API Endpoints: Requests are routed through cli-chat-proxy.grok.com and directly to storage.googleapis.com for multipart uploads.
  • Telemetry: The CLI sends tracking data to Mixpanel (api.mixpanel.com) and xAI's own events endpoint (grok.com/_data/v1/events).

Policy and Consent Analysis

Disabling the "Improve the model" toggle does not stop the repository upload.

While xAI provides an opt-out for using data to improve models, this setting governs training policy, not data transmission. Tests 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.

Furthermore, the researcher noted that the mechanism for 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 Insights and Mitigations

Discussion among technical users highlights significant privacy concerns regarding proprietary agent runners.

Proposed Mitigations

Users have suggested several ways to limit the risk of data exfiltration when using AI coding tools:

  • Sandboxing: Using tools like bubblewrap to restrict the agent's access to only the necessary project directory and mounting sensitive directories as empty.
  • Network Isolation: Using an HTTP proxy to restrict the agent's network access to only specific LLM provider hostnames, and blocking the tool's own telemetry and storage endpoints.
  • Secret Scanning: Implementing a proxy (similar to gitleaks) that scans outgoing streams for secrets and replaces them with unique identifiers before they reach the provider.

Counterpoints

Some users argue that uploading the codebase is a performance optimization, allowing the model to inspect the codebase during its "thinking" phase without making repeated tool calls back to the client, thereby reducing round-trip time (RTT).

"One reason to want to upload the entire codebase is that it allows them to have the model inspect the codebase during 'thinking' without going back to the client to do real tool calls."

Technical Appendix: Provenance

  • Version Tested: grok 0.2.93
  • Binary SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c
  • Methodology: Traffic was captured using mitmproxy with a trusted CA in the macOS login keychain to decrypt HTTPS traffic.

Sources