Grok Build Uploaded Entire Repos: What Actually Fixed It

The Grok Build privacy scandal broke on Sunday, July 12, 2026, when AI-safety researcher Cereblab published a wire-level network analysis showing SpaceXAI’s coding agent uploading entire repositories — complete git history, deleted secrets and all — to a cloud storage bucket, at roughly 27,800 times the volume the model actually needed to do its job.

What makes this incident worth studying is not the upload itself. It is what happened next: SpaceXAI pointed users to a privacy toggle that never governed the uploads, and the behavior only stopped when engineers flipped a silent, server-side configuration flag that no developer could see, set, or verify. The kill switch for a category of privacy-sensitive behavior sat on the vendor’s server the entire time.

This guide reconstructs the incident from the primary wire capture and the July 12–14 reporting: the two separate data channels and their two separate controls, what the git bundles actually carried, why the /privacy command addressed the wrong channel, what genuinely fixed it, and the durable lesson — agent trust is infrastructure, not a settings checkbox.

Grok Build is SpaceXAI’s Rust-based agentic coding CLI — the tool we covered at launch in our breakdown of Grok Build’s parallel-agent coding workflow. Its default model resolves to Grok 4.5, the flagship coding model SpaceXAI shipped on July 8, 2026 — which means the wire analysis landed just four days after the model’s launch, at the peak of developer attention. (SpaceXAI, if the name is new to you, is the rebrand of xAI under SpaceX revealed on July 6, following an acquisition that closed February 2, 2026.)

On July 12, the researcher publishing as Cereblab released a wire-level analysis of Grok Build CLI version 0.2.93, produced by routing the tool’s traffic through the mitmproxy interception proxy on macOS. The methodology matters: because Grok Build does not certificate-pin against mitmproxy’s custom certificate authority, any developer could reproduce the audit without modifying the binary — a key reason the finding spread and was independently reproduced within a day.

The headline numbers came from a controlled 12 GB test repository. The live model-processing channel — the requests that actually carry context to Grok 4.5 — transmitted roughly 192 KB (196,705 bytes): the files the agent opened for the task. A separate storage channel, meanwhile, uploaded the repository itself as git bundles, in 73 chunks of roughly 75 MB each, every one returning HTTP 200. Cereblab’s own arithmetic puts the gap between what the task needed and what left the machine at roughly 27,800× — a ratio from a defined test, not a universal constant, but one corroborated independently by Developers Digest and TechTimes against the same capture data.

Within 48 hours the story was everywhere developers look. The Hacker News thread reached the front page on July 14, and The Register’s July 14 report — “Musk promises purge after Grok Build caught sending entire repos to the cloud” — became the definitive mainstream account. The OECD.AI incident database logged the event as incident 2026-07-13-acb3, classifying it under privacy-and-data-governance and transparency violations.

Almost every account of this incident narrates it in prose — Grok uploaded things, then it stopped. The structure underneath is what actually explains both the failure and the misdirected fix. Grok Build was operating two separate data channels, governed by two separate controls, owned by two different parties. Most coverage — and, notably, SpaceXAI’s own public statement — conflated them.

Read the last two columns together and the scandal’s central confusion resolves itself. When SpaceXAI’s statement pointed users to Zero Data Retention for enterprise teams and the /privacy command as the remedy, it was describing the controls for Channel A. The behavior developers were furious about lived on Channel B — which answered only to a flag on SpaceXAI’s servers. Per securityonline.info’s technical breakdown, the two channels serve different purposes and are governed by entirely different mechanisms; the public fix addressed the wrong one.

The packaging format is what elevates this from a telemetry overreach to a genuine security event. Uploads went out as git bundles — single-file archives of a repository’s entire commit history. A git bundle does not care what your working tree looks like today. An API key committed eighteen months ago and deleted the next morning is still in the history, and therefore still in the bundle that left the machine.

Cereblab proved the scope with planted canaries. A .env file containing a marker API key and a mock database password appeared verbatim and unredacted in captured traffic — on both the model channel and the storage archive. More striking: a probe file the agent was explicitly instructed never to open was recovered intact from the uploaded git bundle after cloning it back out. The uploads were not a function of what the agent read. They happened regardless.

The blast radius extended beyond repositories. The Register’s July 14 report relayed a user account of running Grok Build from a home directory — after which their entire user directory, reportedly including SSH keys and a password-manager database, was uploaded. That report traces to a social-media post rather than an independent wire capture, so treat it as a credible secondary account rather than an audited finding — but it is consistent with the mechanism Cereblab documented: the tool archived the workspace it was pointed at, whatever that workspace contained.

One important boundary on the claims, drawn by the researcher themselves: the capture proves what was transmitted and stored, not what was trained on.

That distinction cuts both ways. It keeps the criticism honest — nobody demonstrated training on user code. It also exposes how little the training question matters for security purposes: once a secret has been transmitted to infrastructure you do not control and cannot audit, it is exposed. TechTimes’ guidance on July 14 was blunt — developers who had run Grok Build against codebases containing real API keys, database passwords, or cloud tokens should treat those credentials as potentially exposed and rotate them immediately, regardless of what their privacy settings displayed at the time.

Grok Build’s primary user-facing privacy control is the “Improve the model” toggle, exposed through the /privacy command. It is the setting SpaceXAI’s statement pointed users toward. So Cereblab tested it directly: disable the toggle, rerun the CLI, watch the wire.

The result is the single most damning detail in the analysis. With the toggle off, the /v1/settings endpoint still returned trace_upload_enabled: true — and whole-repo uploads continued uninterrupted. The user had expressed a preference; the server had not changed its mind.

Why could a server disagree with a local setting at all? Because Grok Build resolves its configuration across three layers — environment variables, the local config file, and remote flags issued by SpaceXAI’s cloud. In Cereblab’s testing, the cloud-issued value could end up controlling upload behavior even against a developer’s local intent: a developer who somehow knew to set disable_codebase_upload=true in ~/.grok/config.toml could still find the remote flag deciding the outcome. Whichever way the precedence resolved in a given session, the operative fact was the same — the switch that mattered was issued by the vendor’s server, invisible to any client-side inspection or version control.

Cereblab’s conclusion, paraphrased from the Register interview: the /privacy command should not be pointed to as the control for this behavior, and no developer should have to run an opt-out after every session. The deeper point is architectural. A privacy control is only real if the data path it claims to govern actually consults it. Grok Build’s storage channel never consulted anything a user could touch.

So what actually stopped the uploads? On or around July 13, SpaceXAI engineers pushed a server-side configuration flag — disable_codebase_upload: true — to the same remote settings layer that had been enabling the behavior. No client update shipped. No setting appeared in the UI. The uploads stopped because the vendor turned them off at the source, using exactly the kind of invisible switch that caused the problem in the first place.

Worth sitting with: as of the scandal’s peak window, per TechTimes, the upload code itself remained present in the shipped binary — only the server-side trigger was switched off — and no formal security advisory had been issued. The same mechanism that disabled the uploads could, technically, re-enable them. That is not an accusation of intent; it is a description of where the control sits.

The public response ran on two tracks. SpaceXAI’s official statement emphasized that for teams using Zero Data Retention, no trace or code data is ever retained, and pointed other users to the /privacy command — which, it said, also deletes previously synced data. Both halves of that framing are the company’s own claims: the ZDR assurance is not independently confirmed, and as Section 04 showed, the toggle it pointed to did not govern the channel in question. Elon Musk went further the same day.

The incident’s paper trail closed out its first phase on July 14: The Register’s definitive report, the Hacker News front page, an Inc.com trust-crisis framing, and a formal OECD.AI incident record. What none of the July 12–14 record contains is independent verification of any remediation claim — deletion, retention, or otherwise. The scoreboard at the date wall: one wire-level audit anyone could reproduce on one side; settings screens, statements, and promises on the other.

Grok Build’s behavior was an outlier, not the category norm — at least as far as the July 2026 reporting establishes. Comparative press coverage of the incident characterized Claude Code, Codex CLI, and Gemini CLI as transmitting only the specific files an agent opens for a task, not the full workspace. One honesty note before the table: that characterization comes from press coverage of the incident, not from Cereblab-grade wire audits of those three tools — nobody, to our knowledge, published equivalent captures for them in this window. The table separates the two evidence classes explicitly.

The right way to read this table is not “three tools are safe, one was not.” It is that only one row has wire-grade evidence behind it — the damning one. The other three rows describe the reported design intent of tools that happen not to have been audited this way in public. If the Grok Build incident has a market-level consequence, it should be that the evidence-basis column stops being a distinction anyone has to draw — because reproducible transmission audits become a normal thing vendors publish and buyers demand.

Here is the trend this incident actually confirms, and it is bigger than one vendor. Agentic coding tools have acquired production-level access to the most sensitive asset most companies own — their codebase, with its embedded credentials, infrastructure topology, and commercial logic — while the trust model around them is still largely social: a settings screen, a marketing page, a founder’s post. The Grok Build scandal is what happens when someone finally checks the wire. The asymmetry it revealed — one afternoon of mitmproxy versus months of default trust from thousands of developers — is the real story, because that asymmetry exists for every agent CLI, not just this one.

Our projection: this becomes a procurement question within the year. Teams already run structured evaluations before adopting a new model — the same discipline we describe in building an LLM eval harness to qualify new models — and transmission behavior will join capability in that qualification gate. Expect enterprise buyers to start asking agent vendors the questions this incident taught everyone to ask: what leaves the machine, on which channels, governed by which controls, owned by whom. Vendors with good answers will publish them before being asked.

Until then, the burden sits with adopting teams. Four controls actually hold — none of them is a checkbox:

And the immediate hygiene item stands regardless of tool: if an agent with undisclosed transmission behavior has touched repositories containing live credentials, rotate them. Secrets hygiene — keeping credentials out of git history entirely, so a whole-history bundle has nothing to leak — is the one defense that works even when the vendor’s switch fails. This is the kind of agent-adoption groundwork our AI transformation engagements formalize: tool-by-tool transmission review, retention contracts, and rollout guardrails before an agent ever meets production code.