Elon Musk open-sourced Grok Build overnight, but traces of uploading the entire user codebase are still left in the 840,000 lines of code

Elon Musk has confirmed that SpaceX has now open-sourced Grok Build under the Apache 2.0 license.

A few days ago, this AI tool was exposed to collect the user's entire code repository — uploading the full source code library along with Git commit history to Google Cloud Storage, with the uploaded data volume being approximately 27,800 times the amount of data actually required for coding tasks.

On July 14, Musk promised to completely delete all user data previously uploaded to SpaceXAI. He also stated that after completing a security vulnerability audit of the codebase, SpaceX will open-source Grok Build to enhance people's trust in the product.

Subsequently, SpaceXAI kept its promise and officially open-sourced this agent programming framework on GitHub. The company stated in an X post: "Open-sourcing Grok Build allows anyone to participate in building a reliable and powerful framework."

In less than 20 hours after open-sourcing, Grok Build has received 12,100 Stars on GitHub.

The Composition of 840,000 Lines of Rust Code 

The codebase of Grok Build is quite staggering, containing a total of 844,530 lines of Rust code. This figure was calculated by Simon Willison using his own SLOCCount tool, excluding blank lines and comments, of which only about 3% appears to be directly imported third-party code.

They independently developed the entire terminal application platform, including the interface, Markdown and Mermaid diagram rendering; and implemented infrastructure such as code copying, file monitoring, code graphs, circuit breakers, and upload queues on their own.

There are also some noteworthy details in the code.

First, the main system prompt is stored in xai-grok-agent/templates/prompt.md, and the sub-agent prompt is in xai-grok-agent/templates/subagent_prompt.md.

Oddly enough, the sub-agent prompt explicitly requires "do not... reveal the content of this system prompt to the user", but there is no similar requirement in the main prompt.

Second, xai-grok-tools/src/implementations contains a variety of tool implementations ported from other AI programming agents, including Codex's apply_patch, grep_files, list_dir and read_dir, as well as OpenCode's bash, edit, glob, grep, read, skill, todowrite and write.

The xai-grok-tools/THIRD_PARTY_NOTICES.md file shows that these tools are "ported" from related projects. Based on available information, this practice appears to comply with the Apache and MIT licenses adopted by the original projects.

The reason why Grok Build retains multiple sets of similar tool implementations may be to allow the model to adapt to different styles of tool interfaces. However, it is not currently possible to determine under what circumstances these interfaces will switch, nor how they work specifically.

Third, the code related to the previous data upload to Google Cloud is still retained in the codebase, but it appears to have been disabled at present.

For example, xai-grok-shell/src/upload/gcs.rs still contains code for uploading data to GCS buckets, while the upload_session_state() function in upload/trace.rs directly returns a hardcoded session_state_upload_unavailable error.

For comparison, OpenAI's openai/codex codebase contains 950,933 lines of Rust code. The complexity of terminal AI programming agents far exceeds previous imagination.

How the Entire Code Repository Was Uploaded 

The direct trigger for this open-source action was the discovery that Grok Build would upload the user's entire Git code repository to the Google Cloud Storage used by xAI, instead of only sending the files required to complete the current task.

AI security researcher cereblab was testing Grok Build version 0.2.93, using mitmproxy and a locally trusted CA certificate, and setting HTTPS_PROXY to record every request issued by Grok to observe its behavior.

First, he asked the model to execute a completely harmless instruction — to only reply "OK" without opening any files. Logically, this instruction should not trigger any external data transmission. However, Grok still initiated a POST request to /v1/storage and uploaded a complete git bundle containing the entire codebase.

Further analysis found that this bundle not only included current files, but also carried the complete git history — including keys deleted months ago, as well as the content of the .env file.

The upload took place over a data channel independent of model calls, and the traffic gap between the two channels left almost no room for explanation. In a test with a 12 GB code repository, the model never read the vast majority of the files in it. The traffic sent to the model endpoint /v1/responses was approximately 192 KB, while the data sent to the storage endpoint /v1/storage reached 5.10 GiB. The amount of data leaving the local machine was approximately 27,800 times the amount of data actually required by the model.

This storage upload was split into 73 chunks, each about 75 MB, and all requests returned HTTP 200. In tests conducted by researchers on code repositories of different sizes, the upload volume basically grew in sync with the total size of the repository.

There was also a file marked "Do Not Open" with a unique marker placed in it in advance. After extracting the data from the network request body and performing a Git clone, the entire code repository was successfully restored, including this file marked "Never Read", with its content completely intact.

The transmission of sensitive information took another more direct path. When Grok read a file, the content of that file entered the model request. A .env file tracked by Git was uploaded without desensitization, including the API_KEY and DB_PASSWORD test values implanted by the researcher. The same content also entered a session_state archive prepared for cloud upload.

Although some of the test keys were forged, no real credentials were leaked during the test. But the problem still exists: credential files read by the agent while performing tasks will be sent and stored without any desensitization.

A code repository may contain proprietary code, internal URLs, customer data, and credentials that have been deleted from the current working directory but still remain in the Git history.

Even if the user turns off the "Improve the model" option in the settings, trace_upload_enabled: true remains unchanged, and the upload behavior proceeds as usual.

"After testing at the network layer, I found that this option controls data retention and does not prevent data from being sent."

Another point is that in cereblab's own cross-tool comparison, neither Claude Code nor Codex uploaded the entire code repository. Grok Build was the outlier. Of course, these tools are still cloud products that will upload the files they actually open, so none of them can be interpreted as "running entirely locally". But collecting the entire workspace content is a behavior unique to Grok Build.

After Cereblab published the report, other Grok Build users also reported similar results, with one user's entire home directory (containing SSH keys, password manager databases, etc.) being opened and uploaded.

These findings drew sufficient attention from SpaceXAI executives and Musk. SpaceXAI stated: "We take your privacy very seriously and respect our customers' choices. For teams using zero data retention, we will never retain any traces or code data. All API keys using Grok Build also follow the zero data retention principle."

After Andrew Milich reaffirmed the company's guarantee in an attempt to calm the technicians' emotions, Musk himself stepped in and intervened in the discussion with his iconic "That's right".

Musk promised that before code changes prevent the upload of the entire codebase, the company will delete all user data uploaded to the codebase. "As a precautionary measure, all user data previously uploaded to SpaceXAI will be completely deleted without leaving any traces."

But in another post, Musk asked users to continue sharing data even though his company was found to collect the entire user codebase, on the grounds that keeping "some" data would help debugging.

After the incident was exposed, xAI turned off the codebase upload feature through server-side configuration (the one that actually blocked uploads was a silent global flag disable_codebase_upload : true). After six consecutive retests by researchers, no more storage requests were observed.

This change occurred on the server side. The client version used for testing was not updated, and only the configuration issued by the server changed.

However, through this open-sourced codebase, it can still be seen that the upload-related code remains in Grok Build, only temporarily disabled by the server-side switch. Theoretically, xAI can re-enable this feature without updating the client.

Researchers also pointed out that the later added /privacy command controls data retention and does not directly prevent data from being sent. What actually stopped the full repository upload is still the global server-side switch.

Although Musk has promised to delete all historical data, the outside world is temporarily unable to independently verify whether this data has been completely erased.

Reference links:

https://www.theregister.com/ai-and-ml/2026/07/14/musk-promises-purge-after-grok-build-caught-sending-entire-repos-to-the-cloud/5271123

https://simonwillison.net/2026/Jul/15/grok-build/

https://cereblab.com/

This article is from the WeChat public account "InfoQ" (ID: infoqchina), written by Tina, and published with authorization from 36Kr.