Grok Build CLI Uploaded Your Entire Git Repo to xAI

A security researcher running under the handle cereblab published wire-level proof on July 10, 2026 that xAI's Grok Build CLI version 0.2.93 uploaded entire Git repositories to a Google Cloud Storage bucket named grok-code-session-traces, independent of which files the agent ever read. The opt-out setting did not stop it. The upload mechanism was not described in the CLI's install or quickstart materials. xAI disabled uploads via a hidden server-side flag after publication, without issuing an advisory or answering what happened to code already transmitted.

What the Wire Capture Proved#

The method is reproducible. Cereblab routed Grok Build through mitmproxy, trusted the proxy's CA in the macOS login keychain, and logged every outbound request. Grok Build does not certificate-pin against mitmproxy's CA.

Two distinct channels carried data outbound. Channel A , POST /v1/responses , carries file contents the agent reads during a session, including .env secrets verbatim. Channel B , POST /v1/storage , is a separate pipeline that packages the entire workspace as a git bundle and POSTs it to grok-code-session-traces, regardless of what the agent touched.

The volume split is the load-bearing number. On a 12 GB repo containing files the agent never read, Channel A moved 192 KB across 5 requests. Channel B moved 5.10 GiB in 73 chunks of approximately 75 MB each, every one returning HTTP 200. That is a ~27,800x ratio. The model demonstrably never ingested those files. The bytes left anyway.

For the definitive content proof, cereblab ran on a real codebase with the explicit prompt "Reply with exactly: OK. Do not read or open any files." Grok uploaded the repository as a git bundle via POST /v1/storage → 200. Cloning the captured bundle recovered src/_probe/never_read_canary.txt , a file the agent was told not to open , with its planted marker verbatim, plus 4 commits of full git history. The result replicated on a second unrelated codebase (cereblab_auth, a Cloudflare Worker repo), same result.

The Opt-Out That Wasn't#

xAI's privacy settings present two distinct controls that engineers need to understand precisely.

The /privacy command inside the CLI sets codingDataRetentionOptOut , a flag that governs training and model improvement. The disable_codebase_upload flag in ~/.grok/config.toml governs whether the repository actually leaves the machine. These are different controls with different scopes.

Cereblab tested this directly. With "Improve the model" turned off, Grok's server returned /v1/settings with trace_upload_enabled: true, upload_enabled: true, and session_registry_enabled: true. The opt-out governs retention, not transmission. Independently confirmed by commenter @wetlink on a second machine (grok 0.2.93, identical SHA-256 2a97ba…d767c, macOS arm64), who found 339 repo_state.upload.enqueued events across four repos before any mitigation , including one session where repo_path was the user's entire home directory.

The /privacy command is a data-retention setting. It is not a block on egress.

Config Switches That Actually Work#

The community documented which levers hold under adversarial conditions. Precedence runs env > config > remote.

For the whole-repo channel, [harness] disable_codebase_upload = true in ~/.grok/config.toml is a hard veto. It held in testing even when uploads were force-enabled via environment variable, producing repo_state.upload.skip with zero enqueues.

For the session-trace channel (the one carrying read file contents including .env values), set both GROK_TELEMETRY_TRACE_UPLOAD=false and GROK_TELEMETRY_ENABLED=false as environment variables for shell-wrapper invocations. In a clean environment, [features] telemetry = false plus [telemetry] trace_upload = false in config also work , the initial report that these TOML keys were silently ignored was a testing error caused by environment variables taking precedence. Both layers should be applied.

Note: auto_update = true is the default. Any update can change behavior. The community-maintained hardening repo at github.com/wetlink/grok-build-privacy-hardening ships a verify.sh canary that re-runs after each update.

What xAI Has and Has Not Said#

After publication, xAI disabled the upload server-side via disable_codebase_upload: true , a flag change with no corresponding advisory, changelog entry, or public statement explaining scope or timeline. Elon Musk publicly committed to deleting previously-uploaded data; as of July 14, 2026, that deletion is not yet confirmed complete.

xAI's public response pointed to Zero Data Retention (ZDR) as the privacy guarantee. ZDR is only available to enterprise accounts. Consumer and most business accounts had no equivalent protection during the period the uploads were active.

The company said it "cares deeply about your privacy." It has not answered what code was collected, from which accounts, across which date range.

Why This Is a Procurement Problem, Not Just a Privacy Story#

This incident belongs to a pattern, not an isolated bug. The question "what does the agent send home?" is now a mandatory procurement line item for any AI coding tool, and the answer cannot be taken from marketing copy or privacy policy summaries. It requires wire-level verification.

The Grok Build finding is specific: a named bucket (grok-code-session-traces), a named mechanism (git bundle via POST /v1/storage), a named version (0.2.93), with reproducible capture commands. That level of specificity is what a security review needs to act on. Most tool evaluations don't reach it.

For engineering teams, the practical implication runs in two directions. First, any tool that runs locally against a repository needs to be treated as a potential egress point until proven otherwise , especially if it authenticates with a consumer account rather than an enterprise ZDR arrangement. Second, the code review and audit layer needs to be architecturally separate from the coding tool itself. If the coding tool is the thing that can't be trusted with the source, the review platform cannot share the same egress path.

Hyrax runs reviews in an isolated worktree, submits the PR, and never auto-merges. The audit runs against the repository; no copy of the repository is retained after the run completes. For teams that need a code governance layer that does not introduce its own data-sovereignty question, that separation is the point.

The broader picture is uncomfortable. Engineers adopt AI coding tools faster than security teams can evaluate them. The evaluation gap is where incidents like this live. A formal question , "show me what this binary sends on the wire" , applied before installation would have surfaced this before any code left anyone's machine.

Hyrax is live at hyrax.dev.