Grok Build Uploads Entire Git Repositories to xAI Storage, Not Just Files It Reads

Summary

xAI's Grok Build coding CLI was found to upload entire Git repositories, including full commit history, to a Google Cloud Storage bucket. This occurred even when the AI was instructed not to access certain files or when the 'Improve the model' setting was disabled. The issue was addressed server-side, disabling codebase uploads.

Full text

Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read Swati KhandelwalJul 14, 2026Artificial Intelligence / Data Privacy xAI's Grok Build coding CLI was uploading entire Git repositories, full commit history and all, to a Google Cloud Storage bucket run by xAI, not just the files a coding task needed. A researcher publishing as cereblab, testing version 0.2.93, captured one of those uploads, cloned the git bundle out of the intercepted request, and pulled back a file the agent had been told in plain terms not to open. The upload rode a separate channel from the model itself, and the byte split is hard to argue with. On a 12 GB repo of files the model never read, model-turn traffic to /v1/responses came to about 192 KB while the storage channel to /v1/storage moved 5.10 GiB, a roughly 27,800x gap between what the model needed and what left the machine. That storage upload ran as 73 chunks of about 75 MB, every one returning HTTP 200, and across the researcher's size sweep the volume tracked total repo size. The destination bucket, grok-code-session-traces, is named in the binary and in a staged metadata.json whose per-file paths point at gs://grok-code-session-traces/. The unread file was src/_probe/never_read_canary.txt, planted with a unique marker. Cloning the captured bundle recovered it verbatim along with the repo's full commit history, and the same test replicated on a second, unrelated repo. What the captures establish is transmission, acceptance, and storage, not training. The teardown does not claim xAI trained on the code, that staff read it, or that gitignored files are always swept in. Tracked files plus history is what the wire shows. The secrets path is separate and simpler. When Grok reads a file, its contents go into the model turn, and a tracked .env went with them unredacted, canary API_KEY and DB_PASSWORD values and all. The same content also landed in a session_state archive bound for storage. The planted secrets were fake, so nothing real leaked in the test. The behavior is still the problem: a credential file the agent read during a task went out and was stored with no redaction. The setting most developers would reach for did nothing here. 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 whether your data trains the model. It does not govern whether your code leaves the machine. Those are two different controls, and only one of them was exposed to the user. Every cloud coding agent has to send some source to a remote model to do its job, so the first channel is expected. Sending the entire tracked repository and its history is a wider boundary than sending the files a task needs. A repo can hold proprietary code, internal URLs, customer data, and credentials that were removed from the working tree but still sit in commit history. In cereblab's own cross-tool comparison, Claude Code and Codex sent no repository bundle; Gemini sent none in an idle test, though its realistic-task run was quota-blocked before it finished. Grok Build was the outlier. Those are still cloud tools that send the files they open, so "local only" is the wrong mental model for any of them. But wholesale collection of the workspace was specific to Grok Build. xAI's response On July 13 the same 0.2.93 binary stopped making storage requests. cereblab retested six times and saw zero /v1/storage uploads, and the server now returned disable_codebase_upload: true and trace_upload_enabled: false. The developer Peter Dedene reported the same flag returned for his account, so the shutoff was not only cereblab's single-machine observation. The tested client stayed on 0.2.93 while its server settings changed, so this was a server-side switch, not a fix shipped in an update. xAI has not confirmed whether it reaches every account or is permanent. xAI has so far addressed the issue on X rather than through a security advisory or changelog note. The @SpaceXAI account said enterprise teams on zero data retention never have code or trace data stored, that API-key use respects ZDR, and that consumers who have not enabled it can run /privacy in the CLI to disable retention and delete previously synced data. Elon Musk went further, saying all user data uploaded before now would be "completely and utterly deleted," with nothing left behind. ZDR covers enterprise teams and API use, so for individual subscribers the /privacy command is the control on offer. For anyone who already ran the tool, the move is not to wait on xAI. Rotate any credential Grok could have sent: anything it read, anything in a tracked file, and anything in the git history the bundle carried, including a secret you committed and later deleted. A file that was gitignored and never committed stayed out of the bundle. A committed one rode along in the history, and deleting it later does not pull it back. A separate analysis of build 0.2.99 found the upload code still in the binary, held off by the server flag, so xAI can turn it back on without an update. And it still has not said why full repositories were uploaded by default, how long they were kept, or how many users were affected. A training opt-out is not a promise that your code stays put, and what leaves the machine is worth checking yourself. Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post. SHARE     Tweet Share Share Share SHARE  artificial intelligence, Cloud security, Credential Security, cybersecurity, Data Exposure, data privacy, Developer Security, enterprise security, Software Security, Source Code Security ⚡ Top Stories This Week 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host on Intel and AMD x86 Systems BeyondTrust Patches Critical Auth Bypass Flaws in Remote Support and PRA Court Filing Reveals Windows Device ID Helped FBI Trace Alleged Scattered Spider Hacker Rogue Agent Flaw Could Have Let Attackers Hijack Google Dialogflow CX Chatbots RedWing MaaS Packages Android Bank Fraud as a Telegram Rental Service 15-Year-Old GhostLock Flaw Enables Root and Container Escape on Most Linux Distros GitHub Copilot Refuses Harmful Requests in Chat, Then Writes Them in Code New HalluSquatting Attack Could Trick AI Coding Assistants Into Installing Botnet Malware GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It Meta's New AI Image Tool Lets Others Use Your Public Instagram Photos in AI Images ThreatsDay: Cloud Bucket Hijacking, Windows LPE Chain, Global Fraud Bust + 17 More Stories Dormant GitHub Accounts Help Attackers Blend In While Mapping Corporate Orgs Attackers Exploit 'Ill Bloom' Vulnerability to Drain Over $5 Million From Cryptocurrency Wallets Unpatched XRING Flaw in XQUIC Lets Remote Clients Crash HTTP/3 Servers Researcher Details WhatsApp-to-Host Attack Chain Using Three OpenClaw Flaws New TrojPix Attack Leaks Data From Air-Gapped Systems via Video Cable Emissions Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices New "Bad Epoll" Linux Kernel Flaw Lets Unprivileged Users Gain Root, Hits Android Google Disrupts NetNut Residential Proxy Network Spanning 2 Million Home Devices European Parliament Member Investigating Spyware Was Hacked With Pegasus ⭐ Featured Resources What 200+ Security Teams Reveal About Using IP Intelligence in 2026 Get Hands-On SANS Training for Today’s Cyber Defense and Offensive Security Challenges See What’s Really Exposed Across Your IT, OT, IoT, Cloud, and Mobile Assets Get Gartner’s Guide to AI Agent Supervision and Runtime Controls

Entities