Developers using xAI’s Grok Build CLI may have unknowingly uploaded entire Git repositories, including complete commit histories, to xAI-managed cloud storage, according to new security research that raises fresh concerns about AI coding assistant data handling.
The findings come from independent researcher cereblab, who analyzed Grok Build version 0.2.93 and discovered the client was transmitting substantially more data than required to complete coding tasks. Rather than sending only the files referenced during an AI interaction, the tool reportedly uploaded complete Git bundles to a Google Cloud Storage bucket operated by xAI.
The behavior has since been disabled through a server-side configuration change, but researchers say the client performed these uploads even when users had disabled the option to contribute data for model improvement.
Entire repositories were transmitted
To determine exactly what Grok Build uploaded, the researcher intercepted outbound requests generated by the client during testing.
The captured traffic showed the application creating and uploading Git bundle archives containing the full tracked repository and its commit history. In one proof-of-concept, the researcher successfully recovered a canary file that the AI assistant had explicitly been instructed not to read, demonstrating that repository uploads extended beyond files actually accessed during a coding session.
Testing against a 12 GB repository highlighted the scale of the difference. According to the research, requests sent directly to the AI model totaled roughly 192 KB, while uploads to xAI’s storage service transferred approximately 5.1 GiB across dozens of upload chunks.
The researcher also identified references within the client to a Google Cloud Storage bucket named grok-code-session-traces, where uploaded session artifacts were reportedly stored.
Training opt-out did not prevent uploads
One of the more significant findings involved Grok’s privacy controls.
Even with the “Improve the model” option disabled, repository uploads continued during testing. According to the researcher, server responses still returned trace_upload_enabled: true, indicating that disabling model training did not disable repository collection.
The research argues these represent two separate behaviors: preventing uploaded data from being used for model training is not the same as preventing data from leaving the local machine.
For organizations using AI coding assistants in corporate environments, that distinction could have significant privacy and compliance implications.
Commit history may expose deleted secrets
The research also examined how Grok Build handled sensitive information.
When the AI assistant read a tracked .env file during testing, its contents were reportedly included both in requests sent to the model and in uploaded session data. The credentials used during testing were intentionally fake, but the researcher noted that real API keys, database passwords, and other secrets could be exposed if present in repositories processed by the tool.
Perhaps more importantly, uploading complete Git histories means secrets removed from the current working tree may still be included if they remain in previous commits.
Gitignored files that were never committed were reportedly excluded from testing, but committed files remained recoverable through repository history.
xAI disabled the behavior after disclosure
According to the research, xAI disabled repository uploads on July 13 through a server-side configuration change rather than a client update.
Subsequent testing reportedly showed no further uploads to the storage endpoint, while server responses began returning disable_codebase_upload: true and trace_upload_enabled: false.
xAI has not published a formal security advisory explaining why complete repositories were uploaded, how long the behavior existed, or whether previously collected data has been deleted.
We care deeply about your privacy and respect customer choice. For teams using zero data retention, no trace and code data is ever retained. All API key use of Grok Build also respects ZDR.
If ZDR is disabled, the /privacy command is available in the CLI to disable data…
— SpaceXAI (@SpaceXAI) July 13, 2026
Statements posted by xAI on X indicated enterprise customers using Zero Data Retention configurations were not affected by stored trace data, while consumer users were directed to use the CLI’s /privacy command to disable retention and request deletion of previously synchronized information.
What defenders should do
Organizations using AI coding assistants should review whether Grok Build was deployed on developer workstations and evaluate what repositories may have been processed before the server-side change.
- Rotate credentials that may have existed in repositories processed by affected Grok Build versions.
- Audit Git history for previously committed secrets, not just the current working tree.
- Avoid running AI coding assistants from home directories or repositories containing unrelated sensitive projects.
- Require human approval before allowing AI agents to access or upload external resources.
- Monitor outbound network traffic from AI developer tools to understand exactly what data leaves developer endpoints.
The findings also reinforce concerns raised in our recent coverage of HalluSquatting, which demonstrated how AI coding assistants can be manipulated into retrieving attacker-controlled repositories. Together, the two studies highlight the growing importance of understanding both what AI development tools download and what they upload.
