xAI's Grok Build Shipped Whole Git Repos to a Cloud Bucket, and the Privacy Toggle Didn't Stop It

A researcher publishing as cereblab pointed a packet capture at xAI's Grok Build coding CLI, version 0.2.93, and found that the tool was not doing what a coding agent is supposed to do. It was not sending the files it needed to read. It was sending the repository. All of it. Tracked files, full commit history, packaged as a git bundle and shipped to a Google Cloud Storage bucket run by xAI called grok-code-session-traces.

The byte split is the part that ends the argument. On a 12 GB repository the model never read, traffic to the model endpoint at /v1/responses came to roughly 192 KB. Traffic to /v1/storage came to 5.10 GiB. That is a gap of about 27,800x between what the model actually needed to do the job and what left the developer's machine. The upload ran as 73 chunks of roughly 75 MB each, and every single one came back HTTP 200. Across cereblab's size sweep, the volume tracked total repo size, which is exactly what you would expect if the thing being uploaded is the repo rather than the task.

The canary that was never opened

cereblab planted a file at src/_probe/never_read_canary.txt with a unique marker, and told the agent in plain terms not to open it. Then they intercepted the upload, cloned the git bundle straight out of the captured request, and pulled the canary back verbatim, along with the repository's full commit history. The test replicated on a second, unrelated repo. The destination bucket is named in the binary and again in a staged metadata.json whose per-file paths point at gs://grok-code-session-traces/.

Be precise about what this does and does not prove, because the researcher was. The captures establish transmission, acceptance, and storage. They do not establish training. The teardown makes no claim that xAI trained on the code, that staff read it, or that gitignored files were swept in. Tracked files plus history is what the wire shows. That is enough.

A separate, simpler problem with secrets

The repository bundle is one channel. Secrets took the obvious one. When Grok reads a file, the contents go into the model turn, and a tracked .env went along with canary API_KEY and DB_PASSWORD values fully unredacted. The same content also turned up in a session_state archive bound for storage. The planted values were fake, so nothing real leaked in the test. The behavior is the finding: a credential file the agent touched during a normal task left the machine and was stored with no redaction step anywhere in the path.

Grok Build was the outlier, not the norm

Every cloud coding agent has to send some source to a remote model to function. That channel is expected and nobody should be shocked by it. Sending the entire tracked repository plus its history is a materially wider boundary than sending the files a task needs, and the difference matters because a repo is not just code. It holds proprietary logic, internal URLs, customer data, and credentials that were pulled from the working tree years ago but still sit in commit history, immortal.

cereblab's cross-tool comparison found 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 alone here. That said, all of these are cloud tools that send the files they open, so "local only" remains the wrong mental model for any of them. Wholesale collection of the workspace is what was specific to Grok Build.

xAI's response: a flag, not a fix

On July 13 the same 0.2.93 binary stopped making storage requests. cereblab retested six times and saw zero /v1/storage uploads, with the server now returning disable_codebase_upload: true and trace_upload_enabled: false. Developer Peter Dedene reported the same flag on his own account, so this was not one researcher's machine. The client never changed version. The server did. That is a switch, not a patch.

xAI has addressed this on X rather than through a security advisory or a changelog entry. 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 said all previously uploaded user data would be "completely and utterly deleted," with nothing left behind. Separately, an analysis of build 0.2.99 found the upload code still sitting in the binary, held off only by the server flag.

The RedEye take

The uploads stopping is not the story. The story is that a server-side boolean is the only thing standing between your private repository and an xAI storage bucket, and xAI controls that boolean. The code path is still compiled into 0.2.99. It can come back tomorrow, silently, with no update for you to review, no changelog for you to diff, and no advisory for your vendor risk team to file. "We turned it off" is a configuration state, not a security control.

The deeper failure is one of honest labeling. A user who unchecked "Improve the model" made a deliberate privacy decision and was given a control that answered a question they did not ask. Whether that gap was carelessness or product design, the effect on the developer is the same: they believed they had opted out, and 5.10 GiB left anyway. Trust in AI tooling gets built on the boring accuracy of settings screens, and this one lied by omission.

And the questions that would actually let a CISO close the ticket remain unanswered. xAI has not said why full repositories were uploaded by default, how long they were retained, or how many users were affected. A deletion promise made on X is not a retention record. Until those three numbers exist, treat every repo you ever opened in Grok Build as having been disclosed to a third party, and act accordingly.

What defenders should learn

• Rotate on history, not on what the agent read. The bundle carried full commit history, so a secret you committed in 2023 and deleted in 2024 went out with it. Deleting a file later does not pull it back out of the git objects. Scope your rotation to every credential that ever touched a tracked file in any repo Grok Build opened, not just the ones currently on disk.
• Gitignored and never committed is the one thing that stayed home. That is a real, testable boundary and it should shape policy: if secrets live in files that were never committed, this class of exposure has a floor. Enforce it with pre-commit secret scanning, not with a hope that the agent behaves.
• Audit the network, not the settings page. cereblab found this with a proxy and a canary file, not by reading documentation. Before you approve an AI coding tool for engineering, run it against a repo with a planted never-read marker and watch what leaves. A 27,800x gap between model traffic and storage traffic is not subtle once you look.
• Treat privacy toggles as scoped claims, and demand to know their scope. "Improve the model" governed training, not egress. Ask every AI vendor, in writing, which specific data flows each user-facing control actually stops, and get the answer before procurement, not after a researcher publishes.
• A vendor mitigation delivered by remote flag is not a remediation. Track it as an open finding until the code is removed from the binary and the vendor publishes retention and impact numbers. Enterprise ZDR contracts are the only durable control here; individual subscribers get /privacy and a promise.

Source

Swati Khandelwal, "Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read," The Hacker News, July 14, 2026, reporting on research published by cereblab. https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html