Grok Build Uploaded Your Entire Repo — Rotate Credentials Now

On July 12, security researcher cereblab published wire-level captures proving that Grok Build CLI v0.2.93 was silently uploading entire Git repositories — full commit history, unredacted .env secrets, SSH keys — to a Google Cloud Storage bucket called grok-code-session-traces. For a 12 GB repo, the tool transmitted 5.10 GiB of data via a parallel upload channel while the actual model-turn traffic was 192 KB. The upload ran regardless of which files the agent opened, regardless of whether “Improve the Model” was toggled off, and regardless of the in-app privacy setting. xAI stopped it not with a code fix but by flipping a server-side flag — meaning the exfiltration code is still present in every binary, including the Apache 2.0 open-source release published July 15.

TL;DR

• What: Grok Build v0.2.93 silently uploaded complete Git repos (5.10 GiB per 12 GB test repo) to xAI’s cloud — 27,800x more data than the coding task required
• Privacy toggle: Disabling “Improve the Model” did nothing; uploads continued until xAI flipped a server-side flag on July 13
• Still live: The upload code remains present in the open-sourced binary; only the server flag prevents it from running again
• Action: Rotate every credential that ever touched a repo Grok Build accessed — Git history travels with the bundle

What Happened

The numbers tell the story more clearly than any narrative. Cereblab ran Grok Build on a 12 GB test repository and captured the network traffic on two separate channels. The model-turn channel — the one that actually handles the coding conversation — transmitted roughly 192 KB. The storage channel uploaded 5.10 GiB across 73 chunks of approximately 75 MB each, sending everything to gs://grok-code-session-traces/. That is a ratio of roughly 27,800

between data collected and data needed for the task.

The upload was not selective. It did not mirror which files the agent opened during the session. It bundled the entire repository including full Git history — which means every secret you ever committed and then deleted was transmitted. Your .gitignore does not matter here. Your working-tree deletions do not matter. If the credential was ever in a commit, it went to xAI’s bucket.

Git history travels with the bundle. A database password you committed in January and removed in February was still in the uploaded data. .gitignore and working-tree deletions do not sanitize what is already in history.

The most damning detail: disabling “Improve the Model” in the UI and running the /privacy command had zero effect. Cereblab confirmed that even after toggling the setting, Grok Build’s /v1/settings endpoint continued returning trace_upload_enabled: true, and the repository upload continued without interruption. The privacy controls that users relied on were cosmetic.

Why This Matters

I have been watching AI coding tools accumulate data-handling debt since the early proxy supply-chain scares, but this incident is structurally different from anything we have covered before. Three things make it worse than a standard telemetry over-collection bug.

First, the fix is unverifiable. xAI stopped the uploads on July 13 by setting a server-side flag (disable_codebase_upload: true) that the Grok Build binary checks at runtime. They did not ship a patched version. They did not remove the upload code. Cereblab retested the same v0.2.93 binary six times after the flag was set and observed zero storage uploads — confirming the flag works. But the same binary can behave differently on different days depending on what the server tells it. You cannot verify the fix by checking a version number, and you cannot audit what the server will decide tomorrow.

Second, the open-source release does not change this. On July 15, xAI published 844,530 lines of Rust under Apache 2.0. Security researchers immediately confirmed that the upload logic is present and active in the published source, held off only by that same server-side flag. Open-sourcing the code is a useful step for future auditability, but it does not undo what was already collected, and it does not prevent the flag from being flipped back.

Third, this is not an industry-wide pattern — though that claim deserves a caveat. Cereblab tested Claude Code, Codex CLI, and Gemini under equivalent conditions. All three sent only the files the agent actually opened during the coding task. None transmitted a whole-repository Git bundle. That said, cereblab’s detailed test parameters are not fully documented, so the comparison is indicative rather than rigorously auditable. The reproduction harness is public if you want to run the checks yourself. Even with that caveat, wholesale repository bundling is clearly specific to Grok Build’s architecture — none of the other tools came remotely close to a 27,800

data ratio.

If your organization uses any AI coding agent, run a network capture during a session. Compare the volume of model-turn traffic against total outbound data. The delta tells you exactly how much telemetry you are generating beyond the task itself.

The incident response from xAI has been notably inadequate. As of July 16, there is no count of affected users, no total volume of data collected since Grok Build entered beta in May 2026, no mechanism for individual developers to verify whether their specific data was transmitted or deleted, and no third-party attestation of deletion. Elon Musk posted on July 13 that “all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted.” That pledge arrived via X post, not a formal security advisory. There is no audit trail. There is no evidence the deletion happened. There is a promise from a social media account.

On timeline: Grok Build’s early beta launched May 14, 2026 for SuperGrok Heavy subscribers only, then expanded to all SuperGrok and X Premium+ users on May 25. If you had access to either phase and ran the tool on a real codebase before July 13, assume your repository contents were uploaded.

Compare this to how a serious security incident gets handled: CVE assignment, affected version enumeration, a signed advisory with SHA hashes, a remediation timeline, and independent verification. xAI provided none of these.

The Take

This is not a privacy policy disagreement or a Terms of Service gotcha. This is a confirmed credential-exposure event for every team that ran Grok Build between its May 14 early beta and July 13 on a real codebase. Treat it accordingly.

The immediate action is not optional: rotate every API key, database password, cloud token, SSH key, and webhook secret present in any repository Grok Build accessed. That includes secrets you committed and later removed — Git history is not your friend here. If you are not sure whether Grok Build touched a particular repo, check your shell history for grok commands and your network logs for connections to GCS endpoints.

The broader lesson is harder to swallow. We gave a coding agent full filesystem access to production repositories, and the only thing between our secrets and someone else’s cloud bucket was a privacy toggle that did not work. The open-source release helps going forward — you can now grep for upload logic before running the tool. But the asymmetry remains: the tool vendor decides at runtime what data to collect, and you find out weeks later from a security researcher, not from the vendor.

I will keep recommending AI coding agents — the productivity gains are real and measurable. But after this incident, “what does this tool upload?” is not an optional procurement question. It is the first one. And “we have a privacy toggle” is no longer an acceptable answer.

xAI has provided no individual verification mechanism. You cannot confirm whether your specific data was collected or deleted. Assume it was collected and act on that assumption.