xAI Open-Sourced Grok Build 72 Hours After a Researcher Caught It Uploading Entire Private Repos. Open-Sourcing After the Fact Is Trust Repair, Not a Refund.
On July 15, xAI open-sourced Grok Build (its terminal coding agent, the whole Rust harness, roughly 845,000 lines covering the agent loop, the tool layer, the TUI, and the extension system) under Apache 2.0. On its own that's a nice release. In context it's damage control. The open-sourcing landed about 72 hours after a security researcher published wire-level evidence that the CLI had been silently uploading complete Git repositories to a company-controlled cloud bucket, without clear user consent. On July 12, xAI disabled the upload by default and deleted the coding data it had already collected.
Sit with the sequence for a second. A coding agent you ran on your machine, pointed at your private repo, was shipping that repo (source, history, whatever secrets were checked in) to someone else's storage. Nobody found it by reading the docs. Somebody found it by watching the network.
You cannot see this without watching the wire
That's the part that should change how you work. The exfiltration wasn't in a changelog, a permissions prompt, or a settings toggle you ignored. It was visible only to someone doing packet-level inspection of what the tool actually sent. Everyone else, every developer who trusted "it's a coding assistant, of course it reads my code," had no signal at all.
This is the uncomfortable truth about the current generation of AI dev tools: they have every legitimate reason to touch your entire codebase, which means an illegitimate upload looks exactly like normal operation. Reading your files is the feature. Sending them somewhere is one config flag away, and you're not positioned to tell the difference from the outside.
Open source is the belated version of the control you actually needed
I don't want to be cynical about the Apache 2.0 release. Publishing 845,000 lines of your agent harness is a real thing to do, and it's genuinely better than the alternative. Now anyone can read exactly what Grok Build does with your code, audit the egress paths, and fork it if they don't like the answer. That's the correct control. Auditability beats promises.
But notice what open-sourcing does and doesn't do. It makes future behavior inspectable. It does not un-upload the repos that already left. If your private codebase sat in that bucket for the window before July 12, "we deleted it" is a claim you're taking on faith from the same party that shipped the upload in the first place. Trust repair is not a refund. The code that left, left.
So the release is good and the timeline is the lesson. "Trust us, we're a coding tool" is not an egress policy. The only thing that was ever going to catch this was someone able to see the traffic. The only durable fix is preferring tools whose behavior you or someone you trust can actually verify.
The 20-minute audit for your own coding agents
You don't need to become a network forensics expert. You need to make your AI dev tools observable enough that a silent upload can't hide.
Start by inventorying what's actually installed and running with repo access: every coding CLI, IDE agent, and MCP server. For each, find the setting that governs cloud sync, telemetry, or "improve the model with your data," and turn it off unless you have a specific reason not to. Assume anything with a cloud-sync feature has, at minimum, the capability to see your code.
Then watch the wire once, deliberately. Point the tool at a throwaway repo and run a network monitor (Little Snitch on macOS, or a simple egress log) while the agent works. You're looking for one thing: does it phone home to somewhere you didn't expect, and how much is it sending. You do this once per tool, not forever, and you learn more in twenty minutes than any privacy policy will tell you. Finally, get real secrets out of the blast radius entirely: anything an agent could exfiltrate shouldn't be a plaintext key sitting in your repo or your config in the first place.
The honest counter-take
Two things I'd hold in tension. First, not every vendor is malicious, and the failure mode here is often a "sync to improve your experience" feature that shipped enabled without anyone thinking hard about consent (bad, but not the same as deliberate theft). Second, some cloud sync is legitimately useful, and a blanket "never let a tool touch the network" posture will cost you real features for a threat you can usually manage with observability instead of abstinence. The goal isn't paranoia. It's that your tools shouldn't be able to do things you can't see.
If I ran a coding agent this week that I'd never watched on the wire, I'd spend one throwaway-repo session watching it before I pointed it at anything I cared about. Grok Build got open-sourced because someone did exactly that. The tools that don't get audited are the ones still counting on you not to look.
Author
Lukas
@lukcombinator