xAI Open-Sources Grok Build After Its Coding Agent Silently Uploaded Entire Repos

xAI's Grok Build coding assistant was quietly shipping developers' entire Git repositories — complete commit histories, unread files, and unredacted secrets — to a company-controlled Google Cloud Storage bucket, according to a security researcher whose wire-level capture of the traffic touched off one of the year's more revealing debates about AI vendor trust. Days later, xAI disabled the behavior and open-sourced the tool. For CISOs weighing whether their organization's Grok usage needs review, the answer hinges on separating what is confirmed from what remains a vendor promise.

What actually happened

The disclosure came not from xAI but from a researcher publishing under the handle cereblab, who routed the Grok Build CLI (version 0.2.93) through a proxy and captured its network traffic. The finding was stark: on launch, the tool created a bundle of every tracked file plus full commit history from the working directory and uploaded it to a bucket named grok-code-session-traces — named explicitly in the binary and in a staged metadata.json.

The byte split is hard to dispute. On a 12 GB repository the model never read, the model-turn traffic to the /v1/responses endpoint came to roughly 192 KB, while the separate storage channel to /v1/storage moved 5.10 GiB — a gap the researcher measured at about 27,800 times more data than the task required. (Axios, in a widely cited figure, put the ratio at roughly 26,000x for the same test.) The upload ran as 73 chunks of about 75 MB, each returning HTTP 200.

Critically, the grab captured a file the agent had been explicitly instructed not to open — src/_probe/never_read_canary.txt, planted with a unique marker — because permission-deny blocks reading, not uploading. A tracked .env file the agent did read went into the model turn unredacted, canary API_KEY and DB_PASSWORD values and all. The planted secrets were fake, so nothing real leaked in the test itself. The behavior is the problem.

B
Uploads to grok-code-session-traces bucket
Secrets, history, unread files leave the machine
E
Grok Build launches] --> B[Bundles tracked files + full git history
Model reads a file] --> E[Contents sent to model turn + storage archive

The setting most developers would reach for did nothing. With "Improve the model" turned off, Grok still uploaded the repository, and the server's own /v1/settings response kept returning trace_upload_enabled: true. That toggle governs model training — not whether code leaves the machine. Those were two different controls, and only one was exposed to the user.

The timeline

On July 13, 2026, after the report went public, the same 0.2.93 binary stopped making storage requests. cereblab retested six times and saw zero /v1/storage uploads; the server now returned disable_codebase_upload: true and trace_upload_enabled: false. Developer Peter Dedene reported the same flag on his account, confirming this was not a single-machine fluke.

The tested client never changed versions — the shutoff was a server-side switch, not a patched update. A separate analysis of build 0.2.99 found the upload code still present in the binary, held off only by the server flag. In other words, xAI can turn it back on without shipping anything.

Days later, xAI open-sourced the full Grok Build codebase on GitHub under the Apache 2.0 license, allowing the tool to run locally. Elon Musk escalated further, pledging to open-source the entirety of X's codebase "with no exceptions" once a security review completed, and to invite third-party reviewers "to confirm that the open source code is what is running."

What was exposed, and who is affected

The vector was the CLI's own telemetry pipeline — not a server intrusion. There is no confirmed evidence that outside parties accessed the grok-code-session-traces bucket. The demonstrated risk is xAI's possession of the data, plus the latent exposure if such a bucket were ever breached.

Independent security researcher Dr. Lukasz Olejnik said the collected data could include proprietary source code, infrastructure details, credentials, personal information, and security documentation. Because commit history was swept in, a secret committed and later deleted still rode along in the bundle.

Motive: fix, deflection, or both

The evidence cuts more than one way. The transparency framing is supported by a real code release and a reviewer invitation. But the deflection reading is equally grounded: the release came after the exposé, the flaw was researcher-discovered rather than self-disclosed, and open-sourcing conveniently neutralized a competitive jab.

That jab came from OpenAI CEO Sam Altman, who called the incident "concerning" on X and added it was "a reason to favor open-source harnesses." The irony is that OpenAI's own Codex CLI is already open-source — Altman was scoring a market point. Musk complicated his own message further: while promising all prior data would be "completely and utterly deleted," he also argued that retaining "some" data was useful for debugging — asking developers to keep trusting a tool caught doing the opposite of what it claimed.

How peers have handled comparable disclosures

The contrast with rivals is where the story sharpens for vendor-risk teams. Anthropic handled a comparable client-side flaw in Claude Code — CVE-2025-52882, a WebSocket origin-validation bypass — through a formal CVE and coordinated disclosure. OpenAI open-sourced its Codex CLI by design, not as a breach response. Google operates a mature disclosure pipeline with a standard security.txt.

xAI, by contrast, has addressed this incident on X rather than through a security advisory or changelog, publishing neither the scale of the problem, the number of affected users, nor how long repositories were retained. That gap echoes a documented 2025 pattern in which xAI lacked a proper security-contact and incident-response pipeline — suggesting structural weakness rather than a one-off. Agentic coding CLIs are an emerging attack surface across every vendor, but wholesale collection of the entire workspace was, in cereblab's cross-tool comparison, specific to Grok Build; Claude Code and Codex sent no repository bundle.

What to do now

For anyone who ran Grok Build, waiting on xAI is not the move:

1. Check your logs. Upload events indicate your repository was shipped:

cat ~/.grok/logs/unified.json | grep repo_state.upload

2. Rotate every credential that lived in affected repos or their git history — API keys, database passwords, cloud credentials, and SSH keys — including any secret committed and later removed.
3. Move to the open-source local-first build and verify no network calls reach xAI hostnames.
4. Sandbox coding agents in an isolated network namespace with a filtering proxy that permits only the model provider's hostname.
5. For ZDR customers: obtain written confirmation of deletion. Musk's "utterly deleted" is a post, not an audit.

Open-sourcing the client is a real improvement — it removes the upload path and makes the harness auditable. But it does not prove what xAI's servers run, which is precisely why Musk's third-party-reviewer promise matters and why, until it is fulfilled, "trust through total transparency" remains a pledge rather than a verified state. xAI has not published a security advisory addressing the scope, retention period, or number of affected users, and did not provide an on-record technical response beyond statements posted to X.