xAI open-sourced its Grok Build terminal coding agent this week — the whole thing, reported at around 844,530 lines of Rust, published to GitHub as xai-org/grok-build under the Apache 2.0 license. Normally that's a feel-good developer story: a frontier lab opens a tool, the community pokes at it, everyone wins.
This one arrives with an asterisk. Grok Build wasn't opened at the top of a hype cycle. It was opened in the middle of a privacy controversy — and the interesting part, the part with a lesson for anyone running a coding agent in their own repo, is what the closed version was doing and why the off switch didn't turn it off.
What security researchers reported#
Grok Build shipped in beta on May 25, 2026 as an agentic terminal CLI: you describe a task in natural language, it writes code and runs automation, delegating big jobs to parallel subagents. Standard shape for the category — the same lane as Claude Code and Codex CLI.
The problem surfaced when researchers watched what a single session actually sent over the wire. By the reporting, each session opened two outbound channels:
- a model-turn channel carrying the task-relevant content — about 192 KB, roughly what you'd expect, and
- a separate storage channel that uploaded the working repository packaged as a Git bundle — a single binary containing the repo's entire tracked contents plus its full commit history — reported at roughly 5.10 GB split across 73 chunks of about 75 MB each.
The legitimate channel moved 192 KB. The quiet one moved 5.10 GB. That's not telemetry — that's the repo.
For a private codebase, a Git bundle isn't a sample. It's everything you ever committed, including whatever you thought you'd scrubbed later in history.
The toggle that didn't gate anything#
Here's the detail founders should circle. Grok Build had an "Improve the model" toggle, and a /privacy command. Developers who turned the toggle off — or ran /privacy — did the reasonable thing and assumed they had opted out of data collection.
They hadn't. Per the reports, disabling that setting did not stop the storage-channel uploads. The uploads stopped only after xAI enabled a global, server-side flag. The control that users could see and touch was not the control that governed the behavior.
That gap — between the switch in the UI and the code path that actually decides what leaves your machine — is the whole story. A privacy setting that doesn't gate egress isn't a weak control. It's a misleading one, because it manufactures confidence in exactly the people who cared enough to look for the switch.
What xAI changed, and what it didn't#
To its credit, xAI moved:
- On July 12, 2026, it disabled default data retention for all Grok Build users (retention had been on by default for non–zero-data-retention users).
- It says it is deleting the coding data it had previously retained.
- It then open-sourced the codebase under Apache 2.0 — and, per multiple reports, the upload code path is still in the repo, now readable by anyone.
Leaving the upload code in the open release is arguably the honest move: it's inspectable now, which is more than could be said a week ago. "Open" beats "closed" for trust every time, because trust in a coding agent should rest on what you can verify, not on what you're told.
The transferable lesson#
Skip the temptation to make this a Grok story. Every terminal coding agent runs inside your repository with your permissions. Every one of them can, in principle, ship your source and history somewhere. The Grok Build episode is just the clearest recent proof that the in-app privacy toggle is not where you should place your trust.
So place it at the network layer instead:
- Verify opt-out where bytes actually move. Watch egress — a proxy,
mitmproxy, host firewall logs, or your endpoint tooling. If a "privacy off" session still streams gigabytes somewhere, the toggle is decoration. Trust the packet capture, not the checkbox. - Get zero-data-retention or enterprise terms in writing. A contractual ZDR commitment is enforceable in a way a UI switch is not. For anything touching customer code or secrets, that's the bar.
- Run untrusted agents where you can contain them. A sandbox, a scratch clone with no history, a container with an egress allowlist. If the agent can only see a shallow checkout, a bundle upload can only leak a shallow checkout.
- Now that it's open, read the egress path. For Grok Build specifically, the code that does the uploading is in the Apache-2.0 repo. If you're going to run it, that's the first file to read.
The good news for founders is that the fix here is cheap and general. You don't need to vet every coding agent's PR history. You need one habit: assume the tool in your terminal can send your repo anywhere, and put a control you own between it and the internet. The toggle in someone else's app was never that control.
