Mitmproxy capture shows Grok Build's CLI uploading a repo's git history to xAI despite a no-read prompt
Researcher cereblab's mitmproxy capture shows xAI's Grok Build CLI 0.2.93 sending about 5.10 GiB to storage and 192 KB to the model. The prompt said not to read files, so teams should audit what their agent CLIs transmit.
The Engineer · Build desk
Key figures from cereblab's second run: about 5.10 GiB went to the storage channel before the capture was stopped mid-stream, against about 192 KB sent to the model. The repo held about 12 GB of random files the agent never read.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Sent to the storage channel, second run, about | 5.1 GiB | capture stopped mid-stream | 2 |
| Sent to the model, about | 192 KB | 1 | |
| Unread repo, about | 12 GB | 1 |
What happened
- In the first test the CLI posted a git bundle of a 4-commit, 47-file repo, and cloning the capture returned the planted file the agent was told not to open.
- With "Improve the model" turned off, the upload still got a 200, and the server's settings response still read trace_upload_enabled: true.
- On a real task, fake canary values from a git-tracked .env went into a model turn verbatim and into a session_state archive bound for storage, per The Hacker News.
- On July 13, 2026, xAI turned the upload off using a server-side flag.
- xAI published the Grok Build source on July 15 under Apache 2.0 for first-party code, and the upload path is still in it behind a hard-coded error.
Why it matters
- What it limits constraint A deny rule on Read(secret.txt) stopped the agent reading the file, yet the tracked file was still in the uploaded bundle.
- Who's exposed exposure The same 0.2.93 binary stopped uploading, with no new release, once the server changed its settings response, and a later change to that response could make a clean test go stale or flip back.
- What doesn't add up contradiction xAI points consumers to /privacy, but cereblab found it controls retention and not what the CLI sends.
- Who has to decide decision A proxy, a canary repo with a planted file and a short mitmproxy addon are enough to test any agent CLI, so the check is cheap to run on each tool a team adopts.
One binary opened two channels. Model turns were sent to cli-chat-proxy.grok.com/v1/responses [6]. Storage traffic used /v1/storage, on that same host, with a multipart init and a batch_exists check [6]. A log that watched only the responses path would have seen 192 KB and filed the session as quiet [1][6].
Treat the 5.10 GiB as a claim about one workload. The repo was about 12 GB of random files the agent never read [1]. The capture was stopped mid-stream after 73 chunks of roughly 75 MB, each answered with HTTP 200 [2]. So the figure is a floor. Against the 192 KB sent to the model, it is roughly 28,000 to 1 [20]. The ratio applies only to a repo of similar size, and the prompt still did not stop the upload [3][4].
The researcher states the limits. The capture proves transmission, acceptance and storage, but it is not evidence that xAI trained on anything [9]. The 12 GB run demonstrates a multi-gigabyte upload without failures, though not a completed transfer, and it is the only run whose log was kept [9]. All testing was pinned to version 0.2.93, and each secret was a fake canary string [9]. The account is one researcher's capture, relayed by a dev.to post that draws on cereblab's write-up and on The Hacker News [19].
xAI answered on X. According to The Hacker News, it said teams on enterprise zero-data-retention never had their code or trace data stored, and that consumers can turn off retention and delete synced data by running /privacy in the CLI [12]. cereblab's test used a consumer SuperGrok/X login on macOS, so the enterprise statement covers a different account type [5]. Elon Musk said previously uploaded data would be "completely and utterly deleted." [13]
The Hacker News also reported that xAI had not stated whether the change applies to all accounts or is permanent, how long it retained uploads, or how many users it affected [16].
The method needs little. cereblab trusted the mitmproxy certificate and pointed HTTPS_PROXY and SSL_CERT_FILE at the proxy [5]. It worked because Grok did not pin its certificates, so every request was readable [5]. The flags that changed sat in the /v1/settings response [7][11], and we'd diff that response between runs.
What to watch
- Whether xAI says if the July 13 change covers every account and is permanent, how long uploads were kept, and how many users were affected.
- Whether the upload code left in the published Grok Build source is removed instead of returning a hard-coded error.
- Whether a second researcher's capture of a later Grok Build release shows the server flags holding.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence68
- Adoption
- Insufficient
- Hype gap−10
- Incentives
- Insufficient
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
In a second run, on a repo of about 12 GB of random files the agent never read, about 192 KB went to the model.
- [2]
In that second run about 5.10 GiB went to the storage channel, in 73 chunks of roughly 75 MB, every one answered with HTTP 200, before the capture was stopped mid-stream.
- [3]
The researcher who publishes as cereblab sent Grok Build CLI 0.2.93, xAI's terminal coding agent, the prompt "Reply with exactly: OK. Do not read or open any files." with mitmproxy sitting in the middle, and the model answered.
- [4]
In the background the CLI also posted a git bundle of the repository to xAI's storage endpoint: 4 commits, 47 files, full history. Cloning the captured bundle returned a planted file the agent had been told not to open, marker string intact.
- [5]
cereblab used a consumer SuperGrok/X login on macOS, trusted the mitmproxy certificate, and pointed HTTPS_PROXY and SSL_CERT_FILE at the proxy. Grok did not pin its certificates, so every request was readable.
- [6]
Model turns went to cli-chat-proxy.grok.com/v1/responses. Storage went to /v1/storage on the same host, plus a multipart init and a batch_exists check.
- [7]
With "Improve the model" turned off, the git-bundle upload still went through with a 200, and the server's /v1/settings response still carried "trace_upload_enabled": true. cereblab's reading is that the setting governs training, not upload.
- [8]
On a real task where the agent did read files, a git-tracked .env holding fake canary values went into a model turn verbatim, and the same values also landed in a session_state archive bound for storage.
- [9]
The capture proves transmission, acceptance and storage. It does not prove xAI trained on anything. The 12 GB run shows multi-gigabyte upload with no failures, not a finished transfer, and only that run's log was kept. Everything was pinned to version 0.2.93, and every secret was a fake canary string.
- [10]
xAI switched the upload off on July 13, 2026 with a server-side flag.
- [11]
The same 0.2.93 binary stopped making storage requests on July 13. cereblab retested six times and saw zero /v1/storage uploads; the server now returned disable_codebase_upload: true and trace_upload_enabled: false.
- [12]
Per The Hacker News, xAI said on X that enterprise zero-data-retention teams never had code or trace data stored, and that consumers can run /privacy in the CLI to turn off retention and delete synced data.
- [13]
Elon Musk said previously uploaded data would be "completely and utterly deleted."
- [14]
cereblab tested /privacy and concluded it controls retention, not what gets sent.
- [15]
On July 15 xAI published the Grok Build source, Apache 2.0 for first-party code. Tech Times reported the Cloud Storage upload code still in the published source, and Simon Willison found remnants of the code: upload_session_state() now returns a hard-coded session_state_upload_unavailable error.
- [16]
As of The Hacker News report, xAI had not said whether the change covers every account or is permanent, how long uploads were kept, or how many users were affected.
- [17]
In cereblab's repro repo, a deny rule like Read(secret.txt) did stop the agent from reading the file, and the tracked file was still in the uploaded bundle.
- [18]
A proxy and a canary repo, plus a short mitmproxy addon, will show what any agent CLI sends, Grok or not.
- [19]
The dev.to account draws on cereblab's write-up and gist and on The Hacker News reporting.
- [20]
About 5.10 GiB sent to storage against about 192 KB sent to the model is roughly 28,000 to 1.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.to'Reply With OK': Grok Build's CLI Still Uploaded the Whole Git History
1 article · October 15, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Network traffic analysisFollow
- AI Coding AgentsFollow
- Data privacyFollow