Grok Build Was Quietly Uploading Your Entire Codebase to Google Cloud
SpaceXAI's Grok Build AI coding tool was silently uploading users' entire codebases to Google Cloud Storage without clear disclosure, and the company disabled the behavior after it was publicly reported.
Original sourceSpaceXAI's Grok Build, an AI-powered coding assistant, was discovered to be uploading users' complete code repositories to Google Cloud Storage as part of its operation — a behavior that was not clearly disclosed to users at sign-up or during use. The issue was surfaced and reported publicly before SpaceXAI took action, at which point the company turned the upload behavior off.
The core problem isn't just a privacy violation in isolation — it's that the data transfer was happening silently. Developers working on proprietary codebases, unreleased products, or client work had no indication their intellectual property was leaving their machines and landing in cloud infrastructure controlled by a third party. The distinction between 'the AI analyzes your code locally' and 'we store your entire repo on Google Cloud' is not a minor implementation detail.
SpaceXAI has not, as of publication, issued a detailed explanation of why the uploads were occurring, what data was retained, how long it was stored, or whether any of it was used for model training. That silence is doing a lot of work. The company disabling the feature in response to a report is the minimum acceptable response, not a resolution.
This joins a growing list of AI developer tools caught treating users' codebases as fair game for backend processing without explicit consent. For tools targeting professional developers — who often work under NDAs, compliance obligations, or competitive sensitivity — undisclosed data exfiltration isn't a bug that gets patched quietly. It's a trust failure that tends to be permanent.
Panel Takes
The Builder
Developer Perspective
“The primitive here is 'we silently exfiltrate your codebase before you agreed to anything,' and that's not a DX bet, that's a data grab. Any tool that requires uploading my entire repo to function should make that the first sentence of the onboarding, not a footnote discovered by a reporter. This is the kind of thing that gets an entire category of tools blocked at the firewall level for enterprise teams, and it's earned.”
The Skeptic
Reality Check
“The question nobody is asking loudly enough: was this a bug or a feature someone decided not to document? 'We turned it off after it was reported' is not the same as 'we never intended to do this,' and SpaceXAI hasn't clarified which it is. What kills this tool in 12 months isn't the competition — it's that enterprise procurement teams now have a documented incident to cite when blocking it, and there's no answer to the question of what happened to the data that was already uploaded.”
The Founder
Business & Market
“The buyer for a professional coding tool is either a developer on a self-serve plan or an engineering org on an enterprise contract — and both buyers just watched their IP land on Google Cloud without consent. There is no moat here; defensibility in developer tooling is built entirely on trust, and that's the one asset SpaceXAI just spent. The business question isn't whether they can fix the feature, it's whether the sales cycle for any team with a legal department just became effectively infinite.”
The PM
Product Strategy
“The job-to-be-done for a coding assistant is 'help me write and understand code faster' — nowhere in that contract does the user agree to 'and also store my entire repository in a third-party cloud.' This is a product completeness failure at the most fundamental level: the tool shipped without a clear data handling policy surfaced at the moment of consequence, which is when a user first connects a repo. Turning off the behavior after a report isn't a product fix, it's damage control, and there's still no answer to what the complete data lifecycle looked like.”