Elon Musk Acknowledges Grok Build Uploaded User Code, SpaceXAI Vows Full Data Deletion

Elon Musk has acknowledged that Grok Build uploaded complete code repositories to company-controlled cloud storage even when users had disabled the “help improve model” option.

The finding came from Cereblab, a pseudonymous independent AI-safety researcher with no stated vendor affiliation. In a reproducible wire-level demonstration, the researcher tested Grok Build CLI v0.2.93 on macOS by routing its HTTPS traffic through mitmproxy with a locally trusted certificate. A 12GB test repository generated 5.1GiB of storage traffic across 73 chunks, while the model conversation used about 192KB.

Musk subsequently promised that previously uploaded user data would be deleted. SpaceXAI also pointed consumers to a /privacy control for managing retention; the company’s official command documentation describes it as showing or toggling privacy and data-retention status.

The incident highlights a gap between a control governing model training and the separate question of whether code leaves a user’s machine. Developers who interpreted the toggle as preventing uploads may therefore have misunderstood its scope.

The event puts pressure on SpaceXAI to prove that its server-side change stops repository transfers and that retained material has been removed. It also raises broader questions for developers assessing cloud-based coding agents that need some remote code access to answer prompts.

Grok Build is SpaceXAI’s terminal-based AI programming agent. Although some coverage has called it an “xAI tool,” current official product materials identify Grok Build as a SpaceXAI product hosted on the x.ai domain. “SpaceXAI” is therefore the company name used here, while Grok Build is the product and Grok is the underlying product family.

Cereblab’s strongest test used the prompt “reply OK, do not open any files.” Grok Build nevertheless sent a Git bundle through POST /v1/storage; cloning the captured payload recovered 47 files, four commits, full history, and a canary file the agent had been instructed not to read. The reported destination was a Google Cloud Storage bucket named grok-code-session-traces.

The transfer was encrypted in transit with HTTPS, but the researcher could inspect it after installing a local trusted certificate. Public evidence does not establish the bucket’s at-rest encryption configuration, access history, geographic location, or retention period.

A separate user posting as @a_green_being reported 339 repo_state.upload.enqueued log events across four repositories, including one whose recorded repository path was the user’s home directory. That account supports the possibility of broader collection, but it is a user report rather than an independently audited forensic result.

Musk’s acknowledgment followed the disclosures. Axios reported that he promised a complete deletion of data uploaded before the announcement. SpaceXAI said zero-data-retention customers did not have trace or code data retained and later disabled default retention. No independent audit has yet confirmed the deletion.

The core tension is between what users reasonably inferred from the visible training toggle and what the tests showed. Cereblab found that disabling model improvement did not initially prevent repository packaging or transmission: the server still reported trace_upload_enabled: true.

That distinction matters. A company can refrain from using code for training while still transmitting or retaining it for debugging, trace storage, or another operational purpose. SpaceXAI characterized retention as useful for debugging and said its zero-data-retention arrangements were respected, but it has not published a complete incident report explaining why full repositories and Git history were collected by default.

The evidence also has limits. Cereblab tested early CLI version 0.2.93 on two controlled repositories, not every operating system, account tier, configuration, or release. The tests demonstrate the behavior under those conditions; they do not establish how many customers were affected or whether SpaceXAI employees or third parties accessed stored code.

Cereblab later repeated the test six times with the same binary and observed no storage uploads after SpaceXAI changed server settings to disable_codebase_upload: true and trace_upload_enabled: false. That indicates a server-side mitigation, although it does not prove deletion of previously retained data.

Developers with proprietary code on machines running affected Grok Build versions are the group most directly affected. In practice, a repository bundle can contain more than the files visible in the current checkout: Git history may preserve deleted credentials, internal endpoints, customer identifiers, or unreleased source code.

Users can inspect ~/.grok/logs/unified.jsonl for repo_state.upload events and confirm which path Grok treated as the repository root. Anyone who finds that secrets may have left the machine should rotate those credentials; deletion from cloud storage cannot undo possible prior access.

To reproduce the original researcher’s narrow test, an investigator would need Grok Build v0.2.93, a disposable Git repository containing a unique canary, and an HTTPS inspection proxy installed only in an isolated test environment. The test prompt should instruct the agent not to read files, after which the investigator can compare model traffic with /v1/storage requests and attempt to clone any captured Git bundle. This should never be performed on a production repository.

SpaceXAI has not disclosed the total number of affected accounts, the full operating period of the upload feature, bucket-access logs, or a third-party deletion verification. Its enterprise terms generally allow some exceptions to deletion obligations, while the company says Grok Build users with zero-data-retention agreements were not subject to retention.

The /privacy command provides a clearer control point, but it governs retention rather than serving as proof that no code is transmitted for inference or other processing. Users should verify both network behavior and account-level retention status instead of treating the command as an offline mode.

Cereblab reported that equivalent idle-prompt tests against Claude Code, OpenAI Codex, and Gemini did not produce complete repository bundles; those tools transmitted files they opened. This is a useful controlled comparison, but it is not a comprehensive security ranking and may change across versions and configurations.

SpaceXAI has since open-sourced the Grok Build harness, giving independent reviewers more visibility into repository packaging and upload paths. Source review can improve accountability, although server-side configuration and deletion remain outside the client code’s verifiable scope.

Users should watch three signals over the next three months. First, a detailed company incident report or independent audit confirming what was deleted, when deletion completed, and whether stored repositories were accessed. Second, documentation separating model-training consent, operational transmission, debugging retention, and zero-data-retention behavior. Third, independent attempts to reproduce the original /v1/storage transfer on current releases.

If none appears, uncertainty about historical retention and deletion will remain. If SpaceXAI publishes verifiable logs, defines retention precisely, and current builds withstand repeat testing, it can begin narrowing the gap between its stated policy and observed behavior.

For teams evaluating AI coding agents, the practical lesson is narrower than rejecting cloud tools altogether: run new agents inside disposable repositories, keep secrets outside reachable working directories, monitor outbound traffic, and confirm retention terms before granting access to private code.