Grok Build’s disable_codebase_upload Fix, Explained

Grok Build stopped uploading entire repositories to xAI’s cloud storage on July 13 — not because a privacy toggle was flipped, but because xAI set a server-side flag, disable_codebase_upload, to true, independent of any user setting.

Quick take

Grok Build 0.2.93 sent full Git-bundled repositories to a Google Cloud Storage bucket regardless of what the agent was told to read.

The user-facing “Improve the model” toggle and the /privacy command did not stop this; only a server-side flag, disable_codebase_upload, did.

That flag is not documented in xAI’s public settings reference as of July 21, 2026.

Enterprise buyers on zero data retention should still request written, session-level deletion confirmation rather than relying on public statements.

What disable_codebase_upload Actually Controls

The setting most developers reached for, Improve the model, only ever governed whether data trains xAI’s models. With it disabled, the server’s /v1/settings response still returned trace_upload_enabled: true, and the repository upload proceeded exactly as before.

Cereblab, the researcher who ran the test, was explicit that /privacy is a per-session retention toggle, not the switch that fixed the upload, and that it should not be pointed to as the control that stopped it.

xAI’s own settings documentation, last updated July 21, 2026, describes the config.toml scopes for models, MCP servers, and permissions but does not list disable_codebase_upload or trace_upload_enabled among its keys.

That gap matters for procurement review: the flag that actually stopped the exfiltration is not something a security team can currently confirm or pin through the documented settings reference alone.

The Wire Evidence Behind the Finding

The underlying test routed Grok Build CLI version 0.2.93 through the mitmproxy interception proxy on macOS and published the full network captures as a public GitHub Gist, a method that required no jailbreak or elevated access.

On a 12 GB test repository, the live model-turn channel, POST /v1/responses, moved about 192 KB — the files the agent actually needed. A parallel channel to POST /v1/storage moved 5.10 GiB across 73 chunks, each returning HTTP 200.

That gap works out to roughly 27,800 times more data moving through the storage channel than the model-turn channel needed, a ratio independent of which files the agent opened or was told to read.

To prove the upload wasn’t scoped to what the agent touched, the researcher planted a file, src/_probe/never_read_canary.txt, that Grok Build was explicitly told not to open, then recovered it intact after cloning the captured Git bundle.

A tracked .env file containing a canary credential, API_KEY=CANARY7F3A9-SECRET-should-not-leave, appeared unredacted both in the model-turn traffic and in a session_state archive routed to the storage bucket.

The destination was a Google Cloud Storage bucket named grok-code-session-traces, reached through paths such as gs://grok-code-session-traces/repo_changes_dedup/v2/, a bucket not mentioned in Grok Build’s onboarding or quickstart materials at the time.

The comparison that raises the stakes for buyers is cross-tool: in cereblab’s own test, Claude Code and Codex sent no repository bundle at all, and Gemini sent none in an idle test, though its realistic-task run was quota-blocked before finishing.

What xAI’s Public Response Leaves Unverified

xAI addressed the finding on X rather than through a security advisory or changelog entry, and no advisory had been issued as of the reporting window covered here.

The company’s public statement said enterprise customers on zero data retention never have code or trace data stored, that API-key use respects ZDR, and that consumers without ZDR enabled can run /privacy in the CLI to disable retention and delete previously synced data.

Elon Musk separately committed that all data uploaded to xAI before the fix would be deleted, while in a different post asking users to keep sharing data anyway because retaining some data helps with debugging — two statements that pull in opposite directions on retention.

The Register noted it could not independently verify whether xAI has deleted the data as promised, and the researcher who found the bug called the /privacy command an inadequate reference point for what fixed the underlying issue.

Checklist Before Trusting the Fix

Teams that ran Grok Build 0.2.93 against private repositories should treat the exercise as a credential and secret-exposure review, not a one-line settings change: rotate any credential that existed in tracked files or Git history during that window, then confirm the rotation.

A clean current branch is not sufficient, because the captured upload carried full commit history, including secrets that had already been deleted from the working tree before the session.

Run grok inspect to confirm which config scopes and settings a given install actually picked up, since environment, user, project, and managed configs can each override the others in Grok Build’s merge order.

Before renewing or expanding a Grok Build deployment, request written, session-scoped confirmation of deletion from xAI rather than relying on the public X statements, and separately confirm whether zero data retention was active for the accounts in question during the exposure window.