A security researcher has published wire-level evidence showing that xAI's Grok Build CLI was uploading entire developer repositories to a Google Cloud Storage bucket, including files the coding agent never opened and credentials stored in .env files. According to International Cyber Digest, the behavior has since stopped via a hidden server-side flag. xAI has issued no advisory, no explanation, and no statement on what happens to code already collected.
The findings come from a researcher publishing under the handle cereblab, who routed Grok Build CLI version 0.2.93 through the interception proxy mitmproxy and released the captures as a public gist. The analysis showed the client bundling the entire tracked repository, including full Git history, and uploading it to a Google Cloud Storage bucket named grok-code-session-traces. The upload ran independently of the files the agent actually opened for its coding task.
The Numbers Tell the Story
The scale is what makes this case stand apart from routine AI telemetry. On a 12 GB test repository, the model-turn channel moved about 192 KB of task-relevant traffic. The storage upload channel moved roughly 5.1 gigabytes across 73 chunks. Every storage request returned HTTP 200. Zero failures. The researcher later cloned a file from the captured bundle that the agent had been explicitly told not to read, proving the upload was not scoped to what Grok accessed but to everything in the workspace.
A canary credential planted in a .env file appeared verbatim and unredacted in the captured traffic. Any team that pointed the CLI at a private or proprietary codebase handed xAI an undisclosed copy of its source history, credentials, and secrets along with it.
The Opt-Out That Did Not Stop the Uploads
Grok Build ships with an "Improve the model" toggle that most developers would read as a data-collection control. Disabling it did not stop the uploads. Server responses still returned trace_upload_enabled: true, and the repository transfer proceeded as normal. The setting governs training consent, not whether code leaves the machine.
Neither the storage bucket nor the upload behavior appears in Grok Build's setup documentation. This is particularly notable given that xAI had marketed the tool with claims like "nothing from your codebase transmitted to xAI servers during a session." The wire data contradicts this directly.
A Silent Fix, No Explanation
Follow-up testing by the same researcher found that a new server-side flag, disable_codebase_upload: true, has stopped the repository uploads. The fix arrived about a day after the wire-level analysis was published. But the mitigation has only been verified on one machine and one account. There is no confirmation from xAI that the change is global, staged, or permanent.
The official changelog listed version 0.2.98 as the latest release on July 12, 2026, without mentioning repository-upload behavior at all. No security advisory. No explanation of the upload's purpose, scope, or retention period. No word on whether repositories already sitting in grok-code-session-traces will be deleted. The public xAI status page showed no active declared incident.
The researcher is explicit about what the captures do and do not prove: the evidence shows undisclosed transmission and storage, not that xAI trained on the uploaded code, that employees viewed it, or that every account received the same configuration. That distinction matters. But it also underscores what is missing from xAI's response: anything at all.
What This Means for Developers
The broader pattern here extends beyond one company's coding agent. AI tools that read local files increasingly operate with access levels that make undisclosed data collection architecturally possible. For developers in regulated industries or those working with proprietary code, what crosses the wire matters more than what a settings page promises.
If you ran Grok Build against a codebase containing real credentials, assume those credentials were transmitted. Rotate API keys, database passwords, and cloud tokens. Deleting the local .env file does not invalidate a credential already exposed.
The AI coding agent market is competing hard on developer trust right now. Competitors like Claude Code, Codex CLI, and Gemini CLI did not show equivalent whole-repository uploads in the researcher's canary tests. Whether xAI's silence reflects a calculation that the story will blow over or an internal scramble to understand what happened, the absence of a formal response leaves enterprises with no compliant path forward. Anyone who ran the affected binary against a private repository is now holding an undisclosed third-party copy of their source history and no documented way to verify what xAI retained or request deletion.
