Grok Build Secretly Uploads Entire Git Repositories to xAI Cloud
A security researcher publishing as cereblab has uncovered that xAI's Grok Build coding CLI was uploading entire Git repositories—including full commit history—to a Google Cloud Storage bucket controlled by xAI, far exceeding the data needed for any individual coding task. Testing version 0.2.93, the researcher captured one of these uploads and successfully cloned the git bundle from the intercepted request, recovering files the agent had been explicitly told not to open. The destination bucket, named grok-code-session-traces, was hardcoded in the binary and confirmed via a staged metadata.json whose per-file paths pointed to gs://grok-code-session-traces/. Developers can audit their exposure surface with our email breach checker.
The scale of the data leakage is striking. On a 12 GB repository where the model never read most files, model-turn traffic to the /v1/responses endpoint totaled roughly 192 KB, while the separate storage channel to /v1/storage moved 5.10 GiB—a roughly 27,800x gap between what the model needed and what left the machine. The upload ran as 73 chunks of approximately 75 MB each, all returning HTTP 200, and across the researcher's size sweep the volume tracked total repo size. A planted canary file at src/_probe/never_read_canary.txt, containing a unique marker, was recovered verbatim from the captured bundle along with the repository's complete commit history, and the test replicated on a second, unrelated repo. Disabling the "Improve the model" setting did nothing to stop the uploads—the server's /v1/settings response kept returning trace_upload_enabled: true, revealing that this toggle controls whether data trains the model, not whether code leaves the machine.
Equally concerning is the credential exposure path. When Grok reads a file, its contents flow into the model turn, and a tracked .env file traveled unredacted, including planted canary API_KEY and DB_PASSWORD values, which then landed in a session_state archive bound for storage. While the planted secrets were fake and nothing real leaked in the test, the behavior highlights a serious risk: any credential file the agent reads during a task is transmitted and stored without redaction. Anyone worried about credential exposure should validate their secrets against our password checker and review overall risk posture with the privacy checkup.
A cross-tool comparison by cereblab found that competing agents behaved differently: Claude Code and Codex sent no repository bundle, and Gemini sent none during idle tests. While every cloud coding agent must transmit some source code to a remote model to function, sending the entire tracked repository and its full commit history crosses a far wider boundary than sending only the files a task requires. Repositories can hold proprietary code, internal URLs, customer data, and credentials that were scrubbed from the working tree but still linger in git history. The captures prove transmission, acceptance, and storage—not training—but the implication is unmistakable: code left the machine regardless of user consent settings, and only one of two underlying controls was ever exposed to the developer.