www.it-connect.fr
Grok Build: SpaceXAI’s CLI Was Uploading Entire Code Repositories to Google
A researcher took a close look at SpaceXAI's official CLI, and the results are alarming. According to a network analysis published on GitHub, the grok tool (Grok Build) version 0.2.93 does not merely send SpaceXAI the files it reads to help you. No, it's much worse: it uploads the entire repository, Git history included, to a Google Cloud bucket, even when you explicitly ask it not to read anything. It's an all-inclusive deal, since it also ships .env files and secrets.
As a reminder, SpaceXAI (formerly xAI) is the artificial intelligence company founded by Elon Musk in 2023, and Grok is its family of models, here available as Grok Build, a command-line code assistant.
An Entire Repository, Not Just the Files Being Read
At the origin of the issue is a researcher using the pseudonym cereblab. The method is reproducible: route the Grok Build CLI 0.2.93 (consumer account, not an API key) through a proxy (he used mitmproxy on macOS), then observe every outbound request.
The researcher identifies two channels. The first, POST /v1/responses, corresponds to the model turn and carries the files the agent actually opens to handle your request. The second, POST /v1/storage, sends something else entirely: a snapshot of the complete repository. In both channels, the contents of the files read, including a .env file, are transmitted as-is, with no attempt at confidentiality. In other words, API keys and other passwords stored in that file reappear word for word in the traffic.
The problem is the second communication channel. On a 12 GB test repository made up of random files, this channel transferred 5.10 GB of data, while the model's first channel carried only 192 KB. The model did not ingest those files, and yet more than 5 GB of data left the machine.
And even when you tell it not to open a single file, Grok sends the entire repository as a git bundle. By cloning that captured package, the researcher recovered a file the agent had been instructed not to open, along with the full Git history. This experiment was reproduced several times by the researcher, including with separate repositories.
According to him, this data is exfiltrated to a Google Cloud Storage bucket: a destination that is even specified in plain text in the metadata.json file. On the local machine, the staging directory ~/.grok/upload_queue can grow to several dozen GB and fill up the disk. Clearly, machine storage space is being put under pressure these days...
SpaceXAI Cut the Flow, Without Saying a Word
About a day after the researcher's analysis started circulating, he relaunched the same 0.2.93 client and reportedly no longer observed any uploads. Strange, right? In reality, the server was returning a new field, disable_codebase_upload: true, along with trace_upload_enabled: false, and no repository upload was observed across 6 consecutive tests. This appears to have been a server-side change, quietly rolled out by SpaceXAI's teams.
For its part, SpaceXAI has published nothing about this: no note, no explanation. The changelog lists version 0.2.98 as the latest on July 12, 2026, with not a word about this upload behavior.
Many questions remain unanswered: when did these transfers begin? How many repositories are affected? Which repositories are stored on Grok's servers? In practice, anyone who pointed this tool at a private or proprietary repository would, in effect, have sent SpaceXAI a copy of their code, their history, and their secrets.
At this stage, we also do not know what SpaceXAI is doing with this data. Nothing indicates that the models are trained on the collected data. This kind of drift is not isolated. Security issues with AI tools are numerous. Recently, I also told you about the SearchLeak flaw that turned Copilot into a one-click data theft tool.
You can find the researcher's analysis on GitHub.
