What specific types of data did Grok Build upload without disclosure?

Grok Build version 0.2.93 uploaded the entire tracked Git repository as a bundle, including files the model never opened, deleted files still present in commit history, and the full commit log. When Grok read any tracked file, its complete contents appeared unredacted in both the live model-turn channel and in a session archive. In the researcher's test, planted .env files containing fake API keys and database passwords were transmitted with zero redaction safeguards.

Was my code used to train Grok models?

xAI has not confirmed or denied whether uploaded repository contents were used for model training. Elon Musk stated that previously uploaded user data would be deleted, but xAI has not published any explanation of the storage duration, what processing the data underwent before deletion, or whether data uploaded before the July 13 server-side fix has actually been purged. Standard data retention caveats apply: code transmitted over the network may have already been processed, indexed, or used in ways that make deletion claims difficult to verify.

What should developers do if they used Grok Build before July 13, 2026?

Rotate any secrets that were present in your repository: API keys, database passwords, SSH keys committed by accident, service account credentials. Review your .git history for credentials that were committed and later removed (these were still present in the bundle Grok Build uploaded). If your repository includes secrets in any tracked file, not just .env, treat those credentials as potentially compromised. Audit which xAI storage logs can be accessed and run the /privacy command in the Grok Build CLI to request deletion of previously synced data.

Grok Build Uploaded Your Whole Git Repo: xAI Secrets Leak Explained

An independent researcher intercepted network traffic from xAI’s Grok Build coding assistant and found the tool was uploading entire Git repositories — including full commit history and unredacted credentials — to a Google Cloud Storage bucket, without disclosing this behaviour to users. The upload-to-use ratio was 27,800:1. xAI applied a server-side fix on July 13, 2026, but left core questions about data retention and training use unanswered.

Incident Summary

Field	Detail
Product	Grok Build CLI v0.2.93 (xAI)
Behaviour	Full Git repository upload to cloud storage, undisclosed and enabled by default
Storage destination	Google Cloud Storage: `grok-code-session-traces` bucket
Data transmitted	Entire tracked repository bundle: all tracked files, staged files, full commit history
Credential exposure	API keys, database passwords, SSH keys in commit history — transmitted unredacted
Upload-to-use ratio	192 KB model traffic vs 5.10 GB storage upload (27,800:1)
Researcher	cereblab (independent)
xAI fix	Server-side flag (`disable_codebase_upload: true`) applied 13 July 2026
Client update	None — upload code remains in 0.2.93 binary; server flag controls execution
Open-source release	Grok Build released under Apache 2.0 within 24 hours of disclosure
Unanswered	Training use of uploaded data, retention duration, number of users affected

Timeline

Prior to 13 July 2026: Grok Build CLI v0.2.93 uploads entire tracked Git repository bundles to grok-code-session-traces on Google Cloud Storage at the start of every session. This behaviour is not disclosed to users. The “Improve the model” preference in Grok Build governs data retention, not data collection — a distinction not communicated in the product UI.

Before 13 July 2026 (researcher investigation): Researcher cereblab intercepts network traffic during a Grok Build session. Model endpoint /v1/responses receives 192 KB. Storage endpoint /v1/storage receives 5.10 GB. Cereblab plants canary file src/_probe/never_read_canary.txt — a file Grok is never directed to open. It appears in the storage upload. Planted .env files with fake API_KEY and DB_PASSWORD values transmit verbatim and unredacted in both the live response stream and session archive.

13 July 2026: xAI applies a server-side fix. The /v1/storage endpoint returns disable_codebase_upload: true and trace_upload_enabled: false for existing 0.2.93 binaries. Repository uploads stop without a client update.

14 July 2026: xAI open-sources Grok Build under Apache 2.0. Elon Musk posts on X stating previously uploaded user data will be deleted. No formal security advisory or changelog entry is published; disclosure is handled through social media.

21 July 2026: Questions about training use of uploaded data, retention period before the fix, and number of affected users remain unanswered.

What Was Actually Being Transmitted

Grok Build 0.2.93 packaged the entire tracked Git repository as a bundle and shipped it to a bucket named grok-code-session-traces. The bundle was not scoped to what the model accessed. It covered everything: tracked files, untracked files that were staged, and the full commit history.

That last part matters. Git commit history includes files that were committed and later deleted, which means credentials removed from a repository months ago were still present in the bundle. If a developer pushed an .env file, realised the mistake, and deleted it, the commit history kept a copy. Grok Build uploaded that copy along with everything else.

Cereblab’s canary test confirmed the behaviour was not limited to files Grok accessed during a session: the tool swept the entire working tree regardless of what was opened. When Grok did read files, their contents appeared unredacted in both the live response stream and the session archive.

xAI’s Response and What It Left Open

xAI moved fast on the technical fix. On July 13, the server returned disable_codebase_upload: true and trace_upload_enabled: false for the same 0.2.93 binary, stopping the uploads server-side without requiring a client update. Within 24 hours, xAI open-sourced Grok Build under Apache 2.0.

The communication was handled primarily through posts on X rather than a security advisory, a changelog entry, or a formal disclosure. A security advisory creates a traceable record and gives affected users clear remediation steps. A social media post does not. For developers trying to understand whether their code was exposed, xAI’s communication left several questions without clear answers.

Among the things still not disclosed: why repository uploads were enabled by default, how long uploaded data was retained before the server-side flag was applied, how many users were affected, and whether repository contents were processed for model training. The upload code also remains present in the 0.2.93 binary; the server-side flag controls whether it fires, but the behaviour lives client-side.

Remediation Guidance

For developers who used Grok Build before 13 July 2026:

Treat any secret in your repository’s tracked history as potentially exposed.

Rotate API keys, database passwords, and service credentials that appear in any tracked file — including files committed and deleted in the past
Run a dedicated secret scanning tool against your Git history — truffleHog or git-secrets are thorough; git log --all --full-history -- *env* *secret* is a starting point
Run /privacy in the Grok Build CLI to request deletion of previously synced data
If your repository is shared infrastructure for a team, treat this as a team-level rotation exercise

For organisations evaluating AI developer tooling:

Run network traffic interception tests before broad adoption of new AI coding tools. Plant canary files to detect covert transmission. What a tool accesses on your machine and what leaves your machine are two separate questions — verify both.

The Broader Pattern

The Grok Build case is part of a pattern building since 2024. AI coding assistants need access to your codebase to be useful. The question is whether the access is scoped to what the tool needs, disclosed to the developer, and governed by controls that actually work.

Grok Build’s particular problem was scope mismatch: a tool positioned as a local coding assistant was, by default, operating more like a remote code sync service. The session traces that went to cloud storage were comprehensive enough that xAI — or anyone with access to that bucket — would have had a complete picture of every repository a user worked with during the exposure window.