Threat · curated 14 Jul 2026
Grok Build Uploads Entire Git Repositories to xAI Storage, Not Just Files It Reads
First reported · updated · 2 reports cereblab.com
Coverage timeline
Why it matters
Grok Build's silent whole-repo uploads sent SSH keys, .env secrets, and password-manager databases off developer machines without consent, exposing how coding AI agents can become uncontrolled data-exfiltration channels.
AI safety researcher Cereblab found that xAI's Grok Build CLI uploaded users' entire Git repositories — including files it was explicitly told not to open and secrets deleted from Git history — as Git bundles to a Google Cloud Storage bucket, even on an idle 'reply OK' prompt. The behavior was reproduced across multiple codebases and captured on the wire via mitmproxy; xAI later disabled it server-side with a disable_codebase_upload flag and Musk promised deletion of uploaded data.
Summary
An AI safety researcher publishing as Cereblab found that xAI's Grok Build command-line coding assistant (versions v0.2.93 through 0.2.99) uploaded users' entire Git repositories — including full commit history and files it was explicitly told not to open — as git bundles to a Google Cloud Storage bucket named grok-code-session-traces, rather than only the files needed to answer a prompt. The researcher captured the transfer on the wire via an intercepting proxy and cloned the captured bytes back into a working repository.[0][2]
The blast radius included secrets deleted from Git history months earlier, which still rode along inside the uploaded bundle, and a read .env file whose contents went to the model endpoint. The finding was reproduced on a second unrelated codebase and corroborated by other researchers on their own private repos, and one user reported their entire home directory — including SSH keys and password manager databases — was uploaded.[0][2]
After the findings drew public attention, xAI made a server-side change so its servers return disable_codebase_upload:true, and the whole-repo uploads stopped. Cereblab stresses that this silent global flag, not the newly shipped /privacy command, is what actually stopped the transfers; /privacy only toggles server-side retention while the upload code still ships in the binary. Elon Musk publicly promised all previously uploaded user data would be deleted, which The Register noted it could not independently verify.[0][2]
Attack chain
- Data collection: When Grok Build read or processed a file, it packaged the entire repository — including files the user told it not to open and the full Git commit history — into a git bundle, going far beyond the files needed to answer the prompt.[0][2]
- Transmission and storage: The bundle was transmitted (POST to a storage endpoint, body magic '# v2 git bundle', returning HTTP 200) to the Google Cloud Storage bucket grok-code-session-traces used by xAI; read .env contents were sent to /v1/responses.[0][2]
- Verification of impact: The researcher cloned the captured wire bytes to reconstruct the repository verbatim, including the file marked never-read and secrets deleted from history months prior, and reproduced the behavior on a second unrelated codebase.[0][2]
- Server-side mitigation: xAI flipped a server-side flag so /v1/settings returns disable_codebase_upload:true (and trace_upload_enabled:false), halting the uploads without a client update, while the upload code remained in the binary.[0][2]
Disclosure timeline
| Date | Event |
|---|---|
| 2026-07-13 | Cereblab published its report on Grok Build's repository-upload behavior; the same client began returning disable_codebase_upload:true and the upload no longer fired.[0][2] |
| 2026-07-13 | xAI shipped a /privacy opt-out command and defaulted the codebase upload off; retested on Grok 0.2.99.[2] |
| 2026-07-14 | xAI (via @SpaceXAI), technical staff, and Elon Musk responded publicly on X; Musk promised all previously uploaded user data would be deleted. The Register published its account.[0] |
How it works
Cereblab routed Grok Build's traffic through mitmproxy with a locally-trusted CA and HTTPS_PROXY set, logging every request. Even on an idle prompt ('reply OK, do not open any files'), the CLI issued a POST whose body carried a v2 git bundle of the whole repository, which the researcher then reconstructed with git clone — recovering a file marked never-read verbatim plus secrets deleted from history months earlier.[2]
Turning off 'Improve the model' did not stop the upload: /v1/settings still returned trace_upload_enabled:true and the upload still fired. The later /privacy command sends PUT {"codingDataRetentionOptOut": true}, a server-side instruction not to keep data rather than a block on what is transmitted; an A/B test showed opt-in and opt-out send identical requests, with the only difference being /v1/traces returning 200 versus 204. The actual halt came from the silent global disable_codebase_upload:true flag.[0][2]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| Grok Build CLI (xAI) | v0.2.93 through 0.2.99 | Mitigated server-side: xAI's servers return disable_codebase_upload:true and default the codebase upload off; the upload code still ships in the 0.2.99 binary and is held off only by the server flag.[2] |
Key takeaways
- A coding agent's data-egress behavior can far exceed the files a task needs: Grok Build shipped whole repositories and full Git history — including deleted secrets — while other CLIs (Claude Code, Codex, Gemini) uploaded only files they opened.[0][2]
- A training-data opt-out is not a transmission control; the fix here was a silent server-side flag (disable_codebase_upload:true), not the user-facing /privacy retention toggle, and the upload code still ships in the binary so it could be re-enabled without a client update.[0][2]
- Committed secrets remain a liability regardless of later deletion, because full Git history rides along in such uploads; keeping sensitive values out of history and rotating exposed credentials is the reliable remediation.[0][2]
Defensive actions
- Rotate any credential Grok Build could have accessed, including secrets in tracked files and secrets present anywhere in Git commit history, even if later deleted.: The tool transmitted entire repositories and full commit history and read .env contents; secrets deleted from history months prior were still recoverable from the uploaded bundle.[0][2]
- Do not rely on the 'Improve the model' training toggle to keep code local; treat the /privacy command as a retention setting, not a transmission block.: With the training toggle off the repo was still uploaded and trace_upload_enabled stayed true; /privacy only sends a server-side retention opt-out while the upload code remains in the binary.[0][2]
- For non-enterprise users, run the /privacy command to disable retention and delete previously synced data; enterprise teams should verify zero data retention coverage. Monitor Grok Build's network behavior independently.: xAI states ZDR covers enterprise teams and API use, and offers /privacy to consumers; because the upload code remains behind a reversible server flag, defenders should not assume the change is permanent.[0][2]