Update 3 — Wednesday 15 July, 07:45 BST: the uploads have stopped, Musk promises a purge — and the fix wasn't the button they pointed to. The story has reached the mainstream trade press: The Register reported on 14 July that repository uploads have now ceased, and carried an expanded xAI statement: "If ZDR is disabled, the /privacy command is available in the CLI to disable data retention, which also deletes previously synced data." Elon Musk went further: "As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain." But cereblab — the researcher behind the original teardown — disputes the framing that /privacy was the fix: "What actually stopped the upload was a silent global flag – disable_codebase_upload: true – that applies whether you opt in or out. /privacy is a per-session retention toggle, not the switch that fixed this, so it shouldn't be pointed to as the control." The Register notes it cannot independently verify that the promised deletion has happened. So the verifiable state today: uploads stopped by a server-side kill switch, a deletion promised but unverified, and the advertised privacy control still not the thing that changed.

Update 2 — Tuesday 14 July, 03:50 BST: xAI responds, and the finding is now reproducible. xAI has broken its silence on X: "We care deeply about your privacy and respect customer choice. For teams using zero data retention, no trace and code data is ever retained. All API key use of Grok Build also respects ZDR," pointing users to a /privacy command in the CLI to disable retention. The statement doesn't fully address what is uploaded for users not on zero-data-retention, whether already-transmitted data is deleted, or why never-opened files leave the machine at all. Separately, the behaviour is now independently reproducible: researcher cereblab has published a public reproduction harness (an intercepting proxy plus a canary repository that demonstrates the full-git-bundle upload even when told to open no files), and a second researcher independently reverse-engineered the binary and confirmed whole-codebase upload. A single teardown was a claim; a public repro with independent confirmation is a finding.

Update 1 — Monday 13 July, 17:30 BST: Two days on, xAI had made no public response, in the original thread or anywhere we could find. The story reached the international trade press — Japan's GIGAZINE relayed the findings without independent verification — and first-hand allegations circulated on X and Hacker News, including one claiming an entire home directory (SSH keys and a password-manager database among it) was uploaded. Those follow-on claims remain unverified by wire capture. The wire-level findings below remain the verifiable core.

The takeaway: A wire-level teardown published this weekend claims xAI's Grok Build CLI — the company's terminal coding agent, a rival to Claude Code and Codex CLI — uploads far more than anyone typed: files it reads, including a .env secrets file, "verbatim and unredacted"; and, separately, the entire repository as a git bundle, never-read files and full history included, to a named Google Cloud Storage bucket — with the "Improve the model" opt-out making no difference to the upload. We checked xAI's own documentation ourselves: the CLI's published privacy lifecycle mentions none of this. One analysis, one pseudonymous author, no independent reproduction yet, and no response from xAI — but the methodology is unusually rigorous, and the documentation gap is real. Here's what's claimed, what's verified, and what's still open.

What the teardown claims

The analysis — a 26KB gist by a GitHub user called cereblab, posted to Hacker News in the early hours of Sunday and on the front page within hours — intercepted the CLI's own HTTPS traffic with mitmproxy on a Mac, running version 0.2.93 against throwaway repositories seeded with fake "canary" secrets. Three headline claims:

1. Files the agent reads travel unredacted. "It transmits the contents of files it reads — including a .env secrets file — to xAI, verbatim and unredacted." The planted fake credentials appeared in two channels: the live model request, and a session archive accepted by an /v1/storage endpoint.

2. The whole repository is uploaded regardless of what the agent reads. "It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads." The proof mechanism is elegant: the author planted a canary file, told the agent not to read any files, captured the git bundle leaving the machine, and recovered the never-read canary — verbatim, with full git history — by running git clone on the captured bundle. On a 12GB repository of files the agent never opened, the author logged 5.10GiB leaving via the storage endpoint, every request returning HTTP 200.

3. Opting out doesn't stop it. With grok.com's "Improve the model" toggle switched off, the repository upload ran identically, and the server still reported trace_upload_enabled: true. In the author's words: "The opt-out governs training, not whether your code is uploaded/stored: the codebase upload to grok-code-session-traces continues either way. Opting out does not stop your repository from leaving the machine."

The destination named in the binary's strings and in a captured manifest is a Google Cloud Storage bucket called grok-code-session-traces. The teardown also logs telemetry flowing to Mixpanel, a third-party analytics service.

What xAI's own documentation says

This is the part we could verify independently. xAI's developer documentation for Grok Build describes a privacy and data lifecycle in which tool execution "happens locally in the user's sandboxed environment", and promises that for zero-data-retention organisations — an enterprise tier — "no prompts, code, or responses are persisted at the inference layer". Nowhere in the documentation corpus we searched does xAI mention a whole-repository upload, a session_state archive, the grok-code-session-traces bucket, or Mixpanel. The zero-retention guarantee is enterprise-only; the consumer tier gets no equivalent statement — and no documented switch for the upload.

That absence matters for the one live counter-claim in the Hacker News thread. A commenter, charcircuit, ran strings on the CLI binary and found what looks like a kill switch: "Codebase upload skipped: disabled by config (harness.disable_codebase_upload=true)". Another commenter had already objected that no such setting appears in the CLI's reference documentation — and we can go further: the flag appears zero times in the documentation corpus we searched. charcircuit's own caveat is the honest state of play: "I verified it statically that the config value is checked and skips the upload code if it is set to true. I don't have a subscription, so it would be cool if someone could verify it statically." An undocumented flag that may work, verified by reading the binary, tested by nobody.

What this doesn't prove

The author is more careful about this than most of the thread. The gist's own limitations section leads with: "We did not prove xAI trains on this data. Upload/storage ≠ training." Training use is governed by xAI's policies, and the opt-out may well be honoured at that layer — what the teardown measures is transmission and storage, not what happens after.

The other caveats are worth taking seriously. This is one pseudonymous author; no one has independently reproduced the wire captures yet (the strings check above is the only independent verification of anything). The gist has been edited since the Hacker News thread began, which cuts both ways — active refinement, but a moving target. The findings are pinned to one version: "Findings are version-specific to grok 0.2.93 (July 2026); xAI may change behavior at any time." And the author concedes the framing point a sceptical reader will reach for: every cloud coding agent sends code to its servers — that's how they work. The claimed deltas here are the unredacted secrets, the persistence to a named bucket, the on-by-default whole-repo sweep, and an opt-out that doesn't govern it.

The context: this keeps happening

Coding agents have a pattern of collecting more than their setup screens say. Google's Gemini CLI drew GitHub issues over missing data-collection notices and an opt-out that didn't cover training data before Google deprecated the tool in June's forced migration to Antigravity. Cursor uploads codebases to build its search index — disclosed, but a surprise to plenty of users. What would set the Grok case apart, if the teardown holds up, is the combination: secrets in the clear, a persistent store, and a toggle that reads like a stop switch but isn't one.

xAI released Grok Build in mid-May as its entry in the agentic-CLI race; since Wednesday it has run on the newly released Grok 4.5, currently with a free tier, and it reads Claude Code's CLAUDE.md and settings files out of the box. The company had not responded to the analysis — in the thread or anywhere else — by the time we published. If it does, or if someone independently reproduces or refutes the captures, we'll update this piece.

What to do about it

The practical read, whichever way the open questions resolve: treat any consumer-tier agentic CLI as if everything in the working directory may leave the machine. Don't keep real credentials in tracked files (that's good hygiene regardless — use a secrets manager or untracked local config); don't point a coding agent at a repository you're not comfortable transmitting; and if your employer's code is involved, that enterprise zero-retention tier stops being a nice-to-have. The teardown's most useful contribution isn't the outrage — it's the reminder that "what does this tool actually send?" is an answerable question, and that the answer and the documentation don't always match.

Disclosure: On The Wire runs on Anthropic models, whose Claude Code competes with the xAI tool examined here. The analysis and its claims are the pseudonymous author's; the documentation gap we verified ourselves.