Grok Build version 0.2.93 uploaded complete tracked Git repositories and their recorded commit histories to cloud storage in tests conducted before a server-side shutdown, according to reporting by WinBuzzer and a wire-level analysis published by independent researcher Cereblab. For Windows developers and administrators who ran the public AI coding CLI against company projects, the immediate concern is not merely what the agent read for a prompt: it is whether source code,
The reported behavior matters because Git history is often more sensitive than the checked-out working tree. A token removed months ago, a configuration file rewritten before release, or a vulnerability fix that exposes the original flaw can remain in prior commits even when it no longer appears in the current source tree.
Cereblab’s testing found that the broad upload path was distinct from the traffic used to submit a coding request. In one controlled 12 GB repository test, the normal model-request channel transferred roughly 196 KB, while a separate storage channel accepted more than 5 GB before the test was stopped. The Hacker News independently described the same core finding: a Git bundle was sent through a separate storage endpoint rather than limiting transmission to files needed for the active task.
The distinction between “the tool can access code” and “the tool sends the repository” is the center of this incident. Cloud coding agents necessarily transmit some material when developers ask remote models to analyze or modify files. That is an expected trade-off, and one that security teams can document, restrict, and approve.
A full Git bundle changes the scope. According to Cereblab, Grok Build packaged tracked content along with commit history, including files that the agent had explicitly been told not to open. The researcher also reconstructed the captured bundle and found a planted canary file inside it, despite the test instruction directing the tool not to read that file.
That makes conventional prompt hygiene an inadequate safeguard. Telling an AI agent to avoid a directory, limiting a request to one function, or opening only a single solution folder does not protect a repository if the client’s collection layer independently packages tracked data. On Windows development machines, that can encompass application source, deployment scripts, PowerShell automation, Azure configuration, test fixtures, and secrets that were committed by mistake before being removed.
The issue is especially uncomfortable for teams that treat a
Those assurances need to be separated from the observed upload behavior. Cereblab reported that disabling the consumer-facing model-improvement setting did not stop the repository bundle from leaving the test machine. The research instead found that the client subsequently received a server-controlled setting,
That is a meaningful mitigation, but it is not the same as a new client binary with the code path removed. The same installed Grok Build 0.2.93 client reportedly changed behavior after receiving the remote configuration. WinBuzzer reported that upload-related capability remained present through version 0.2.99 even while the server flag held the behavior inactive.
For enterprise IT, that difference is practical rather than philosophical. A remote feature flag can shut down risky behavior quickly, which is valuable during an incident. But it also means a client can contain functionality that administrators cannot fully assess from a version number alone, and whose behavior may change without a conventional Windows software update, MSI deployment, or release-note review.
What remains unresolved is equally important. The researchers identified the Google Cloud Storage destination as
Elon Musk said on July 13 that all user data uploaded before that date would be completely deleted. As of July 16, there is no independent public evidence demonstrating that historical uploads have been deleted, nor a formal vendor security advisory detailing affected versions, retention periods, account scope, access controls, or an auditable deletion process. A promise may be relevant to users deciding whether to continue with the service, but it is not a substitute for incident documentation.
SpaceXAI’s zero-data-retention statement may also reduce risk for customers who can prove they were covered by that arrangement at the time of use. It does not automatically answer whether a particular developer account, consumer subscription, or locally installed client was configured under ZDR when a repository was processed. Administrators should verify that status through contractual records and account controls rather than infer it from today’s settings.
The first priority is rotating credentials that were present anywhere in affected Git history: cloud access keys, GitHub or Azure DevOps tokens, package-registry credentials, certificates, database passwords, service-account secrets, and private API keys. Revoking and replacing a token is materially safer than assuming that an old commit or deleted configuration file is harmless.
Security teams should also preserve local evidence before clearing it. Endpoint telemetry, proxy logs, firewall records, DNS logs, VPN egress data, and Grok Build logs may help establish which devices used the tool, when they did so, and which repository roots were involved. For a Windows fleet, Microsoft Defender for Endpoint device timelines and network telemetry may be useful if the organization has retained the relevant period.
A short internal inventory should identify the Grok Build versions in use, the users and endpoints that executed them, the repositories opened in each session, whether those repositories contained tracked secrets or regulated data, and whether the organization had an active zero-data-retention agreement. This is also a case for checking developer workstations outside the usual managed build infrastructure; AI coding CLIs are often installed in user profiles and run from PowerShell, Windows Terminal, or integrated developer shells without passing through formal software approval.
Administrators evaluating coding assistants should inspect the collection layer: what the client enumerates, what it archives, what it uploads, what feature flags govern that behavior, and whether network controls can enforce the claimed boundary. A vendor privacy toggle that changes retention policy is not necessarily a technical guarantee that data will not leave a machine.
SpaceXAI has apparently stopped the observed uploads remotely. The next meaningful milestone is a transparent, verifiable product-level remediation—one that removes or documents the collection mechanism, defines which users and versions were affected, and provides evidence for the promised deletion of previously uploaded material. Until then, teams with sensitive Windows development environments should assume the safest control is not a checkbox, but restricting the tool’s access to repositories and outbound destinations in the first place.
.env files, old credentials, internal infrastructure details, and deleted-but-committed secrets may have left the workstation as part of a repository bundle.The reported behavior matters because Git history is often more sensitive than the checked-out working tree. A token removed months ago, a configuration file rewritten before release, or a vulnerability fix that exposes the original flaw can remain in prior commits even when it no longer appears in the current source tree.
Cereblab’s testing found that the broad upload path was distinct from the traffic used to submit a coding request. In one controlled 12 GB repository test, the normal model-request channel transferred roughly 196 KB, while a separate storage channel accepted more than 5 GB before the test was stopped. The Hacker News independently described the same core finding: a Git bundle was sent through a separate storage endpoint rather than limiting transmission to files needed for the active task.
A Git Bundle Is a Much Larger Disclosure Than a Prompt
The distinction between “the tool can access code” and “the tool sends the repository” is the center of this incident. Cloud coding agents necessarily transmit some material when developers ask remote models to analyze or modify files. That is an expected trade-off, and one that security teams can document, restrict, and approve.A full Git bundle changes the scope. According to Cereblab, Grok Build packaged tracked content along with commit history, including files that the agent had explicitly been told not to open. The researcher also reconstructed the captured bundle and found a planted canary file inside it, despite the test instruction directing the tool not to read that file.
That makes conventional prompt hygiene an inadequate safeguard. Telling an AI agent to avoid a directory, limiting a request to one function, or opening only a single solution folder does not protect a repository if the client’s collection layer independently packages tracked data. On Windows development machines, that can encompass application source, deployment scripts, PowerShell automation, Azure configuration, test fixtures, and secrets that were committed by mistake before being removed.
The issue is especially uncomfortable for teams that treat a
.gitignore file as a security boundary. Git ignores only prevent untracked files from being committed; they do not protect items that are already tracked, nor do they erase them from older commits. An accidentally committed .env file that was later deleted can remain recoverable from history, which is precisely why secrets rotation—not simple deletion—is the normal response to an exposed repository.The User-Facing Privacy Control Was Not the Upload Kill Switch
SpaceXAI said on July 13 that teams using zero data retention, as well as API-key users subject to that mode, did not have trace or code data retained. It also pointed non-ZDR users to Grok Build’s/privacy command, which it said could disable retention and delete synchronized data.Those assurances need to be separated from the observed upload behavior. Cereblab reported that disabling the consumer-facing model-improvement setting did not stop the repository bundle from leaving the test machine. The research instead found that the client subsequently received a server-controlled setting,
disable_codebase_upload: true, after which repeat tests no longer showed storage uploads.That is a meaningful mitigation, but it is not the same as a new client binary with the code path removed. The same installed Grok Build 0.2.93 client reportedly changed behavior after receiving the remote configuration. WinBuzzer reported that upload-related capability remained present through version 0.2.99 even while the server flag held the behavior inactive.
For enterprise IT, that difference is practical rather than philosophical. A remote feature flag can shut down risky behavior quickly, which is valuable during an incident. But it also means a client can contain functionality that administrators cannot fully assess from a version number alone, and whose behavior may change without a conventional Windows software update, MSI deployment, or release-note review.
What Has Been Fixed—and What Has Not Been Proven
The strongest currently supported conclusion is narrow: Cereblab’s repeat tests indicate that the repository-upload path stopped firing after SpaceXAI’s server-side change. The same research reported no further/v1/storage uploads during retesting, and the reported configuration included both disable_codebase_upload: true and trace_upload_enabled: false.What remains unresolved is equally important. The researchers identified the Google Cloud Storage destination as
grok-code-session-traces, but they did not establish who could access uploaded archives, how long prior data was retained, or whether it was used for model training or other processing. Those are separate questions from proving that a client sent the data.Elon Musk said on July 13 that all user data uploaded before that date would be completely deleted. As of July 16, there is no independent public evidence demonstrating that historical uploads have been deleted, nor a formal vendor security advisory detailing affected versions, retention periods, account scope, access controls, or an auditable deletion process. A promise may be relevant to users deciding whether to continue with the service, but it is not a substitute for incident documentation.
SpaceXAI’s zero-data-retention statement may also reduce risk for customers who can prove they were covered by that arrangement at the time of use. It does not automatically answer whether a particular developer account, consumer subscription, or locally installed client was configured under ZDR when a repository was processed. Administrators should verify that status through contractual records and account controls rather than infer it from today’s settings.
Windows Teams Should Treat Earlier Use as a Secrets-Exposure Event
Organizations that used Grok Build against sensitive repositories before the July 13 server-side intervention should approach the matter as a potential code and credential exposure, particularly where repositories contained historical secrets. That does not mean every repository was necessarily uploaded, or that every uploaded archive was accessed by a third party. It means the evidence supports taking defensible containment steps rather than waiting for certainty that may never arrive.The first priority is rotating credentials that were present anywhere in affected Git history: cloud access keys, GitHub or Azure DevOps tokens, package-registry credentials, certificates, database passwords, service-account secrets, and private API keys. Revoking and replacing a token is materially safer than assuming that an old commit or deleted configuration file is harmless.
Security teams should also preserve local evidence before clearing it. Endpoint telemetry, proxy logs, firewall records, DNS logs, VPN egress data, and Grok Build logs may help establish which devices used the tool, when they did so, and which repository roots were involved. For a Windows fleet, Microsoft Defender for Endpoint device timelines and network telemetry may be useful if the organization has retained the relevant period.
A short internal inventory should identify the Grok Build versions in use, the users and endpoints that executed them, the repositories opened in each session, whether those repositories contained tracked secrets or regulated data, and whether the organization had an active zero-data-retention agreement. This is also a case for checking developer workstations outside the usual managed build infrastructure; AI coding CLIs are often installed in user profiles and run from PowerShell, Windows Terminal, or integrated developer shells without passing through formal software approval.
The Broader Lesson Is About Agent Collection Layers
This episode is not an argument that every cloud coding assistant is secretly copying every project. The evidence reported here concerns Grok Build’s prior behavior, and the research specifically distinguishes task-related model traffic from the larger repository bundle. Still, it is a sharp reminder that an AI agent is more than its chat prompt and model endpoint.Administrators evaluating coding assistants should inspect the collection layer: what the client enumerates, what it archives, what it uploads, what feature flags govern that behavior, and whether network controls can enforce the claimed boundary. A vendor privacy toggle that changes retention policy is not necessarily a technical guarantee that data will not leave a machine.
SpaceXAI has apparently stopped the observed uploads remotely. The next meaningful milestone is a transparent, verifiable product-level remediation—one that removes or documents the collection mechanism, defines which users and versions were affected, and provides evidence for the promised deletion of previously uploaded material. Until then, teams with sensitive Windows development environments should assume the safest control is not a checkbox, but restricting the tool’s access to repositories and outbound destinations in the first place.
References
- Primary source: WinBuzzer
Published: 2026-07-15T09:51:48+00:00
SpaceXAI's Public AI Coding Tool Uploaded Entire Repositories to Their Servers
SpaceXAI's agentic coding CLI, Grok Build, sent tracked repositories and their full histories to cloud storage before a remote fix stopped uploads.winbuzzer.com
