xAI Open-Sources Grok Build’s Code but Keeps Its Kill Switch

xAI published all 844,530 lines of Grok Build’s Rust source code on Wednesday, hours after developers learned the coding tool had been silently uploading their codebases to company servers. The release is being framed as a transparency fix. Developers who read the new code say the mechanism that caused the crisis is still sitting inside it, switched off by a flag xAI controls, not the person running the tool.

That distinction is the whole story this week. xAI can turn full-repository uploads back on for any account, at any time, without shipping a new binary or a changelog entry. Nothing in Wednesday’s release changes that.

844,530 Lines of Rust, Released Under Pressure

xAI open-sourced Grok Build, its terminal-based coding agent, under the Apache 2.0 license on Wednesday, publishing the harness to GitHub. The company framed the release as the most direct path to a reliable harness, saying developers could now read the source to see exactly how context assembly and tool dispatch work.

The dump covers four areas: the agent loop that assembles context and dispatches tool calls, the tools that read and edit code and run shell commands, the agent loop, tools, and terminal interface now public, and an extension system for skills, plugins, hooks, and subagents. Independent developers who ran a line-count tool against the repository confirmed the 844,530 figure, noting it dwarfs what most people assume a terminal coding wrapper looks like. For comparison, OpenAI’s competing Codex CLI runs to roughly 950,933 lines of Rust, a fact that surprised several developers who examined both.

Buried in the code are tool implementations lifted from rivals. The harness ports apply_patch, grep_files, list_dir, and read_dir from OpenAI’s Codex, plus bash, edit, glob, grep, read, skill, todowrite, and write from the open-source OpenCode project, disclosed in a third-party notices file to satisfy the Apache and MIT licenses those projects use.

What Cereblab’s Wire Capture Proved

The crisis began with a researcher publishing as cereblab, who routed Grok Build CLI version 0.2.93 through mitmproxy, a free tool that intercepts and displays a program’s network traffic in plain text, on July 12. The test found two channels running every session: a model-turn channel moving roughly 192 kilobytes of task-relevant content, and a storage channel quietly uploading 5.10 gigabytes in 73 chunks of about 75 megabytes each. Every one of those 83 storage requests returned a successful response. Zero failures.

That is a gap of roughly 27,800 times more data leaving the machine than the coding task required. To prove the upload was not limited to files the agent touched, cereblab planted a canary file and told Grok Build not to open it. The agent complied, replying only “OK.” The published wire capture of the upload shows the storage channel moved the entire repository anyway, and cloning the recovered bundle pulled back the untouched canary file along with the repository’s complete commit history. The researcher then repeated the test on a second, unrelated codebase and got the same result, ruling out a one-off fluke.

xAI had marketed Grok Build as local-first, with nothing from a codebase transmitted to its servers during a session. The wire data contradicted that directly, and the finding reached the front page of Hacker News within two days.

Why Didn’t the Privacy Toggle Stop the Uploads?

Grok Build’s “Improve the model” toggle only ever controlled whether xAI could use a developer’s data to train future models. It never controlled whether the repository left the machine in the first place. Those are two separate systems inside the product, and only one of them was ever exposed to users as a setting they could change.

After cereblab disabled the toggle and reran the tool, the server’s own settings endpoint kept returning trace_upload_enabled: true, and the storage channel kept accepting chunked uploads without interruption.

The point is that /privacy is a per-session retention toggle, not the switch that fixes things.

Cereblab made that distinction after xAI, responding to the incident on July 14, pointed affected users toward a new /privacy command as the fix. The command changes retention status and can delete previously synced data. It does not, and never did, stop a repository from being transmitted in the first place. The actual fix, a server-side flag called disable_codebase_upload: true, arrived quietly on July 13, a day before xAI said anything publicly. Cereblab retested the same binary six times afterward and recorded zero storage uploads each time. A separate developer, Peter Dedene, reported the identical flag on his own account, confirming the change reached beyond a single test machine.

A Deleted Secret Still Lives in Git History

The upload traveled as a Git bundle, a single file that packages a repository’s tracked contents and its entire commit history in one package. That format matters more than the raw gigabyte counts suggest.

A developer who removed a password from a .env file six months ago and considers the exposure fixed is still exposed if that password was ever committed to a tracked file. The bundle carries the object history regardless of what the working directory looks like today. Standard advice, delete the file and rotate today’s secrets, does not cover this incident. Rotation has to reach every credential that ever appeared in a tracked file or anywhere in the project’s Git history, including entries removed from the working tree long before Grok Build was installed.

Files that were gitignored and never committed appear to have stayed out of the bundle, though cereblab did not test that exhaustively. The safest working assumption for any developer: if a secret was committed at any point, assume it reached xAI’s servers.

• Rotate every API key, database password, or cloud token that ever appeared in a tracked file, even ones removed months ago.
• Treat SSH keys and credentials that were committed and later deleted from Git history as exposed, since a bundle carries the full object history.
• Confirm whether zero data retention (ZDR), an enterprise configuration that never stores code or trace data, was active before July 13; if not, assume the repository reached the grok-code-session-traces bucket.
• Check whether internal data-handling agreements or regulatory obligations require formal notification of customers or authorities.

None of this is optional for teams that ran the tool against proprietary code before the server-side fix landed.

Grok Build Was the Outlier Among Its Rivals

Grok Build launched in public beta in May 2026, open to SuperGrok Heavy subscribers before expanding across SuperGrok and X Premium Plus tiers. It entered a field that already included Anthropic’s Claude Code, used by roughly 18% of professional developers by mid-2026, OpenAI’s Codex CLI, and Google’s Gemini CLI.

Cereblab ran the identical wire-capture methodology against all three competitors. None showed a parallel full-repository channel.

That comparison does not clear the other three tools of every data-handling question. It does establish Grok Build’s July 2026 behavior as a documented outlier among terminal coding agents, not an industry norm.

Where xAI’s Account Still Has Gaps

xAI’s response has run entirely through executive posts on X rather than a formal security advisory or incident timeline. Elon Musk wrote that “all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted.” OpenAI’s chief executive, Sam Altman, called the behavior “concerning” in his own public comment on the episode.

What We Know

• Grok Build 0.2.93 uploaded complete Git bundles to a bucket named grok-code-session-traces, confirmed by cereblab across two repositories and six retests.
• The “Improve the model” toggle had no effect on uploads; the server kept reporting trace_upload_enabled: true after users opted out.
• The server-side flag that stopped new uploads on July 13 was verified independently on a second developer’s account.
• The upload code remains inside the published source. The function upload_session_state() now returns a hard-coded error rather than being deleted.

What’s Unconfirmed

• How many users were affected, or how much data Grok Build collected since its May 2026 beta launch.
• Whether repositories already stored in Google Cloud have actually been purged, with no third-party audit offered.
• Whether the server-side flag is a permanent, global setting rather than a reversible one.

xAI says Grok Build complies with SOC 2 Type 2, an independent audit standard for how companies handle customer data, along with the European Union’s General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA). Ireland’s Data Protection Commission has had a separate statutory inquiry into xAI’s broader GDPR compliance open since April 2025, unrelated to this specific incident but relevant to how any regulator would view it. Security firm Hive Security, in a writeup of the incident, called the server-side switch a mitigation that matters but not a lasting fix, since a remote flag can change without any new code reaching a developer’s machine.

Should You Run Grok Build Now?

For individual developers on personal repositories, the upload channel appears off as of July 13, and the source is now readable enough to verify that independently. The remaining concern is narrow but real: the code to resume uploads still compiles into the binary, and the only control is a flag on xAI’s servers.

For teams working on proprietary code, the calculus is harder. There is still no formal incident report, no published user count, and no audit trail proving deletion happened. The open-source release adds a third option beyond the cloud path and the privacy toggle: compile Grok Build from source and point it at a self-hosted inference server, an approach that fits into a stack builders are assembling around centralized providers’ gaps. Whether a meaningful share of developers actually adopt that fully local mode, instead of the subscription-based cloud path most were already using, is still an open question. Any organization that ran Grok Build without ZDR enabled before July 13 is still deciding whether that counts as a reportable incident under its own data-handling agreements.

Frequently Asked Questions

Does the Open-Source Release Work on Windows?

Not fully. The published build documentation lists macOS and Linux as supported build hosts, while Windows builds are described as best-effort and untested from the current source tree. Developers on Windows can still install the compiled CLI through the normal installer, but compiling the open-source harness themselves, the path that keeps data off xAI’s servers entirely, is not yet a reliable option on that platform.

How Does This Compare to xAI’s 2024 Grok-1 Release?

xAI has open-sourced before, but not like this. In March 2024 it released Grok-1, a 314 billion parameter base model shared under the same Apache 2.0 license, publishing weights and architecture rather than a live product’s operating code. Grok Build is different in kind: it is the actual harness handling a developer’s files and shell commands, and until July 13, the same pathway that quietly uploaded them.

Does Compiling From Source Guarantee My Code Never Leaves My Machine?

Not automatically. Running Grok Build against a self-hosted inference server removes xAI’s servers from the model conversation itself. It does not guarantee every telemetry or authentication channel in a given build has been eliminated. Developers handling regulated data are better off inspecting the source and capturing their own network traffic before trusting any local build with sensitive repositories.

Can Outsiders Verify xAI’s SOC 2 Compliance Claim?

Not without a signed agreement. xAI says Grok Build meets SOC 2 Type 2 standards, but obtaining the actual report requires signing a non-disclosure agreement with the company first. That leaves independent researchers, the same community that found the upload behavior in the first place, without public access to the audit meant to back up the compliance claim.

Where Do I Report a Security Bug in Grok Build?

Through xAI’s bug bounty program rather than GitHub. The company points researchers to its bug bounty program on HackerOne, and GitHub’s issue tracker is disabled on the new repository. xAI’s contributing guidelines also state plainly that external code contributions are not accepted, so the release is meant for reading and running the harness, not sending patches back.