Grok Build Was Silently Uploading Your Entire Codebase — Including Secrets You Thought Were Gone
xAI's Grok Build CLI was found uploading entire code repositories — including excluded files and historically deleted secrets — to Google Cloud, with no user disclosure. The feature was quietly disabled after Cereblab published their findings, raising serious questions about data transparency in AI developer tools.
When Your AI Coding Assistant Becomes a Data Vacuum
For developers who adopted Grok Build — xAI’s command-line AI coding tool — the expectation was straightforward: an intelligent assistant that reads your code locally and helps you build faster. What researchers discovered instead was something far more unsettling. The tool was quietly packaging entire code repositories and uploading them to Google Cloud storage, with no clear disclosure and, critically, no respect for the files users explicitly asked it to ignore.
According to reporting from The Verge (https://www.theverge.com/ai-artificial-intelligence/965600/spacexai-grok-build-repository-upload), research published by Cereblab on Monday revealed that the Grok Build CLI was not just scanning code for context — it was transmitting whole repositories upstream. The scope of the data transfer went beyond what even cautious developers might have anticipated: the tool was reportedly uploading files it had been instructed not to open, and it was capturing secrets that had been deleted from a project’s history.
That last detail deserves to linger for a moment. Deleted-from-history secrets — API keys, database credentials, authentication tokens that a developer had consciously removed from their Git log — were apparently still being swept up and sent to xAI’s servers. For security-conscious teams, this is not a minor footnote. It is precisely the category of sensitive material that organisations spend real engineering effort scrubbing from codebases.
What Cereblab Found
Cereblab’s findings zeroed in on the behaviour of the Grok Build CLI, the command-line interface that developers use to interact with xAI’s coding assistant. Their tests demonstrated that the tool was packaging and uploading entire code repositories rather than selectively sending only the snippets needed to answer a specific query.
The researchers also compared Grok Build’s data retention behaviour against similar tools — specifically Claude Code, Anthropic’s competing AI coding product. The comparison was not flattering for xAI. Grok Build was found to be retaining significantly more data than Claude Code, suggesting that the aggressive upload behaviour was not an industry-wide default but a choice specific to how Grok Build had been engineered.
The details of exactly what was being uploaded — and how long it was being stored — remain important open questions. When a tool ingests secrets that were deleted from a repository’s history, those credentials could potentially remain accessible on a third-party cloud infrastructure even after a developer believes they have been safely purged. The implications for enterprise teams, open-source contributors, and solo developers working on proprietary projects are considerable.
xAI’s Response: A Flag in the Dark
As of Monday, when Cereblab published their findings, the researchers reported that xAI’s servers had begun returning a disable_codebase_upload: true flag, and the upload behaviour had stopped firing in their tests. In other words, the company appears to have quietly switched off the feature around the time the findings became public — or possibly just before.
Elon Musk, who leads xAI, responded to coverage of the incident, though the full content of his response was not elaborated in the source reporting. The speed of the fix — if it can be called that — suggests xAI was aware of the scrutiny and moved to disable the feature rather than defend it.
What is notable here is the mechanism of remediation. There was no formal security advisory published at the time of reporting, no detailed changelog entry explaining the change in behaviour, and no proactive communication to users whose repositories may already have been uploaded. The fix was a server-side flag flip, observable only because researchers were actively monitoring the tool’s network traffic.
Why This Pattern Is Becoming Familiar
Grok Build is not the first AI developer tool to raise eyebrows over what data it transmits and where. As AI-powered coding assistants have proliferated — from GitHub Copilot to Cursor to Claude Code — the question of what these tools do with your code in transit has become one of the most consequential unresolved debates in developer-facing AI.
The business model for many of these tools creates an inherent tension. Training and improving large language models requires vast amounts of high-quality code. Developers using these tools are, knowingly or not, generating exactly the kind of data that would be valuable for model improvement. Most reputable providers have policies about not training on customer code, but the infrastructure required to ingest, process, and serve AI coding assistance means that code is, at minimum, leaving the local machine.
What makes the Grok Build situation particularly pointed is the allegation that the tool ignored explicit user instructions about which files to access. A .gitignore file or an equivalent exclusion directive is a developer’s primary mechanism for telling tools what is off-limits. If a CLI tool overrides those instructions and uploads the excluded files anyway, it represents a breakdown not just of privacy expectations but of a foundational trust contract between the tool and its user.
The Secrets-in-History Problem
The detail about deleted-from-history secrets warrants its own examination. In Git-based workflows, removing a secret from a repository’s current state does not automatically remove it from the commit history. Developers who discover they have accidentally committed an API key typically have to undertake a deliberate history-rewriting process — using tools like git filter-repo or BFG Repo Cleaner — to purge the credential from every historical commit.
If Grok Build was uploading repositories including their full history, then secrets that had been properly purged at the file level but perhaps not yet scrubbed from the commit log would have been captured. Worse, if the tool was somehow reaching into previously-cleaned history and still surfacing those values, the implications are even more serious.
For Indian development teams — whether working at large IT services firms, fintech startups, or product companies — this matters acutely. Codebases in regulated industries such as banking, healthcare, and payments often contain configuration files and environment variables that, if exposed, could result in compliance violations under frameworks like RBI’s IT security guidelines or CERT-In’s incident reporting mandates.
What Developers Should Do Now
If you have been using Grok Build and are concerned about what may have been uploaded, there are several practical steps worth considering:
- Rotate any credentials that existed in your codebase, even if you believe they were previously deleted from history. Assume the worst-case scenario and treat those credentials as potentially compromised.
- Audit your repository history using tools like
git logandgit showto identify any commits where sensitive values may have appeared, then usegit filter-repoto fully purge them. - Review the permissions granted to any AI coding CLI tools in your development environment. Be particularly cautious about tools that request broad filesystem access or that establish outbound network connections.
- Check your organisation’s AI tool approval policies. Many enterprise security teams are now maintaining lists of approved and prohibited AI tools; the Grok Build incident is a concrete case study for why those policies exist.
- Monitor network traffic from development machines if you have the tooling to do so. Researchers discovered this issue precisely because they were watching what the CLI was sending over the wire.
The Broader Question for AI Tooling Trust
This incident arrives at a moment when AI coding assistants are transitioning from novelty to infrastructure. Developers at companies of all sizes are building workflows, CI/CD pipelines, and onboarding processes around these tools. The more deeply embedded they become, the higher the cost of discovering that they have been silently exfiltrating sensitive data.
xAI’s apparent quick response in disabling the upload behaviour is a partial positive signal — the company did not attempt to argue that the behaviour was acceptable. But the lack of transparent communication to affected users, the absence of a formal incident disclosure, and the fact that it took independent researchers rather than xAI’s own security processes to surface the issue all point to gaps that need addressing.
For a tool that positions itself as trustworthy infrastructure for professional developers, the bar for transparency around data handling is not optional. Developers — especially those working in regulated industries or on proprietary intellectual property — need to know exactly what leaves their machines, under what conditions, and with what retention policies. A server-side flag flip, discovered through third-party network monitoring, is not that disclosure.
The full reporting is available at The Verge, and Cereblab’s original findings provide the technical grounding for the claims outlined here. As AI coding tools continue to mature, incidents like this one will likely serve as reference points for the industry standards — and regulatory expectations — that are still taking shape.
