The Grok Build CLI tool from xAI, designed to help with writing code, was, according to a researcher, uploading to xAI’s cloud storage not only the files required to complete a task, but entire Git repositories together with the full commit history. The issue affected at least version 0.2.93 and potentially applied to any developer who used the tool before July 13. The user setting to opt out of model training did not stop data transmission. Everyone who has worked with Grok Build is advised to immediately rotate any secrets that may have been present in tracked files or commit history.
What the Network Traffic Analysis Showed
The researcher publishing under the pseudonym cereblab carried out a detailed analysis of Grok Build version 0.2.93’s network traffic. The tool used two separate data channels: one for interacting with the language model via the /v1/responses endpoint, and a second for uploading data to storage via /v1/storage.
The scale of the discrepancy between these channels is telling. On a 12 GB repository whose files the model did not read, traffic to the model amounted to about 192 KB, whereas 5.10 GiB went to the storage channel — a difference of roughly 27,800 times. The upload was performed in 73 fragments of about 75 MB each, with every fragment receiving an HTTP 200 response. The upload volume reportedly scaled in proportion to the size of the repository.
The target storage — the grok-code-session-traces bucket in Google Cloud Storage — was identified both in the tool’s binary file and in an intermediate metadata.json file that contained paths of the form gs://grok-code-session-traces/.
Canary Test and the Secrets Problem
To confirm that data was being transmitted, the researcher placed a file named src/_probe/never_read_canary.txt with a unique marker in the repository and explicitly instructed the agent not to open this file. After intercepting the uploaded bundle and cloning it, the canary file was restored verbatim together with the full commit history. The test was reproduced on a second, unrelated repository with the same result.
A separate issue concerned the handling of secrets. When Grok read a tracked .env file as part of a task, its contents — including test values for API_KEY and DB_PASSWORD — were sent into the model context without any redaction and were additionally stored in a session_state archive that was uploaded to storage. The secrets in the test were fake, but the mechanism itself — sending and storing credentials without filtering — represents a systemic risk.
Important: the research documents the fact of transmission, receipt, and storage of data, but does not claim that xAI used the code to train the model or that company employees accessed it. It is also noted that files from .gitignore that never made it into commits were not included in the bundle.
Privacy Setting Did Not Work as Expected
A key aspect of the incident is how the user settings behaved. According to the researcher, with the “Improve the model” option disabled, the tool continued to upload the repository, and the server’s response to the /v1/settings request still contained trace_upload_enabled: true. This means the toggle controlled only whether the data would be used for model training, but not the fact that code was being sent from the user’s machine. Two different mechanisms — data transmission and its use for training — were separated, but the user had control only over the latter.
Comparison with Competitors
In a comparative analysis carried out by the same researcher, Claude Code and Codex did not send repository bundles. Gemini did not send a bundle in the test without an active task, although the test with a real task was not completed due to quota exhaustion. Grok Build turned out to be the only tool performing a bulk upload of the workspace. At the same time, all cloud coding tools send the files they open — a fully local model of operation does not apply to them.
xAI’s Response and Current Status
On July 13, the same 0.2.93 binary stopped making calls to /v1/storage. The researcher ran six repeat tests — not a single upload to storage occurred. The server began returning disable_codebase_upload: true and trace_upload_enabled: false. Since the client remained on the same version, this was a server-side block rather than an application update. Developer Peter Dedene confirmed similar flag changes on his account.
xAI responded via posts on X rather than through a formal security advisory. The @SpaceXAI account stated that corporate customers with zero data retention (ZDR) mode were never subject to storage of code or traces, and that individual users can run the /privacy command in the CLI to disable storage and delete previously synced data. Elon Musk stated that all previously uploaded user data would be “fully and unconditionally deleted,” but this statement was made on a social network without accompanying technical documentation.
A significant detail: an independent analysis of version 0.2.99 showed that the upload code is still present in the binary, but is deactivated by a server flag. This means xAI can re-enable the functionality without releasing a client update.
Recommendations
- Secrets rotation: replace all credentials that Grok Build may have read — the contents of tracked files and data from commit history, including secrets that were committed and then removed from the working tree. Deleting a file from the current branch does not remove it from Git history.
- /privacy command: if you continue using Grok Build, run
/privacyin the CLI to disable storage and request deletion of previously synced data. - Network traffic audit: when working with any cloud coding tool, monitor outgoing traffic. The volume of data sent by the tool should be proportionate to the task being performed.
- Secrets storage: do not place real credentials in files tracked by Git. Use secrets managers and environment variables loaded from secure stores.
xAI has still not published a formal security advisory and has not answered three key questions: why full repositories were uploaded by default, how long the data was stored, and how many users were affected. The upload code remains in the binary and is controlled by a server flag that can be changed at any time. For developers who have worked with Grok Build, the top priority is to rotate all secrets that have ever appeared in tracked files or commit history of affected repositories.
