Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read
11:02 · July 14, 2026 · Hacker News AI Section
xAI's Grok Build coding CLI was uploading entire Git repositories, full commit history and all, to a Google Cloud Storage bucket run by xAI, not just the files a coding task needed. A researcher publishing as cereblab, testing version 0.2.93, captured one of those uploads, cloned the git bundle out of the intercepted request, and pulled back a file the agent had been told in plain terms not
Summary
A security researcher publishing under the handle cereblab examined xAI’s Grok Build CLI in version 0.2.93 and found that the tool transmitted entire Git repositories, including full commit histories, to an xAI-controlled Google Cloud Storage bucket named grok-code-session-traces. Network captures showed that a 12 GB repository generated only 192 KB of traffic to the model endpoint while moving 5.10 GiB over a separate storage channel, confirming that the upload occurred independently of any files the model actually read. A deliberately planted file the agent had been instructed not to access was recovered intact from the captured bundle, along with every tracked file and its revision history.
The same behavior persisted when the user-facing “Improve the model” toggle was disabled. Server responses continued to report trace_upload_enabled: true, indicating that the control affected only training consent and left the repository transfer unaffected. When Grok opened a tracked .env file during a task, its contents—including placeholder credentials—were sent both to the model and to a session_state archive stored in the same bucket, with no redaction applied.
On 13 July the server began returning disable_codebase_upload: true for the same client binary, after which no further storage uploads were observed. The change was effected remotely; the upload logic remains present in later builds such as 0.2.99 and can be re-enabled without a client update. xAI has stated that enterprise accounts under zero-data-retention agreements are exempt and that consumers can invoke a /privacy command to delete previously synced data, yet it has not disclosed retention periods, the number of affected users, or the original rationale for collecting full repositories by default.
Why it matters
This article is highly relevant for security and privacy professionals as it highlights a severe data exfiltration risk associated with a popular AI coding assistant. Dutch and EU organizations must be aware of these unauthorized data transfers to protect intellectual property, prevent credential leaks, and ensure compliance with GDPR and corporate security policies.
