SpaceXAI’s Public AI Coding Tool Uploaded Entire Repositories to Their Servers

SpaceXAI has released a server-side fix for a hidden repository-upload path in its Grok Build command-line AI coding tool. Repeat tests of the same installed client had found that only a remote flag stopped the programmed uploads. Grok Build handles SpaceXAI’s coding workflows and was later publicly released as an agentic coding tool.

Before the server-side fix, version 0.2.93 uploaded entire tracked repositories as a Git bundle, including tracked files and full history. 

Dr. Lukasz Olejnik, an independent security researcher at King’s College London, called the data retention used by Grok Build “excessive”. Potentially exposed material could include proprietary code and credentials, vulnerability information, personal data, and infrastructure details. A stored history can retain sensitive details removed from the latest version alongside current intellectual property.

In a controlled 12 GB test, the service handling the coding request received 196,705 bytes. A separate cloud-storage endpoint accepted more than 5 GB before measurement ended, a roughly 27,800-fold difference. One channel carried data needed for the coding task; the second stored a much broader copy of the project and its history.

By July 14, the installed client received a server-side disable_codebase_upload flag set to true, and repeated tests produced no further uploads. SpaceXAI separately claimed that teams using zero data retention, an account mode under which it says traces and code are not kept, and API-key users had no trace or code data retained. 

How the Separate Upload Path Worked

Grok Build created a Git bundle containing a code project’s tracked files and complete commit history. Cereblab, the security research team that captured and reconstructed the network traffic, found a planted canary file the tool had been instructed not to open. A tracked secrets file that the tool did read traveled without redaction in a model request and was also packaged into a session-state archive intended for storage.

In a separate uploaded-bundle test, the reconstructed bundle preserved full Git history and carried the planted canary, a tracked file the tool had not read. For a developer requesting help with one function, that mechanism could move the project’s recorded history far beyond the task’s narrow file scope.

Captured session archives went to a Google Cloud Storage destination named grok-code-session-traces. The researchers could not determine who could access the stored material or whether it was used for training, leaving access and downstream use outside the demonstrated findings. 

Why the Privacy Command Was Not the Kill Switch

SpaceXAI told consumers outside zero data retention that its command-line interface privacy command could disable retention and delete synchronized data. However, switching off the consumer Improve the model setting did not stop the tested repository upload because retention and codebase uploads used different controls. A server-side flag, not the user-facing setting, stopped storage traffic in repeat tests.

“/privacy is a per-session retention toggle, not the switch that fixed this, so it shouldn’t be pointed to as the control.”

Cereblab researchers, security researchers (via Cereblab)

Remote deactivation does not demonstrate that the path was removed from the client. On July 13, Elon Musk promised that all user data uploaded to SpaceXAI before then would be completely deleted. 

Musk also asked users to permit data retention for debugging while asserting that privacy settings were respected.

The upload capability in the Grok Build binary remained until version 0.2.99 while the server flag held it inactive. A later Grok Build binary that removes this code, rather than receiving another remote flag value, gives users a verifiable product-level fix.