"All user data uploaded before now will be completely and utterly deleted," Elon Musk said, promising removal of previously stored content.
What cereblab captured from Grok Build
A researcher publishing as cereblab tested Grok Build version 0.2.93 and intercepted an upload that included an entire Git repository—files plus full commit history—sent to a Google Cloud Storage bucket run by xAI. The captured bundle contained an unread probe file, src/_probe/never_read_canary.txt, planted with a unique marker; cloning the bundle recovered that file verbatim along with the repository's full commit history. The result was replicated on a second, unrelated repository, demonstrating repeatable transmission and acceptance to xAI storage. The researcher stresses the captures establish transmission, acceptance, and storage, not training.
How much left the machine: responses vs storage channels
The uploads used two distinct channels. Model-turn traffic to /v1/responses reflected what the model needed for a coding task; storage traffic to /v1/storage carried the repository bundle. In one example, a 12 GiB repository that the model never read generated roughly 192 KB of model-turn traffic to /v1/responses while the storage channel to /v1/storage moved about 5.10 GiB—a roughly 27,800× gap between what the model needed and what was uploaded for storage. That storage upload ran as 73 chunks of about 75 MB each, every one returning HTTP 200. The destination bucket is named grok-code-session-traces and is referenced in the binary and a staged metadata.json whose per-file paths point at gs://grok-code-session-traces/.
Secrets exposure: .env, model turns, and session_state archives
When Grok read a file, its contents entered the model turn; the researcher tested a tracked .env file and found it went out unredacted, including planted API_KEY and DB_PASSWORD values. The same secret content also landed in a session_state archive bound for storage. The planted secrets were fake in the test, so nothing real leaked in this instance, but the behavior is the core concern: credential files that the agent read were transmitted and stored without redaction.
xAI's server-side switch and public explanations
On July 13 the same 0.2.93 client stopped making storage requests; cereblab retested six times and observed zero /v1/storage uploads. The server began returning disable_codebase_upload: true and trace_upload_enabled: false in /v1/settings responses. Developer Peter Dedene reported the same flag returned for his account, indicating the change was server-side rather than a client update. A separate analysis of build 0.2.99 found the upload code still present in the binary but prevented from running by the server flag, meaning xAI can re-enable it without shipping a new client.
xAI addressed the issue publicly on X via the @SpaceXAI account, saying enterprise teams on zero data retention (ZDR) never have code or trace data stored and that API-key use respects ZDR. The post told consumers who have not enabled ZDR they can run /privacy in the CLI to disable retention and delete previously synced data. Elon Musk then said previously uploaded user data would be "completely and utterly deleted." xAI has not confirmed whether the server-side flags reach every account or whether the change is permanent, nor has it publicly explained why full repositories were uploaded by default, how long they were kept, or how many users were affected.
What this means for developers, enterprise teams, and security teams
- Developers and individual subscribers: Rotate any credential Grok could have sent—anything the agent read, anything in tracked files, and anything present in git history (including secrets committed and later deleted). A gitignored file that was never committed stayed out of the bundle; a committed secret rode along in history and deleting it later does not remove it from past bundles.
- Enterprise teams on zero data retention (ZDR): According to @SpaceXAI, ZDR enterprise accounts and API use are exempt from code or trace storage; the company says API-key use respects ZDR. Enterprise teams should verify account-level settings and logs to confirm whether storage flags applied to their environments.
- Security teams and procurement leaders: The presence of an upload path independent of model-turn traffic—controlled by server-side flags—means a training opt-out toggle (e.g., "Improve the model") does not by itself prevent repository uploads. Contracts and operational checks should distinguish retention/training opt-outs from the controls that permit code and trace data to leave developer machines.
xAI's actions—turning off server-side uploads for the tested binary and offering CLI controls to delete synced data—addressed the immediate transmission observed by cereblab. They do not, however, answer why the client defaulted to bundling full repositories and commit histories in the first place, how many users were impacted, or the retention period for stored bundles. Those unanswered specifics are central to assessing risk and remediation for any user who ran the tooling before July 13.
