SpaceXAI’s Grok Build coding tool came under scrutiny after a security researcher found that its CLI was uploading entire Git repositories t...
SpaceXAI’s Grok Build coding tool came under scrutiny after a security researcher found that its CLI was uploading entire Git repositories to cloud storage rather than sending only the files required for a coding task.
The uploaded data reportedly included tracked files, full Git history, files the agent had been instructed not to read, and secrets that had been deleted from the current working tree but remained in earlier commits. The destination was a Google Cloud Storage bucket controlled by xAI.
After the findings were published, the upload behavior stopped. The researcher observed that SpaceXAI’s server began returning:
disable_codebase_upload: true
Elon Musk also said previously uploaded user data would be completely deleted. However, independent confirmation that every historical copy has been removed was not publicly available when the incident was reported.
The incident began with a controlled network analysis of the Grok Build CLI.
The researcher, publishing under the name Cereblab, reverse-engineered the official binary and monitored its network traffic. In a test designed to reveal the tool’s actual data flow, Grok Build packaged the repository as a Git bundle and uploaded it to a Google Cloud Storage bucket associated with xAI.
This was not limited to the few files needed to answer the prompt.
The captured bundle reportedly contained:
The original AIbase report describes the retention scope as substantially broader than that of comparable AI coding tools such as Claude Code.
In one test reported by Axios, Grok Build uploaded approximately 5.1 GB of data even though the coding task itself required only about 192 KB. That example illustrates the difference between sending task-relevant context and transferring a complete repository archive.
Uploading a current source tree is already a serious security event. Uploading full Git history can be more damaging.
Developers often remove a secret from the latest version of a repository and assume it is gone. In reality, the value may remain accessible in older commits unless the history has been rewritten.
Git history may contain:
A repository can therefore look clean in the current working tree while still carrying sensitive material inside .git.
This is why instructions such as “do not open this file” are not an adequate protection when the tool separately packages the repository at the Git level. A file-level permission instruction may control what the agent reads during the model conversation, but it does not automatically prevent a separate upload pipeline from bundling repository history.
Cereblab’s analysis identified the destination as an xAI-controlled Google Cloud Storage bucket.
Using Google Cloud does not mean Google independently decided to collect the repository. Cloud storage providers host infrastructure for customers, and the relevant data controller or service operator in this case was reported to be xAI or SpaceXAI.
The important issue is that repository data left the user’s machine and entered third-party cloud infrastructure.
For enterprise teams, that can trigger questions involving:
Even when the cloud provider itself has strong security controls, an undisclosed or unexpected transfer can violate a company’s own governance requirements.
After the investigation became public, Cereblab tested the CLI again.
The server returned:
disable_codebase_upload: true
The whole-repository upload no longer triggered.
This appears to have been a server-side change because users did not need to install a new version before the behavior stopped. A remote configuration flag disabled the repository-bundling pipeline.
That distinction matters.
A server-side switch can stop the behavior quickly, but it also shows that the client’s data-handling behavior may depend on remote configuration. Organizations evaluating coding agents should therefore verify actual network traffic and not rely only on a local version number or a static settings screen.
Elon Musk responded publicly by saying that all user data uploaded before the change would be “completely and utterly deleted,” with nothing remaining.
SpaceXAI also said that privacy choices would be respected and that customers covered by zero-data-retention arrangements would not have trace or code data retained.
These are important commitments, but several questions remained open at the time of reporting:
Deletion reduces future exposure, but it does not automatically resolve every security concern. If a repository contained active credentials, users should assume those values may have left the local environment and rotate them.
/privacy Command Was Not the Real FixSpaceXAI initially pointed users to the Grok Build CLI command:
/privacy
Official Grok Build documentation describes /privacy as a command that shows or changes privacy and data-retention status.
The security researcher found that this setting controlled retention behavior rather than the underlying transfer of the complete repository bundle. In other words, the command could affect what SpaceXAI retained after receiving data, but it was not the server-side mechanism that stopped the repository from leaving the machine.
Cereblab’s conclusion was clear:
/privacy was a per-session retention control.disable_codebase_upload was enabled.This is one of the most important lessons from the incident.
| Control Question | Meaning |
|---|---|
| Does data leave the device? | Transmission or upload control |
| Is received data stored? | Retention control |
| How long is it stored? | Retention-period policy |
| Is it used for model training? | Training-use policy |
| Can the user delete it? | Deletion control |
| Can the user verify deletion? | Audit and assurance control |
A service may promise not to retain data and still transmit it for real-time processing. That may be acceptable under a clearly documented enterprise arrangement, but it is not the same as keeping the data local.
Users should not interpret “zero data retention” as “zero data transfer” unless the product explicitly makes that guarantee.
xAI’s API security documentation describes Zero Data Retention as an enterprise feature.
When ZDR is enabled for an API team, xAI says prompts, completions, and associated metadata are processed in real time but are not persisted to its servers. The documentation also says API responses include an x-zero-data-retention header so applications can check whether ZDR is active.
For standard API use without ZDR, xAI says requests and responses may be stored temporarily for up to 30 days for abuse and misuse auditing.
These API policies are useful, but organizations should not automatically assume that every Grok product, CLI trace, file-transfer channel, or consumer account follows the same data lifecycle.
Before using Grok Build with private repositories, verify:
Independent security researcher Dr. Lukasz Olejnik described the scale of data retention as excessive.
The potentially exposed information could include:
The risk is not limited to intentional misuse.
Large code archives can also be exposed through:
The principle of data minimization exists to reduce this attack surface. A coding assistant should receive the minimum information required to perform the requested task.
Uploading an entire repository by default is difficult to reconcile with that principle when only a small number of files are needed.
Teams that used Grok Build before the upload was disabled should respond as they would to any potential source-code exposure.
Review where Grok Build was run.
Record:
Do not limit the review to files the agent appeared to open.
Use your organization’s approved secret-scanning tools to inspect the full history, not only the current branch contents.
Look for:
A secret that was deleted from the latest commit may still require rotation.
Describe your idea once, and We0 AI can generate a showcase site, pages, and CMS, then help you attract customers and traffic after launch.
One complete project generation for free registration
Best for trying one complete generation flow and seeing a first project draft quickly.
If a credential existed anywhere in the tracked repository history during the affected period, revoke or rotate it.
Do not wait for proof that someone accessed the uploaded copy. Credential rotation is usually cheaper than investigating a later compromise.
Prioritize credentials that provide:
Check cloud, source-control, CI/CD, database, and internal-service logs for unusual activity after the repository was used with Grok Build.
Look for:
Absence of suspicious activity does not prove the data was never exposed, but it can help assess immediate risk.
Use the current Grok Build release and review the active configuration.
Official documentation provides:
grok inspect
This command helps confirm which configuration sources are being loaded.
The CLI also provides:
/privacy
Use it to review retention status, but remember that the command should not be treated as proof that no data leaves the device.
Enterprise users should request written answers covering:
A public deletion promise is helpful, but regulated organizations may need account-specific evidence.
If the repository contained customer code, personal data, regulated information, or content covered by an NDA, involve the appropriate internal teams.
Depending on the context, this may include:
Do not make a breach-notification decision based only on a news article. Use the facts of the organization’s own exposure and applicable law.
The incident highlights a broader problem across AI development tools.
Coding agents often request extensive access because they need to search large repositories, run commands, read documentation, and modify files. That power creates a large privacy boundary.
Before approving a coding assistant, teams should evaluate five areas.
Document every category of data the tool can collect:
Test what actually leaves the machine.
Vendor documentation is necessary, but network behavior is the strongest evidence of actual transmission.
Use an isolated test repository containing harmless canary values, then inspect:
Do not run the tool from a directory that contains unrelated projects.
Prefer:
For enterprise deployment, confirm:
A tool’s behavior can change after an automatic update or remote configuration change.
Re-test after:
Security approval should not be permanent when the product is changing rapidly.
Agent instructions operate at the model or tool-use layer. A separate telemetry or synchronization component may not interpret those instructions.
Privacy controls need to exist in the data pipeline itself.
A vendor can say it sends only necessary context, but enterprise users need evidence.
Useful assurances include:
Remote configuration made it possible to stop the upload quickly. It also means users may not know when important behavior changes.
A mature response should include:
Even if SpaceXAI deletes every stored copy, any credential included in an uploaded repository should be treated according to its exposure risk.
Deletion protects future access to the vendor’s copy. It does not change the credential itself.
Cereblab’s wire-level analysis found that the CLI uploaded an entire tracked Git repository as a bundle, including commit history and files unrelated to the immediate coding task. That history could include secrets removed from the current working tree.
The captured traffic showed uploads to a Google Cloud Storage bucket controlled by xAI. Google Cloud was the infrastructure provider; the relevant product and data-handling decisions were attributed to SpaceXAI.
The researcher later observed the server returning disable_codebase_upload: true, after which the whole-repository upload no longer triggered. The change appeared to be server-side.
/privacy command prevent repository uploads?The command controls privacy and retention settings, but Cereblab reported that it was not the mechanism that stopped the full-repository upload. Users should distinguish between preventing transmission and limiting retention after transmission.
Yes. Musk publicly said all previously uploaded user data would be completely deleted. Independent verification of the full deletion was not publicly available at the time of reporting.
If a secret existed in the tracked repository or its Git history while Grok Build was used, rotation is a prudent response. Deletion of the vendor’s stored copy does not guarantee that a credential was never exposed or accessed.
xAI describes ZDR as an enterprise API feature that processes inputs and outputs without persisting them. It does not necessarily mean that data never leaves the local device, and organizations should verify which Grok Build data channels are covered.
The reported whole-repository upload has been disabled, but each organization must evaluate the current version, settings, account terms, network behavior, and repository sensitivity. A server-side fix does not replace internal security review.
/privacy.Grok Build was found uploading entire tracked Git repositories and their histories to an xAI-controlled Google Cloud Storage bucket, even when only a small amount of code was required for the task.
SpaceXAI disabled the repository upload through a server-side disable_codebase_upload flag, and Elon Musk promised that previously uploaded data would be deleted. The /privacy command addressed retention settings but was not the control that stopped repository transmission.
Developers who used the affected CLI should identify repositories, scan full Git history, rotate potentially exposed credentials, review logs, and request account-specific deletion information where necessary.
The central lesson is simple: an AI coding tool’s privacy must be verified at the data-transfer layer, not inferred from prompts, retention labels, or a settings screen.
Start from one sentence and have a complete website in minutes.
