Image: Pexels, used under the Pexels License.
In July 2026, xAI's Grok Build coding CLI packaged whole git repositories, including files the agent was told not to open and the full commit history, and uploaded them to a Google Cloud Storage bucket. A researcher caught it on the wire, xAI switched the upload off by July 13, and Elon Musk promised the data would be deleted. If your developers ran it before then, the question isn't whether to trust the fix. It's which secrets in those repos you still haven't rotated.
What the researcher found
The analysis comes from @cereblab, an independent researcher who published it as a GitHub Gist that GitHub dates July 10, 2026, with a reproduction kit the next day. The binary was grok 0.2.93 (build f00f96316d4b) on macOS Apple Silicon, logged in with a consumer account. Every capture was the researcher's own traffic, routed through mitmproxy, with fake "canary" secrets planted in the test repos. No real credentials were exposed.
Screenshot: cereblab, "What xAI's Grok Build CLI Actually Sends to xAI", GitHub Gist, captured October 15, 2026.
A .env file went out unredacted, twice. With API_KEY=CANARY7F3A9-SECRET-should-not-leave in a .env, the value showed up in the model request to cli-chat-proxy.grok.com/v1/responses and again inside a session_state archive sent to /v1/storage. Sending files the agent reads to the model is how cloud coding agents work. Writing them, secrets and all, into a stored archive is the part that matters for you.
The whole repo went too, read or not. The researcher told the agent: "Reply with exactly: OK. Do not read or open any files." It replied OK. Meanwhile /v1/storage accepted a 152 KB git bundle, and running git clone on the captured bytes rebuilt the repository, including a file the agent was told not to open, with its marker intact. The researcher's site lists the recovered bundle as 47 files and 4 commits with full history, and says secrets deleted from the repo months earlier were still inside it. A second, unrelated codebase gave the same result.
Size didn't stop it. On a 12 GB repo of random files the agent never read, the model channel moved about 192 KB while the storage channel moved 5.10 GiB in 73 chunks of roughly 75 MB, every one accepted, before the researcher stopped the capture. The researcher puts the ratio at about 27,800 to one: whatever the model needed, the upload took everything.
The opt-out didn't change it. With "Improve the model" turned off, the bundle still uploaded, and the server's /v1/settings reply still read "trace_upload_enabled": true.
The destination was named in the binary and in a staged manifest: a Google Cloud Storage bucket called grok-code-session-traces. Sessions also sent events to Mixpanel.
Screenshot: cereblab.com, Grok Build report, captured October 15, 2026. The Claude Code, Codex and Gemini rows are the researcher's own comparison.
What it didn't prove
The researcher is careful about scope, and so are we.
- Upload isn't training. The capture shows data leaving the machine and being accepted. It doesn't show what xAI did with it.
- "Not documented" is narrow. The researcher checked the CLI's install script and quickstart, not every xAI policy page.
- No real secrets were taken. The test used canary values. It shows the mechanism, not that anyone's real credentials were misused.
Other users did report real exposure. The Register reported one user "whose entire user directory, containing SSH keys, password manager databases, and more, was opened and uploaded."
How xAI responded
July 13. The researcher saw the server start returning disable_codebase_upload: true, and the upload stopped. Musk replied on X the same day:
https://x.com/elonmusk/status/2076739687658496209
xAI's account also posted that teams using zero data retention (ZDR) never had trace or code data retained, and pointed everyone else to a new /privacy command. IBTimes UK, covering the story that night, noted that ZDR is only available to enterprise accounts according to xAI's documentation.
The researcher tested /privacy on the wire and found it changes what xAI keeps, not what's sent: opted in or out, the same requests leave the machine. In the researcher's words, quoted by The Register: "What actually stopped the upload was a silent global flag... that applies whether you opt in or out."
July 14 and 15. xAI made the Grok Build source public on GitHub (the repository was created July 14) and announced it on July 15.
Screenshot: "Grok Build is Now Open Source", xAI, July 15, 2026, captured October 15, 2026.
In a statement with the release, quoted by The Register, xAI said that "in the early beta, data retention was enabled by default for non-ZDR users," that it "disabled default retention for all Grok Build users starting on July 12th," and that it was "deleting all coding data that was previously retained." The Register noted the public repo is a single commit, so you can't see how the code changed over time.
July 22. The researcher retested on version 0.2.106 and found the upload still off.
The Register said it couldn't independently verify the deletion. xAI hasn't published an advisory saying what was retained or for how many users.
What to do if your team used it
- Find out who installed Grok Build before mid-July 2026, and on which repos. If you can't tell which repos, use every repo those developers could reach.
- Rotate every secret that was ever committed to those repos, not just what's in the current tree. The bundle carried full history, so a key you removed last year still counts.
- Rotate anything in a
.envor similar file the agent may have opened, even if it was never committed. Opened files went out in the model request. - Check where it was run from. If someone ran it from a home directory rather than a project folder, treat their SSH keys and local credential stores as exposed too.
- Put AI coding agents on your approved-tools list before anyone installs them. Our AI coding tools policy has a section you can paste.
Our take
The fix is real, but it's a server-side flag xAI controls, and the public source doesn't prove what runs on its servers. For a regulated codebase, we'd hold off on reinstalling until xAI documents in writing what the CLI uploads and how long it's kept, or until you can run it with ZDR on an enterprise contract. For everyone else, the useful lesson is about vendor review: none of this was visible in the install docs. It showed up only when someone watched the traffic. If an AI coding agent will sit inside your source tree, a short proxied test run on a canary repo is a cheap addition to your vendor due diligence.
Correction, October 15, 2026: an earlier version said the git bundle captured a .env file even when the agent didn't open it; the bundle carried tracked (committed) files and history, so an uncommitted .env went out only if the agent opened it. It said files outside the git working directory weren't uploaded; The Register reported a user whose whole home directory was uploaded. It said /privacy doesn't delete data already sent; xAI says it also deletes previously synced data, though that's unverified. It dated the open-source release July 14; the repo was created July 14 and xAI announced it July 15. We also replaced a dead IBTimes UK link and removed an unsourced claim about xAI's enterprise data processing terms.
Related Reading
- Grok Build: 5 questions before your devs install it
- AI coding tools policy: GitHub Copilot, Cursor, Claude Code
- AI vendor due diligence checklist
- AI agent API token leak: incident response
- MCP server security governance checklist
Sources: cereblab, Grok Build wire analysis (GitHub Gist), cereblab.com, IBTimes UK, July 13, 2026, The Register, July 14, 2026, The Register, July 16, 2026, xAI, "Grok Build is Now Open Source".
