What happened
Grok Build, xAI’s terminal-based coding agent, was uploading complete Git repositories to company-controlled cloud storage. The transfer could include files the agent never opened and secrets preserved in the project’s Git history.
An independent researcher publishing as CEREBLAB captured the traffic and reconstructed the uploaded repository. The test used Grok Build 0.2.93 with a simple instruction: reply with “OK” and do not open any files. Grok followed that instruction, but the background upload still sent a Git bundle to a Google Cloud Storage bucket.
Cloning that captured bundle recovered the full test repository. It included a file the agent had never read, four commits, and the project’s reachable Git history. Turning off the “Improve the model” setting did not stop the upload.
A separate controlled test by Hari Krishnan produced the same basic result. Krishnan reported that Grok Build sent every tracked file at the current Git commit, every reachable Git object, and files deleted from the current project but still present in its history.
The repository upload has now been disabled. CEREBLAB retested the same client on July 13 and found that xAI’s server was returning a global setting called disable_codebase_upload. Grok Build no longer initiated the transfer. The researcher also tested version 0.2.99 and reported that the upload remained off.
Why it matters
Sending code to a remote model is a normal part of using most cloud-based coding agents. The model needs the contents of relevant files before it can reason about them. Uploading an entire repository in the background is a different data decision, especially when the task does not require any files.
Git history makes the potential exposure larger than the current project folder suggests. Deleting an API key from a file does not remove it from earlier commits. If that old commit remains reachable in the repository, the key can still be included in a Git bundle.
This distinction is easy to miss if you are building without an engineering or security team. A clean .env file today does not prove that a credential never appeared in the project’s history. Removing a secret and rotating it are also different actions. Rotation disables the old credential at the service that issued it.
The privacy controls add another complication. CEREBLAB found that Grok Build’s newer /privacy command changes the server’s data-retention setting. It does not stop the ordinary model requests needed to use a cloud coding agent. SpaceXAI says teams with zero data retention enabled do not have trace or code data retained, and its enterprise documentation describes zero data retention for Grok Build.
On July 16, SpaceXAI published the Grok Build harness under the Apache 2.0 license. The released code covers the agent runtime, tools, terminal interface, and extension system. SpaceXAI also said builders can compile it and use their own local inference.
In a privacy follow-up, SpaceXAI said it turned off default retention for all Grok Build users on July 12. The company also said it was deleting all coding data previously retained. These are important changes, but publishing the client does not independently verify deletion or reveal every server-side process.
Several questions remain unanswered publicly. SpaceXAI has not said how many users were affected, how long the repository upload operated, whether anyone accessed the stored data, or how users can confirm deletion. The public Grok Build changelog still does not document the repository-upload issue or its server-side shutdown.
Who should care
Anyone who ran Grok Build inside a private or commercial repository before July 13 should pay attention. The risk is higher if the repository ever contained API keys, cloud credentials, database passwords, access tokens, or private configuration values in tracked files.
Users who only tried Grok Build on disposable test projects have less to worry about. Teams with a confirmed zero-data-retention agreement also have a different retention posture, although they may still want an internal record of what the tool transmitted.
What builders should do next
Update Grok Build before using it again. The repository upload was disabled remotely, but running the latest client avoids relying on an older binary and gives you the current privacy controls.
If you used an affected version on real work, review the repository for credentials that were committed at any point, including credentials later deleted from the visible files. Rotate anything sensitive through the dashboard of the service that issued it. Do not assume deleting the local file or rewriting the current code invalidates the old key.
Finally, treat data transmission and data retention as separate questions when evaluating any coding agent. Ask what leaves your machine, what gets stored, for how long, and which setting controls each behavior. A promise not to train on your code does not necessarily mean the code was never uploaded.
The practical takeaway is not to avoid every cloud coding agent. It is to give these tools access only after you understand their data boundaries, because an agent’s permissions are only part of the risk. Its network behavior matters too.
End of article