xAI open-sourced its Grok Build terminal coding agent on Wednesday under the Apache 2.0 license, releasing 844,530 lines of Rust to GitHub hours after the tool's covert full-repository upload behavior exposed developer SSH keys, credentials, and commit histories to the company's Google Cloud Storage infrastructure. The move is the most direct response xAI has made to the incident — but security researchers have confirmed that the code capable of exfiltrating entire codebases remains present in the published binary, held off only by a server-side configuration flag that xAI can re-enable without pushing a software update.

Any developer who ran Grok Build before July 13, 2026 in a directory containing a Git repository should treat every credential in their tracked files and commit history as potentially transmitted to xAI's servers — including API keys, database passwords, cloud tokens, and SSH keys committed and later removed from working files months ago.

The Upload Behavior Was Not What xAI's Marketing Said

The crisis was documented by a security researcher publishing as cereblab, who routed Grok Build CLI version 0.2.93 through the open-source network interception proxy mitmproxy on July 12. The analysis revealed that every session triggered two simultaneous network channels: a model-turn channel (POST /v1/responses) that transmitted roughly 192 KB of task-relevant content, and a storage channel (POST /v1/storage) that uploaded 5.10 gigabytes of data in 73 chunks of approximately 75 MB each — a ratio of roughly 27,800 times more data than the coding task required.

The storage channel routed to a Google Cloud Storage bucket named grok-code-session-traces, under paths of the form gs://grok-code-session-traces/repo_changes_dedup/v2/. The data was transmitted as a Git bundle — a single binary file packaging the repository's entire tracked contents plus its complete commit history. cereblab cloned the captured Git bundle and recovered a file the agent had been explicitly instructed not to open, proving the upload covered the full workspace rather than only the files the model accessed during the session.

xAI had marketed Grok Build with the claim that "nothing from your codebase" was transmitted to its servers during a session. The wire captures directly contradict that claim.

Neither the "Improve the Model" Toggle Nor the /privacy Command Fixed It

The disclosure that most damaged xAI's initial response was not the upload itself but what the upload ignored. Grok Build ships with an "Improve the model" toggle, the natural reading of which is a data-collection control. Disabling it did nothing. The server's own /v1/settings response continued returning trace_upload_enabled: true, and the storage channel transmitted the full repository regardless.

When xAI responded to the incident on July 14, company staff directed affected users to run the /privacy CLI command as the means to change their exposure. cereblab disputed that framing publicly: "What actually stopped the upload was a silent global flag — disable_codebase_upload: true — that applies whether you opt in or out. /privacy is a per-session retention toggle, not the switch that fixed this, and no developer should have to run an opt-out after every session to keep their own code off someone else's servers. The right default is off."

This distinction matters for how enterprises evaluate the remediation. The training-consent control and the data-transmission control are architecturally separate in Grok Build's design — and the user-facing toggle governed only the former. Whether xAI's marketing language that conflated them was an oversight or a deliberate framing choice, the effect was that security-conscious developers who had disabled data sharing were still transmitting their full repository history.

What Git Bundle Format Means for Deleted Secrets

The use of the Git bundle format as the upload vehicle creates a specific risk that the raw volume figures do not fully capture. A Git bundle is a single-file representation of a repository's complete object history — every commit, every version of every tracked file, including content that was subsequently deleted from the working tree.

This means that a developer who removed a secret from their .env file six months ago and considers the exposure remediated is still exposed if that secret was ever committed to a tracked file: the Git bundle carries the full history. Standard remediation advice — "delete the .env file and rotate the secrets you use today" — is insufficient for this incident. Rotation must cover every credential that ever appeared in a tracked file or anywhere in the repository's Git history, including entries deleted from the working tree long before Grok Build was installed.

The analysis showed that gitignored files that were never committed appear to have stayed out of the bundle, though this was not exhaustively tested by cereblab. The strongest defensible position for any developer is: if a secret was committed at any point in the repository's history, assume it was transmitted.

Open-Sourcing Is Structural but the Upload Code Is Still There

xAI's open-source announcement frames the release primarily as a transparency measure. "Publishing the code is the most direct way to build toward a robust and reliable harness," the company wrote. "You can read the source to see exactly how it works, from context assembly to tool-call dispatch."

The 844,530 lines of Rust published to github.com/xai-org/grok-build cover four main areas: the agent loop, which handles context assembly, model response parsing, and tool-call dispatch; the tools for reading, editing, and searching code and running shell commands; the fullscreen terminal user interface with its plan-review and inline diff viewer; and an extension system supporting skills, plugins, hooks, MCP servers, and subagents.

Developers who examined the repository confirmed what security researchers had warned: the upload infrastructure is present and legible in the source. The file xai-grok-shell/src/upload/gcs.rs contains the code for writing to a Google Cloud Storage bucket. The function upload_session_state() in upload/trace.rs now returns a hard-coded session_state_upload_unavailable error, meaning the pathway exists in code but is blocked at the function level.

Simon Willison, a developer whose analysis of the repository reached a wide technical audience, noted that the upload infrastructure being "disabled rather than removed" in the open-sourced code is a meaningful observation. Because the current mitigation is a server-delivered flag (disable_codebase_upload: true) rather than a client-side code change, xAI retains the technical ability to re-enable full-repository uploads for any or all users without publishing a new binary. Security firm Hive Security, in a writeup of the incident, characterized the server-side flag as "a mitigation that matters, but not a durable client-side security boundary."

The repository was released in a single commit, with no prior development history visible, and xAI's CONTRIBUTING.md explicitly states that external contributions are not accepted. The codebase also includes tool implementations ported from OpenAI's Codex (apply_patch, grep_files, list_dir, read_dir) and the open-source OpenCode project (bash, edit, glob, grep, read, skill, todowrite, write), which xAI documented in a THIRD_PARTY_NOTICES.md file in compliance with the Apache and MIT licenses those projects use.

For comparison, OpenAI's Codex repository contains roughly 950,933 lines of Rust — a figure that surprised many observers who had assumed terminal coding agents were relatively thin wrappers around API calls.

What xAI Has and Has Not Committed To

xAI's response to the incident arrived via executive posts on X rather than through a formal security advisory, an incident timeline, or a changelog entry. Elon Musk posted on July 14 that "all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain." The company separately confirmed that its zero data retention (ZDR) configuration — available to enterprise accounts — had never retained code or trace data, and that API key users also benefit from ZDR.

What xAI has not provided: the number of affected users, the total volume of data collected since Grok Build entered beta in May 2026, a method by which individual developers can verify whether their specific data has been deleted, a timeline for completing the deletion, or any third-party attestation that the deletion has occurred. The deletion pledge, as security analysts noted, carries no audit mechanism — the same transparency gap that made the original upload scandal consequential.

The July 13 server-side fix has been independently retested. cereblab retested the same 0.2.93 binary six times after the server flag was set and observed zero storage channel uploads in each run. A separate developer, Peter Dedene, reported the same flag on his account, confirming the server-side change applied beyond a single test installation. But the caveat applies in both directions: the mitigation was verified on a limited number of machines and accounts, and xAI has not confirmed whether it applies globally and permanently.

For enterprises that ran Grok Build against private or proprietary repositories — including environments where GDPR obligations, NDA coverage, or regulatory frameworks govern code sharing with third parties — xAI's response to date offers no compliant path to audit the scope of their exposure or document the deletion for regulatory purposes. xAI claims compliance with SOC 2 Type 2, GDPR, and CCPA, but access to the formal SOC 2 report requires a signed NDA, and Ireland's Data Protection Commission has had a formal statutory inquiry into xAI's broader GDPR compliance open since April 2025.

Where Grok Build Fits in a More Competitive Market

Grok Build launched in public beta in May 2026, initially available to SuperGrok Heavy subscribers before expanding to all SuperGrok and X Premium Plus tiers. The tool runs as a terminal-native AI coding agent — a full-screen, mouse-interactive TUI that can read and edit files, execute shell commands, search the web, and delegate subtasks to parallel subagents operating in separate Git worktrees. It operates on xAI's purpose-built coding model and supports plan-based workflows where developers can review proposed changes before execution begins.

It entered a competitive field that includes Anthropic's Claude Code, launched in early 2025 and used by approximately 18% of professional developers as of mid-2026; OpenAI's Codex CLI; and Google's Gemini Code Assist. cereblab's comparative testing found that Claude Code, Codex CLI, and Gemini sent only the files their agents opened during a task — a narrower boundary than Grok Build's whole-workspace upload. That comparison does not make those tools exempt from scrutiny on other dimensions of their data handling, but it establishes Grok Build's July 2026 behavior as a documented outlier in the category.

The open-source release adds a third path for developers: compile Grok Build from source, point it at a self-hosted inference server, and route no data to xAI's infrastructure at all. Whether a meaningful portion of the developer community will operate Grok Build in that fully local mode, rather than using the cloud inference path that requires a SuperGrok or X Premium Plus subscription, is an open question.

Should Developers Run Grok Build Now?

For individual developers using personal repositories, the upload channel appears to be off as of July 13, and the open-source release makes the behavior independently auditable. The key remaining concern is that the code to resume uploads is present in the binary and the control mechanism is a server-side flag.

For teams and enterprises working on proprietary code, the calculus is different. The incident has not produced a formal incident report, a documented deletion audit, or a mechanism for organizations to verify that their specific repositories have been purged from grok-code-session-traces. xAI's enterprise ZDR tier was specifically designed to address this, but it requires an enterprise account and is not available to consumer or individual API subscribers. Any organization that ran Grok Build without ZDR enabled before July 13 should rotate all credentials from those repositories and assess whether their data handling agreements with customers or regulators require formal incident notification.

The open-sourcing of Grok Build is a significant move — one that makes the tool's behavior auditable in a way that closed-source competitors cannot match. But a codebase being readable is not the same as a codebase being safe. The trust restoration project for Grok Build is not complete with the publication of source code; it will be complete when xAI provides a verifiable account of what was collected, on whose behalf, for how long, and what happened to it.

Frequently Asked Questions

Did Grok Build upload my code to xAI's servers?

If you ran Grok Build CLI before July 13, 2026, the answer is likely yes for any directory that contained a Git repository. Security researcher cereblab documented using mitmproxy that Grok Build 0.2.93 transmitted full Git bundles — containing all tracked files plus the repository's complete commit history — to a Google Cloud Storage bucket named grok-code-session-traces. The upload ran regardless of whether you had disabled the "Improve the model" toggle. xAI set a server-side flag on July 13 that stopped the uploads; the upload code remains present in the binary. If your repository contained API keys, database passwords, cloud tokens, or SSH keys at any point in its tracked history — even if you deleted them from working files — rotate those credentials now.

Is the open-source release enough to trust Grok Build with private repositories?

The open-source release is a meaningful step because it makes the upload architecture independently auditable. However, three structural concerns remain. First, the code capable of transmitting full repositories to Google Cloud Storage is still in the binary; it is held off by a server-side flag, not removed from the client. Second, xAI controls that flag and can re-enable the behavior for any or all users without pushing a software update. Third, xAI has not published a deletion audit, affected user count, or mechanism for developers to verify their specific data was purged. The open-source release lets you verify what the code does; it does not provide certainty about what the server will instruct it to do in the future. For sensitive work, the most protective option is to compile Grok Build from source and run it against a self-hosted inference server, removing xAI from the data pipeline entirely.

What is the difference between the /privacy command and what actually stopped the uploads?

They are architecturally separate controls. The /privacy command in Grok Build is a per-session retention toggle: it governs whether data that has already been transmitted is used to train xAI's models, and it can trigger deletion of previously synced data. It has no effect on whether your repository is transmitted to xAI's servers in the first place. What actually stopped the full-repository uploads on July 13 was a server-side configuration flag, disable_codebase_upload: true, that xAI set globally. cereblab confirmed this after testing: "The right default is off." Any developer who ran /privacy after the incident and believes that resolved their transmission exposure should understand that the two controls govern different things: what leaves your machine versus what is done with it after it arrives.

How does Grok Build's data handling compare to Claude Code, Codex CLI, and Gemini?

cereblab's comparative wire-level analysis tested all four tools using the same mitmproxy methodology. Claude Code, Codex CLI, and Gemini each transmitted only the files their agents opened for a given coding task — roughly the 192 KB range consistent with task-relevant content. None of the three showed the parallel full-repository upload channel that Grok Build used. That comparison establishes Grok Build as a documented outlier in the current generation of terminal coding agents, though it does not exempt those competitors from independent scrutiny of their own data handling practices.