Grok Build Repository Upload Scandal: Researcher Confirms Privacy Mode Cannot Stop It
Do Son 
Last week, security researcher @Cereblab exposed a troubling behavior in Grok Build. The tool silently transmitted developers’ entire local repositories to cloud storage without explicit authorization. Under normal circumstances, a coding assistant should only send the code snippets required for a given task. Instead, Grok Build uploaded complete repositories. Moreover, the destination was not the model itself but Google GCP storage buckets.
Unsurprisingly, the revelation triggered widespread concern across the developer community. Project repositories frequently contain credentials, API keys, and other sensitive data. Furthermore, the evidence suggests SpaceXAI harvested this repository data for future model training. Such practices risk leaking confidential information. At the same time, they trample on the privacy rights of developers.
SpaceXAI’s Response: “Just Enable Privacy Mode”
Late last night, SpaceXAI issued a statement addressing the repository upload controversy. According to the company, developers can activate privacy mode through the /privacy command. By default, however, Grok Build operates in data-sharing mode. This means SpaceXAI collects usage data to improve its products and models. Once a developer enables privacy mode, data sharing stops. In addition, the company promises to delete any data already sent to the cloud.
On the surface, this sounds like a reasonable solution. Yet the original statement conveniently dodged the central question: why does the tool collect entire project repositories in the first place? In fact, follow-up findings from @Cereblab show the statement is pure misdirection. The /privacy command does nothing to prevent repository uploads.
Privacy Mode Has Nothing to Do With Repository Uploads
The researcher’s initial analysis already identified the true control mechanism. Grok Build decides whether to upload a full repository based on a cloud-issued HTTP request header. After the exposure, SpaceXAI quietly disabled repository uploads on the server side. That kill switch remains off today. Consequently, developers can verify this themselves by inspecting the request header. A value of disable_codebase_upload: true means repository uploads are blocked. Previously, the value was false, which permitted uploads.
To be clear, Grok Build runs two separate data collection channels. The first channel is the product-improvement pipeline governed by /privacy. It covers only the code snippets sent to the model. If a user opts out of data sharing, SpaceXAI deletes the stored data from this channel.
The second channel is the critical one: full repository uploads. This channel answers exclusively to the HTTP request header. Therefore, when the cloud instructs the client to upload a repository, opting out of data sharing accomplishes nothing. The /privacy command was never designed to control repository uploads. As a result, SpaceXAI’s public statement amounts to deliberate obfuscation.
The Real Fix: Remove the Header Control Entirely
Following SpaceXAI’s statement, @Cereblab re-ran the verification tests. The researcher confirmed that /privacy applies only to the telemetry channel. In sharing mode, that channel transmits roughly 18KB per send. By contrast, repository uploads can reach 5GB or more. One user even reported that the tool transmitted over 100GB of data.
Accordingly, the only genuine remedy is structural. SpaceXAI must strip both the request header and the upload path from future releases. Only after their removal would the cloud lose its remote switch over developer repositories. For now, the upload function remains disabled server-side. Consequently, no repositories are currently being sent to the cloud, regardless of whether developers opt out of data sharing.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
