SpaceXAI’s Grok Build, a developer-focused AI coding tool, has reportedly been sending far more of users’ code than many would reasonably expect—at least until the behavior was identified and then disabled. New reporting and analysis point to a workflow where the Grok Build command-line interface (CLI) packaged entire repositories and uploaded them to Google Cloud, including files users had been instructed not to share and even material described as “secrets deleted from history.” The episode has quickly become a privacy and security flashpoint for the broader category of AI coding assistants, raising uncomfortable questions about what “context” really means when an automated tool is allowed to collect and transmit local project data.
The story begins with researchers at Cereblab, who examined how Grok Build operates under the hood. Their findings, as summarized in coverage by The Register and echoed by The Verge, describe a process that went beyond sending only the specific files a user intended to work on. Instead, the CLI reportedly assembled a full codebase bundle and transmitted it to SpaceXAI’s servers. In other words, the tool appears to have treated the repository as a unit of context rather than a set of carefully scoped inputs.
That distinction matters. Many developers are comfortable sharing a small slice of a project—say, a single file they’re actively editing or a minimal snippet needed to debug a function. But a whole repository can contain far more than the immediate task: configuration files, internal documentation, build scripts, test fixtures, vendor code, and—most importantly—credentials and secrets that may be present in some form even after attempts to remove them. Even when developers believe they’ve cleaned up sensitive information, remnants can persist in commit history, lockfiles, environment templates, logs, or generated artifacts. The concern highlighted in the reporting is that Grok Build’s packaging step may have captured content that users had been told not to open or that should not have been included in the first place, along with “secrets deleted from history.”
To understand why this is so consequential, it helps to look at how AI coding tools typically work. Most modern assistants rely on a combination of local context gathering and remote model inference. The local side might read files from your workspace, extract relevant sections, and send them to a backend service. The remote side then uses that information to generate suggestions, patches, or explanations. In principle, the system can be designed to minimize data exposure by selecting only what’s needed, redacting sensitive patterns, and respecting explicit user boundaries.
In practice, however, the implementation details vary widely. Some tools use targeted file selection; others use broader repository indexing; still others may default to bundling more than necessary to improve performance or reduce complexity. When a tool bundles an entire repository, it increases the chance that sensitive or irrelevant data will be transmitted—especially if the tool’s filtering logic is incomplete or if it relies on assumptions about what users will have removed.
Cereblab’s analysis, as reported, suggests that Grok Build’s behavior included packaging and uploading repository contents in a way that retained significantly more data than similar tools have been observed doing. That phrase—“significantly more data retention”—is important because it implies not just that the tool uploaded too much, but that it may have done so in a manner that persisted longer or more broadly than comparable systems. Data retention isn’t only about whether something is uploaded; it’s also about what happens after upload: how long it’s stored, whether it’s used for training, whether it’s kept for debugging, and whether it’s accessible to other processes or teams. While the reporting focuses on the upload step itself, the underlying implication is that the tool’s design may have been oriented toward maximizing usefulness for the assistant rather than minimizing exposure for the user.
The timing of the change is another key element. According to the reporting, once the issue was brought to light, SpaceXAI altered the behavior. Researchers reportedly observed that the servers began returning a flag indicating codebase uploads were disabled, and that the upload step no longer fired. In other words, the system appears to have been updated to stop the repository-wide upload after the problem was identified.
This kind of rapid mitigation is not unusual in the tech world—especially when a behavior is discovered through testing and then escalated publicly. But it doesn’t fully resolve the core question: what happened before the fix, and how many users were affected during the window when the tool was uploading entire repositories?
Even if the tool later disables the behavior, the episode still matters for several reasons. First, developers may have already run Grok Build on projects containing sensitive information. Second, the incident highlights a structural risk in AI developer tooling: the gap between user expectations and actual data flows. Many users assume that an AI coding assistant will only transmit what it needs for the current request. If the tool instead uploads a whole repository, the user’s mental model is wrong—and that mismatch can lead to accidental disclosure.
Third, the incident underscores the difficulty of “secret hygiene” in real-world development. Developers often remove secrets from their current working tree, rotate credentials, and scrub commits. Yet secrets can linger in ways that are hard to predict: in older commits, in branches, in tags, in CI logs, in generated files, or in files that are excluded from normal workflows but still exist in the repository. The reporting’s mention of “secrets deleted from history” points to a particularly thorny scenario: even if a secret is no longer visible in the latest version of a file, it may still be recoverable depending on how the tool packages the repository. If the tool includes metadata or history-like artifacts—or if it captures files that contain previously removed values—the risk becomes more complex than simply “don’t put secrets in your repo.”
There’s also a broader ecosystem angle. Grok Build is not the only AI coding assistant, and it’s not the first to face scrutiny over data handling. But each new case tends to reveal different failure modes: overly broad file collection, insufficient redaction, unclear documentation, or ambiguous consent mechanisms. What makes this incident stand out is the apparent scale of the upload—entire codebases—and the suggestion that the retention behavior was more extensive than what has been observed in other tools. That combination turns a privacy concern into a security concern, because the more data that leaves a developer’s machine, the larger the attack surface and the greater the potential impact of any mishandling.
For developers, the practical takeaway is less about panic and more about operational caution. If you use AI coding tools that interact with your local filesystem, you should treat them like any other integration that can access sensitive assets. That means reviewing documentation carefully, understanding what the tool sends, and adopting workflows that reduce the chance of sensitive data being present in the first place. In practical terms, that can include using separate repositories for experiments, keeping production secrets out of code entirely, and ensuring that credentials are managed through secure environment variables rather than committed files. It also means being mindful of what “repository” includes—tests, fixtures, sample configs, and any file that might contain internal endpoints or tokens.
But there’s a second takeaway that goes beyond individual user behavior: transparency and control need to be built into these tools, not bolted on after the fact. The reporting indicates that Grok Build’s behavior changed after researchers tested it and found the upload step. That suggests the system had a server-side switch or policy mechanism that could disable codebase uploads. If such a mechanism exists, it raises the question of why it wasn’t enabled by default in the first place, or why users weren’t clearly informed about the scope of what would be uploaded.
In a well-designed system, users should be able to choose the granularity of context. For example, a tool could offer modes like “current file only,” “selected files,” or “repository indexing with strict exclusions.” It could also provide a preview of what will be sent before transmission, or at least log which files were included in the payload. Without that, users are left to infer behavior from outcomes, which is a poor substitute for explicit guarantees—especially when the stakes involve secrets and private intellectual property.
The incident also invites a deeper look at how AI coding tools decide what to include. Repository-wide packaging might be motivated by performance and quality: having more context can improve code completion, refactoring suggestions, and dependency understanding. But quality improvements come with a cost. If the tool’s value depends on seeing everything, then the product should say so plainly and provide strong safeguards. If the tool can operate effectively with narrower inputs, then repository-wide uploads should be avoided by default.
There’s another nuance: even if a tool claims it deletes data after processing, deletion policies are difficult for users to verify. Users can’t easily audit what was uploaded, how it was stored, or whether it was retained for debugging or evaluation. That’s why independent research like Cereblab’s is so important—it tests the system’s behavior rather than relying on marketing claims. When researchers observe concrete upload patterns, it provides evidence that can be used to push for better controls.
The response from SpaceXAI, as described in the reporting, appears to have been to disable the codebase upload behavior by flipping a server-side flag. That’s a meaningful step, but it also highlights a limitation: disabling a feature after discovery doesn’t retroactively protect data that may have already been transmitted. It also doesn’t necessarily address whether other forms of data collection are still happening—such as uploading selected files, sending metadata, or retaining logs. The most responsible next step would be a clear explanation of what changed, what data was previously uploaded, and what the current behavior is. Ideally, that explanation would include specifics: whether uploads are now limited to explicitly requested files, whether there are exclusions for sensitive patterns, and whether any repository-level packaging still occurs for certain operations.
For the industry, this case is likely to accelerate scrutiny of AI developer tools. Companies building these systems will face increasing pressure to demonstrate compliance with privacy expectations and to provide verifiable controls. That could mean stronger client-side filtering, more explicit user consent