Grok Build Uploaded Whole Repositories: What the Wire Tests Show About AI Coding CLIs

On July 15, xAI, whose own pages now say SpaceXSI, released the source code of its Grok Build terminal agent under Apache 2.0. In a normal week, that would be a story about a new open coding tool.

This was not a normal week for Grok Build. Days earlier, a researcher using a proxy and a canary repository had shown the CLI sending entire git repositories to remote storage, whatever the agent had actually read. Turning off the "Improve the model" setting did not stop it.

The upload has since been switched off. The method used to find it is what every team using an AI coding tool should take away, because it works on any tool.

What the Grok Build wire tests measured

The researcher, who publishes as cereblab, tested version 0.2.93 on macOS with a consumer login, a mitmproxy capture and a repository created for the purpose. The findings, from the published report:

Measurement	Result
What left the machine	Every tracked file plus git history, as a git bundle through `/v1/storage`, regardless of what the agent read
Upload volume on a 12 GB repository	About 5.10 GiB before the capture stopped, against about 192 KB on the model channel
Files the agent did read	Sent unredacted to `/v1/responses`, including a git-tracked `.env`
"Improve the model" switched off	No change. `trace_upload_enabled` stayed true
`/privacy opt-out` on 0.2.99	Tested after the upload was already off. Same traffic: 185,421 bytes against 185,578, with no repository bundle in either run. `/v1/traces` changed from 200 to 204
Documentation	Mechanism not found in install or quickstart materials, in an audit the author says is not exhaustive

The ratio in the second row is what caught my attention. The model channel carried about 192 KB and the storage channel carried over 5 GiB. Whatever that upload was for, the model did not need it to answer the prompt.

The report's own summary is hard to improve on: "Opting out does not stop your repository from leaving the machine."

What is established and what is one person's claim

This story got larger as it spread, so I want to be careful.

Measured by the researcher: whole-repository upload, as described above.
Reported by commenters, not verified: a second machine showing 339 upload events, one with repo_path set to the home directory, and an undocumented configuration key that may stop the upload.
One user's claim: that SSH keys, a password database, documents, photos and videos left their machine. Nobody has shown how a home directory came to be selected.
Not shown: any third-party access. "Data breach" is the wrong term for what is public. The data went to the vendor, as far as anyone can show.
Unproven: that the destination bucket is xAI's. The report shows the bucket name, and Elon Musk's own post describes the data as uploaded to the company.

How xAI responded

Date	Event
July 10	Researcher's report published, revised July 12 and 14
July 12	xAI says default data retention was switched off
July 13	Settings show `trace_upload_enabled: false` and `disable_codebase_upload: true`. Upload stops. Musk promises deletion
July 15	Source released under Apache 2.0, with external pull requests refused and issues off. xAI's post on X addresses retention

Two of those are different changes, and they should not be merged. Retention decides what the vendor keeps. The upload flag decides what leaves your machine.

xAI says on X that users could always disable upload and that this choice was respected. The researcher's tests show "Improve the model" did not stop the upload, and that /privacy opt-out, tested once the upload was already off, changed retention rather than what was sent. Those statements might be reconciled if xAI means the undocumented key, but I cannot confirm that. As of today I have found no security advisory, post-mortem, user count or confirmation that the data was deleted.

The fix itself raises a further question. The change was a server-side flag. The same server could turn it back on. The open source release helps only in part. A leftover upload_session_state function in the published code now returns a hard-coded "unavailable" result, which anyone can check, but that covers the session archive, and the researcher found the repository upload machinery still present in the 0.2.99 binary.

Does your privacy control stop transmission or only retention?

This is the question I would take from this incident.

Most AI tools describe their controls in terms of training and storage: "we will not train on your data", "retention is off". Those are promises about what happens after the data has arrived. For a repository holding client code, secrets or regulated data, the relevant event is the bytes leaving your network. No retention policy changes that.

Read any vendor's settings page with that distinction in mind and you will find many controls describe the second half only.

In my agentic development methodology, the rule is that a person owns direction, AI reviewers own judgment, and the machine and CI own facts. A privacy toggle is a statement of intent. What your tool sends is a fact, and you can measure it.

How to test an AI coding tool yourself

The method here is simple, and I would make it standard for any tool you allow on a work machine:

Create a canary repository with unique strings in files the agent will not be asked to read, and include a fake secret.
Route the tool through a proxy such as mitmproxy on a clean machine or VM.
Ask for a small task that touches one file.
Search the capture for your canary strings. Anything from an unread file is a finding.
Compare bytes sent on each channel with what the task should need.
Switch on every privacy control and run it again. Compare bytes, not just endpoints.
Repeat on every release. A later version may behave differently from the one you approved.

That last step is what most organisations miss. Security reviews approve a product once, while these CLIs update weekly. A canary run in CI, on each new version, would have caught this in hours.

What I would do this week

If you used Grok Build, treat files in any repository it touched as having left your machine, and rotate secrets found in them, especially anything committed by accident.
Keep secrets out of git. A tracked .env was sent straight to the model endpoint here, and that behaviour is normal for any coding agent that reads the file.
Do not run agents from your home directory. Give them a project root, ideally in a container with nothing else mounted.
Add egress monitoring on developer machines where you handle client code. An unexpected 5 GiB upload should raise something.
Ask vendors what the minimum session state is. If they cannot explain why a whole repository must leave the machine, it should not.

Releasing the code was a good step, and I would like to see more vendors do it. It would be better still if we did not need a researcher with a proxy to learn what a developer tool does with our source code. I do not expect Grok Build to be the only CLI with a surprise in its network traffic. Most of them have simply not been tested this carefully.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI-assisted software engineering.