xAI Grok Build CLI Wire Analysis: Full Repo Uploaded to xAI Servers
Original: What xAI's Grok Build CLI Actually Sends to xAI
Why This Matters
Undisclosed bulk code and secrets uploads by a major AI coding CLI raise significant enterprise privacy and security concerns.
A wire-level analysis of xAI's Grok Build CLI (v0.2.93) found that the tool uploads entire repository contents—including .env secrets files and full git history—to xAI's servers via POST /v1/storage, regardless of what files the AI agent actually reads.
Researcher 'cereblab' published a reproducible teardown of xAI's official Grok Build coding CLI (version 0.2.93), capturing network traffic during normal use on their own machine with a throwaway repository containing fake canary secrets.
Key findings:
1. **Secrets transmission**: Contents of .env files are sent verbatim and unredacted via two channels — the live model turn (POST /v1/responses) and a session_state archive uploaded via POST /v1/storage.
2. **Unconditional repo upload**: Even when prompted with "reply OK, do not read any files," Grok packaged and uploaded the entire repository as a git bundle. Cloning the captured bundle recovered a file the agent was explicitly told not to open — src/_probe/never_read_canary.txt — with its unique marker intact, along with full git history.
3. **Scale confirmed**: On a 12 GB repo of never-read random files, /v1/storage moved 5.10 GiB (all HTTP 200), while the model-turn channel moved only 192 KB — a ~27,800× ratio confirming the upload targets the codebase, not just what was read.
4. **Destination**: Data is routed to a Google Cloud Storage bucket named grok-code-session-traces (gs://grok-code-session-traces/…), named verbatim in the binary and in captured metadata.json.
The researcher states this mechanism was not found documented in user-facing disclosures. All captures used fake credentials; no real secrets were exposed. Evidence includes SHA-256 hashes and a "what we did not prove" list in the appendix.