On a 12 GB test repository, xAI's Grok Build CLI sent about 192 KB to the model and 5.10 GiB to a Google Cloud Storage bucket, What xAI Grok Build CLI actually sends to xAI: a wire-level analysis.
Three days later, xAI open-sourced the whole thing. The timing is not a coincidence, and the release is genuinely useful. But it answers a question nobody was asking. The complaint was "you took my repo without asking." The answer was "here's the code that took it." Those aren't the same fix.
Key Takeaways
- In July 2026, a wire-level analysis found Grok Build uploaded 5.10 GiB of a test repo to a Google Cloud bucket while the model itself read only 192 KB, a ratio near 27,800x (cereblab, GitHub Gist, July 2026).
- xAI released 844,530 lines of Rust under Apache 2.0, but as a single commit with no development history (Simon Willison, July 2026).
- The release covers the harness, not the model. Grok's weights stay closed, so "local-first" means bringing your own model.
- The upload code is still compiled in, disabled by flag rather than removed, which leaves the capability remotely switchable.
The harness, not the brain. In July 2026, xAI published Grok Build's agent loop, tool layer, terminal UI, and extension system as roughly 844,530 lines of Rust under Apache 2.0, with only about 3% vendored code (Simon Willison, "xai-org/grok-build, now open source", July 15, 2026). The Grok model weights were not part of it.
That distinction does most of the work in this story. A harness is scaffolding: it assembles context, calls the model, parses the reply, and dispatches tool calls (MarkTechPost, "SpaceXAI Open-Sources Grok Build", July 15, 2026). It's the part that decides what leaves your machine. So open-sourcing it is the right layer to open if the argument is about data movement. But it isn't a Grok release.
The repo splits into a handful of crates: xai-grok-shell for the agent runtime, xai-grok-tools for tool implementations, xai-grok-workspace for filesystem and VCS integration, and xai-grok-pager for the TUI. It runs three ways: interactive TUI, headless for CI, or embedded in an editor over the Agent Client Protocol. It's 99.6% Rust, and had drawn 13.4k stars and 2.4k forks (GitHub, xai-org/grok-build, retrieved July 17, 2026).
Read that card again. Thirteen thousand stars, two thousand forks, and one contributor. Issues sit at zero because they're switched off. The README explains why: the tree "is synced periodically from the SpaceXAI monorepo," with a SOURCE_REV file recording the upstream commit it was cut from (GitHub, xai-org/grok-build, retrieved July 17, 2026). Upstream merge, as MarkTechPost noted, is not on offer.
According to Simon Willison's July 2026 review, Grok Build's 844,530 lines sit just under OpenAI's Codex at 950,933 lines of Rust, which is a useful reminder that terminal coding agents are far heavier engineering artifacts than the "it's just a while loop around an API" framing suggests. A lot of what people experience as a model getting better at agentic work is really the harness getting better, a pattern we picked apart when Sonnet 5 landed near-Opus agent quality at a lower price. Willison also noted several tool implementations appear ported from Codex and OpenCode, and that the subagent system prompt instructs the model not to reveal its own contents.
Far more than the model ever looked at. Routing grok 0.2.93 through mitmproxy on macOS, researcher cereblab measured two separate channels: the files the agent actually read moved 196,705 bytes across five requests, while a parallel channel pushed 5.10 GiB in 73 chunks of roughly 75 MB each to /v1/storage (cereblab, GitHub Gist, July 2026). That's a gap of about 27,800x.
The proof is the part that's hard to argue with. cereblab planted a file the agent never opened, marked CANARY-XR47P2-NEVERREAD-UNIQUE, and later recovered it verbatim from an uploaded Git bundle, full commit history included. The repo left the machine regardless of what the agent processed. The destination was a Google Cloud Storage bucket named grok-code-session-traces, confirmed from strings in the binary, staged metadata.json paths, and live multipart PUTs to storage.googleapis.com.
Secrets rode along in both channels. A canary .env line reading API_KEY=CANARY7F3A9-SECRET-should-not-leave showed up verbatim inside a 48,070-byte POST /v1/responses body and again inside an accepted session_state archive. And the upload channel was durable in a way the model channel wasn't: across the whole capture, 82 storage POSTs were attempted and not one failed, while the only errors recorded were model quota responses (one 402, three 429s). As cereblab put it, "The whole repo is uploaded at multi-GB scale; the only ceiling is a model quota, not storage size."
Worth stating plainly what this analysis did not show, because the louder coverage blurred it. cereblab did not prove xAI trained on the data (upload and training are different questions, governed by policy). The tests didn't cover every account type, and whether .gitignored files get swept in was left untested. The finding is about data movement, and that's damning enough without inflating it.
Users who switched "Improve the model" off still got a /v1/settings response reporting trace_upload_enabled: true, and the uploads continued (cereblab, GitHub Gist, July 2026). The control people reached for was real, visible, and pointed at something else entirely.
This is the detail that should bother engineering leaders more than the upload itself. A bug that sends too much data is a bug. A privacy control that reports success while the thing it names keeps happening is a different category of problem, because it defeats the only verification most teams ever perform: checking the setting.
Partly, and less than the headlines imply. The upload code is still in the published source, disabled rather than removed (Simon Willison, July 2026; The Decoder, July 16, 2026). xAI stopped the behavior with a server-pushed flag, disable_codebase_upload: true, which means it never required a new binary to turn off, and wouldn't require one to turn back on.
That's the crux, and it follows from the published code rather than from anyone's opinion of it. If a server flag switched the upload off, a server flag can switch it back on: for any user, on any session, without shipping a new binary. byteiota reached the same reading (byteiota, July 2026). Reading the source tells you the capability exists. It doesn't tell you today's flag state, and the flag lives on their servers, not in your repo.
The single-commit release compounds this. Willison flagged that the repo landed with one commit and no history, so you can't see when the upload path was added, by whom, under what review, or what the code looked like on the day cereblab ran that capture. There's an innocent explanation and it's sitting in the README: the tree is a periodic export from an internal monorepo, not the repo the code was actually written in. Plenty of large projects publish that way. It still leaves you reading a snapshot with no past. Published source and open development are different arrangements, and only one of them lets you check the history against the incident.
To be fair to xAI, the response wasn't nothing. Default retention went off on July 12, the company said it would delete previously retained coding data, and it stated that zero data retention had been honored for enterprise customers since launch (The Register, July 16, 2026). Usage limits were reset for everyone, and the code went to HackerOne with bounties from $100 to $20,000. That's a faster and more substantive correction than most companies manage. It just doesn't make the capability go away.
Configure the veto yourself, then verify it on the wire. cereblab's July 13 retest confirmed that [harness] disable_codebase_upload = true in ~/.grok/config.toml blocks the whole-repo pipeline, checked with adversarial canaries (cereblab, GitHub Gist, July 2026). That's the control that works. The one in the UI wasn't.
For the separate session-trace channel, you need both GROK_TELEMETRY_TRACE_UPLOAD=false and GROK_TELEMETRY_ENABLED=false. Setting [telemetry] trace_upload = false in TOML alone gets silently overridden unless the environment is clean. Precedence runs environment, then config, then the remote server flag. Read that ordering again: your environment beats their server. That's the good news buried in the mechanism.
| Setting | Where it goes | What it stops |
|---|---|---|
disable_codebase_upload = true | [harness] in ~/.grok/config.toml | The whole-repo Git bundle upload |
GROK_TELEMETRY_TRACE_UPLOAD=false | Environment variable | Session-trace uploads |
GROK_TELEMETRY_ENABLED=false | Environment variable | Telemetry collection (needed alongside the above) |
base_url | config.toml | Sends inference to your own endpoint instead of xAI |
| "Improve the model" toggle | In-app settings | Nothing relevant. It did not stop the repo upload. |
Source: cereblab's July 13, 2026 retest, verified with adversarial canaries.
The genuinely valuable door the release opens is local-first. You can compile the harness, point base_url at your own inference or any OpenAI-compatible endpoint, and run without touching xAI's infrastructure. Note the trade: at that point you're running xAI's excellent Rust TUI against somebody else's model, because Grok's weights aren't in the box. If you've been weighing what a 1M-context coding model like GLM-5.2 can do or whether local AI hardware earns its keep, this is the release that makes that pairing practical.
Grok Build is the one that got measured, not necessarily the only one worth measuring. Coding agents run with your credentials, your filesystem, and a network connection, which is a combination that deserves more scrutiny than most teams give it. The default posture across the industry is to send the model what it reads. Grok Build's upload channel was structurally different: it sent the repo, then let the model read what it needed.
The governance question isn't "is this vendor trustworthy." It's "what would I be able to detect if they weren't." For most teams today the honest answer is nothing, because nobody's watching the socket. Open source moves that needle, but only for the small number of people who read 844,530 lines of Rust, and only for the parts that aren't decided on a server you don't own.
If your agent spend is climbing while the value stays fuzzy, the same discipline applies to both questions. We've written before about why AI often costs more than the humans it replaces, and the pattern rhymes: the demo is cheap and clean, the production reality is neither, and the gap only shows up when somebody measures instead of assuming.
The harness is. xAI published about 844,530 lines of Rust under Apache 2.0 in July 2026, covering the agent loop, tools, TUI, and extensions (Simon Willison, July 2026). The Grok model weights were not released, so inference still runs against a hosted API unless you supply your own model.
Yes. A July 2026 wire-level analysis of grok 0.2.93 recorded 5.10 GiB uploaded to a Google Cloud bucket called grok-code-session-traces from a 12 GB test repo, including a file the agent never read (cereblab, GitHub Gist, July 2026). xAI disabled the behavior by server flag on July 12 and pledged to delete retained data.
Yes, present but disabled rather than removed (Simon Willison, July 2026). Because it's gated by a server-pushed flag, the capability stays remotely switchable without a new release. Setting disable_codebase_upload = true under [harness] in ~/.grok/config.toml is the client-side veto that cereblab verified actually blocks the pipeline.
Yes, if you build from source and point base_url at your own inference endpoint in config.toml. Add disable_codebase_upload = true under [harness], plus GROK_TELEMETRY_TRACE_UPLOAD=false and GROK_TELEMETRY_ENABLED=false, since environment variables take precedence over both config and remote flags.
It makes it auditable. Auditable and safe are different properties. In 2026 the release shipped as a single commit with no development history, so the code's past isn't reviewable and the flag state still lives on xAI's servers. Auditability is a real upgrade, but it only pays off if someone actually audits.
Open sourcing Grok Build was the right move made for the wrong reason, and it's still worth having. The Rust harness is a serious piece of engineering, the local-first path is real, and shipping 844,530 lines to HackerOne beats a press release about how much you value privacy.
But keep the two claims separate. Transparency tells you what the code can do. It doesn't tell you what a server three time zones away decided it will do tonight. The controls that changed your actual risk are the ones you set yourself: build it, veto the upload in config.toml, set the environment variables, and point it at inference you control. The rest is visibility, and visibility only counts when somebody looks.
Bring your setup and we'll check the data path on the wire, not on the settings page.
Continue exploring these related topics
GLM-5.2 is Z.ai's new flagship text model for long-horizon engineering work: 1M-token context, 128K maximum output, function calling, structured output, MCP integration, and a public model card on Hugging Face.
Two flagship AI models. Five weeks apart. Same price — but very different strengths. Here's the honest breakdown of Claude Opus 4.8 vs GPT-5.5 on benchmarks, pricing, and real-world performance.
Clawdbot is an open-source, self-hosted AI assistant with persistent memory and automation. Run it locally and connect WhatsApp, Telegram and Slack.
