Grok Build Is Now Open Source: xAI Responds to Backlash
TL;DR: A week after xAI’s coding tool was caught quietly uploading users’ code, the company has responded. On 15 July 2026 it open-sourced Grok Build (so anyone can inspect exactly what it does), reset usage limits for everyone, turned off data retention, and says it’s deleting the code it previously collected. These are the right moves — with one honest caveat we’ll get to.
What happened
If you read our piece last week, you’ll remember the short version: a researcher found xAI’s Grok Build tool was uploading users’ entire codebases — secrets included — to xAI’s own cloud, and the company said nothing publicly for days. We promised to update you if that changed. It has.
On 15 July 2026, xAI made three moves, reported by its own announcement and covered by Simon Willison and Cryptobriefing:
- Grok Build is now open source — the full codebase, released under the permissive Apache 2.0 licence. Anyone can now read exactly what the tool does and sends.
- Usage limits were reset for all users.
- Data handling changed: default retention was switched off (from 12 July), and xAI says it is deleting the coding data it had already collected.
That last point matters most, because it’s a direct answer to the biggest open question from last week — “is the code that was already uploaded going to be deleted?” xAI now says yes.
Why it matters if you don’t code
Two of these changes are more meaningful than they sound.
“Open source” means the tool’s inner workings are now public. Before, you had to trust xAI’s word about what Grok Build sent. Now the code is out in the open, so security researchers — the same kind of people who caught the problem — can check every line and confirm what it does. You don’t have to read code yourself to benefit; you benefit from others being able to. Sunlight is the point.
Running it locally takes xAI out of the loop. With the open-source version, the tool runs on your machine instead of routing your project through xAI’s servers. That structurally removes the thing that caused the problem: if your code never leaves your computer, it can’t be over-collected.
Add the promised deletion of already-collected data, and this is close to the full set of things you’d want a company to do after a mistake like this.
The honest caveat
Credit where it’s due — but two things keep this from being a clean win:
- “We deleted it” is a promise you can’t personally verify. Open-sourcing the tool lets people audit what it does now; it doesn’t let you confirm what happened to data already taken. You’re still trusting xAI on that part.
- It took public pressure. Transparency that only arrives after a researcher forces the issue is better than none — but it’s worth remembering how the trust got spent in the first place.
What to do
- If you used Grok Build before this: our advice from last week still stands — rotate any secrets (API keys, passwords) that were in those projects. Deleting the uploaded copy doesn’t un-expose a key that already left your machine; assume it’s compromised and replace it.
- If you’re curious now: the open-source, run-it-locally version is a much safer way to try it than the old cloud-tied one.
- Everyone else: the general lesson from last week holds — prefer tools that are clear about what they collect, and keep secrets out of project folders.
Who should care (and who shouldn’t)
- Former Grok Build users: this is your resolution — rotate secrets, and know your data is (per xAI) being deleted.
- Anyone weighing xAI’s tools: how a company handles a mistake tells you a lot. This response was solid, if late.
- You only use Lovable, Bolt, Replit, or Cursor: none of this touched you — but it’s a useful reminder to check what your own tool collects.
Our take
This is roughly what accountability should look like: make the tool inspectable, take yourself out of the data path, and clean up what you collected. We’d genuinely give xAI credit for the substance of the response. The lingering lesson isn’t about Grok specifically — it’s that the tools we build on should be this transparent before something goes wrong, not only after. Judge tools not just on features, but on how they behave when they’re caught out.
Want a tool matched to how you actually work? Take the 60-second Vibe Coding Tool Finder quiz →
FAQ
Does open-sourcing Grok Build mean my previously uploaded code is safe now?
Not exactly. Open-sourcing lets people verify what the tool does going forward. Separately, xAI says it’s deleting the coding data it already collected — but that’s a commitment you can’t independently confirm. If secrets were in those projects, rotate them regardless.
Do I need to do anything?
If you used Grok Build before, rotate any API keys or passwords that were in your projects. If you didn’t, there’s nothing to do — this is a positive development, not a new risk.
What does “open source” actually protect me from?
It removes the “just trust us” problem. When a tool’s code is public, independent experts can confirm what it collects and sends — and, in this case, you can also run it locally so your code never leaves your computer.
