Security research organization Cereblab recently released a wire-level traffic analysis report, revealed that xAI’s official coding assistant Grok Build CLI (v0.2.93) will upload the entire code repository to a Google Cloud bucket controlled by xAI without the user’s knowledge. Affected are not just the files read by the model during the work phase, but the complete contents of the entire Git repository, including historical commit records, deleted secrets, and files that the user explicitly asked the tool to “not open”, all of which were packaged and sent out without the user’s knowledge.
Grok Build was caught secretly passing code
Researcher @hrkrshnn (Hari) released this report on X and characterized it as a “background code collection mechanism with malware characteristics”, causing an uproar in the developer community. Elon Musk later personally came forward and promised to delete all uploaded user data, but xAI has not yet issued a formal information security report.
SpaceXAI was caught uploading your code to its cloud.
I reversed xAI’s official Grok Build binary. In a controlled session with zero tool-calls, it uploaded the complete codebase to xAI’s storage
It ships a malware-like background code collector. https://t.co/1AjmmjiJjU
— Hari (@hrkrshnn) July 13, 2026
Three transmission channels, two of which should not exist
Cereblab used mitmproxy to intercept and record all network requests made during the tool’s use. The analysis revealed three distinct data transmission channels:
- Model channels (expected behavior): The tool sends the files that the user asks the model to read to the Grok API, which is how the AI code assistant normally operates.
- Repository upload channel (unusual behavior): The entire Git repository, including complete historical commit records, is packaged and sent to the Google Cloud Storage bucket in 73 segments
grok-code-session-traces, the endpoint isPOST /v1/storage - Session trace channel (unusual behavior):Include
.envConfidential full file contents are transmitted to xAI’s telemetry servers without any masking
What best illustrates the seriousness of the problem is the comparison of the amount of data. In a 12 GB test repository, the model channel transferred 192 KB of data, while the repository upload channel transferred 5.10 GB, the amount of data required by the model 27,800 times. The researcher did not issue any tool calls (zero tool-calls) during the use of the tool, and the uploading behavior still occurred under this premise.
Cereblab also performed a cross-tool comparison: under the same test conditions, neither Claude Code nor Codex sent any repository archive packages, and Gemini found no similar behavior in idle tests. Grok Build is the only tool that collects the entire code base.
Privacy switch is a decoration
The privacy settings provided by the Grok Build interface have no practical effect at all. After testing, researchers found that the “Improve the model” switch only controls whether the data is used for model training and does not affect the uploading behavior itself. The server continues to post back trace_upload_enabled: true, not affected by local settings.
Another independent researcher @arafatkatze further confirmed that even if /privacy command and set trace_upload_enabled=false, the tool is still directed towards /v1/traces The endpoint issued a request of 7,407 bytes.
Grok Build is straight up malware behavior with an Apple notarized signature.
You could explicitly deny the agent permission to read a file and it would upload that exact file anyway, because a separate code path silently packed your entire repo, full Git history included, and… https://t.co/d0eIbMhice
— Ara (@arafatkatze) July 14, 2026
According to community analysis, various invalid local settings include:
~/.grok/config.tomlin[telemetry] trace_upload = falseIgnored by binary files[features] telemetry = falseAlso invalid- The only setting confirmed to be valid is
[harness] disable_codebase_upload = true, or set environment variables through a shell wrapperGROK_TELEMETRY_TRACE_UPLOAD=false
Even more seriously, researchers .env A canary credential is embedded in the file, which is a fake secret used to verify whether the data has been leaked, and tells the tool “Do not open this file.” As a result, this credential appears intact in the captured upload, without any obscuration, because the repository packaging mechanism operates independently of the tool’s access control process.
xAI knows the existence of this function in advance
Analysis by @arafatkatze points out that Grok Build’s Apple-signed binary contains grok code session traces、after_codebase.tar.gz and disable_codebase_upload and other strings, showing that this code collection mechanism is a deliberately designed function and is not an unintentional loophole.[5] The tool did what it was designed to do, it just didn’t tell the user.
The more important context is that xAI only released the results through the server after the researchers made the discovery public. disable_codebase_upload The flag is set to true, preventing subsequent uploads. Repair occurs as a result of external pressure rather than as a protective mechanism actively designed in advance.
xAI official response: Protection measures only apply to enterprise users
The xAI official account @SpaceXAI issued a statement claiming that enterprise users who use Zero Data Retention (ZDR) “do not retain any code or tracking data at all” and pointed out that API key access will also comply with ZDR. At the same time, within the CLI /privacy Command to disable data retention and delete synchronized data.
But the problem is that ZDR is a function of the enterprise solution. Generally, individual developers do not have this layer of protection under the standard version. In other words, before the incident came to light, most developers using Grok Build were never covered by the protections claimed by xAI.
Elon Musk’s own response further complicated matters. He first tweeted on July 13, stating that “retaining a certain amount of data is helpful for debugging” and hoped that users would allow xAI to continue to retain it. Then in another tweet on the same day, he promised: “As a precautionary measure, all user data previously uploaded by SpaceXAI will be completely and completely deleted without any retention.” Two public statements with opposite positions appeared one after another within a few hours.
This is not an AI derailment, it is a product design choice
In numerous technical analyses, an important clarification point has been repeatedly mentioned: the existing evidence can only prove that the data was transferred and stored in a Google Cloud storage bucket controlled by xAI. It cannot prove that xAI employees have read the captured code, nor can it prove that the captured code is used for model training.
Cereblab’s report clearly defined the scope of the study, and @itsJaimeMedina’s summary also emphasized that the core issue in this incident was “data access beyond what is reasonably expected.” Developers expected the tool to read the archives associated with the task, but did not expect the complete Git history of the entire repository to unknowingly leave the machine.
@DeepThoughtAR’s comment hits the mark: “Someone built, tested, and released a CLI at xAI that behaved this way. The threat comes from design decisions in the product, not the model.” This incident follows a clear pattern: ship, get caught, deactivate. The flag remains unset until someone makes it public.
User’s self-protection checklist
After the incident was exposed, the community compiled the following recommended measures:
- Rotate keys now: If you have ever pointed Grok Build to a repository that contains API keys, passwords, or any secrets, you should rotate the relevant credentials immediately. There are reports that users launching Grok Build from their home directory resulted in SSH keys and password manager databases being uploaded.
- Execute audit script: @hrkrshnn released audit tips and Python scripts on July 14 to query local logs
~/.grok/logs/unified*.jsonlmiddlerepo_state.upload.startandrepo_state.upload.enqueuedevents to identify which repositories were collected - implement
/privacyOrder: You can disable retention and request deletion of synchronized data, but please note that this command was only widely recommended after the incident was exposed. - Use an isolated environment: Test with the canary secret on the throwaway repository before using any AI code helper on the production repository
Source: KOCPC Chinese