xAI's Grok Build CLI Uploads Git Repositories to a Google Cloud Bucket

The xAI Grok Build CLI — xAI's agentic coding tool built on the Grok model family — was caught silently uploading entire Git repositories, including their full commit histories, to a Google Cloud Storage bucket controlled by xAI. The disclosure was made on July 13, 2026 by a researcher publishing under the handle cereblab, who documented the behavior through intercepted network traffic and released the captures as a public gist alongside a technical breakdown of the findings. The discovery raises serious questions about undisclosed data collection by AI coding agents, and the fix that followed — a hidden server-side configuration flag flipped with no public announcement — may be generating almost as many questions as the original behavior did.

What the Researcher Found: Full Repos, Not Just Context

The Interception Method

The researcher cereblab used mitmproxy on macOS to intercept all network traffic generated by the xAI Grok Build CLI version 0.2.93. What they found went far beyond what any standard AI coding agent needs to function. According to the International Cyber Digest report on the findings, the tool was uploading entire repositories — complete with Git history — to a Google Cloud Storage bucket named grok-code-session-traces.

The bucket name itself is worth pausing on. "Session traces" implies lightweight diagnostic telemetry — log lines, timing data, anonymized usage signals. What cereblab reported was the opposite: a near-complete forensic copy of the developer's repository, transmitted without any disclosure in the tool's setup documentation.

The Traffic Split

The traffic volumes tell the story starkly. On a 12 GB test repository, the channel carrying task-relevant model requests — the data an agent legitimately needs to read code and answer questions — amounted to roughly 192 KB. The upload to Google Cloud Storage, by contrast, was approximately 5.1 gigabytes: on the order of 27,000 times the size of the working context. Critically, the repository upload occurred independently of which files the agent actually opened or read during its coding task — the upload was not scoped to accessed files.

The Canary Credential Test

To make the finding impossible to dismiss as coincidental noise, cereblab planted a canary credential inside a .env file — a test secret with no real access attached, designed purely to track where data travels. That credential appeared verbatim and unredacted in the intercepted traffic destined for the GCS bucket.

.env files are a particularly high-risk vector in this context. Developers routinely add them to .gitignore to prevent secrets from being committed, but in practice those files frequently appear in a repository's earlier history before the ignore rule was added, or as accidental commits that were never truly purged. An upload of the entire Git object store — not just the working tree — means even secrets that a developer believes were removed from the repository may have been transmitted. Any team using Grok Build against a real codebase would, on the basis of these captures, have been handing xAI an undisclosed, full-fidelity copy of their source history, configuration files, and any secrets ever committed to version control.

Whether the grok-code-session-traces bucket was publicly accessible or required authenticated access was not confirmed in cereblab's report — an important open question that xAI has not addressed publicly.

Why it matters for regulated industries: Most enterprise codebases contain API keys, internal architecture details, proprietary algorithms, and data subject to regulatory frameworks — even when developers believe those assets have been cleaned up. An upload of the entire Git object store means nothing is filtered out. For organizations subject to GDPR, HIPAA, SOC 2, or export-control regulations, transmitting unreviewed repository data to a third-party cloud bucket without disclosure creates immediate compliance exposure, regardless of whether the data was subsequently misused.

The "Local-First" Claim and the Broken Opt-Out Toggle

Marketing Language vs. Observed Behavior

The privacy concern is compounded by two specific representations xAI had made about xAI Grok Build. First, the product was marketed as "local-first" — language that, in the developer tooling space, carries a widely understood meaning: your code stays on your machine, and network calls are limited to inference requests. Second, the Grok Build interface ships with an "Improve the model" toggle, which any reasonable developer would interpret as a data-collection opt-out mechanism.

The Toggle That Did Nothing

Cereblab tested this toggle explicitly. Disabling it made no difference to the upload behavior. The server continued returning trace_upload_enabled: true regardless of the toggle's position. The finding crystallizes a distinction that is easy to obscure in product copy: the toggle controls training consent, not whether code leaves the machine at all. Data was being transmitted to the grok-code-session-traces bucket on Google Cloud Storage whether or not the user had opted out of model improvement — and, per the report, neither that bucket nor any upload mechanism appears in Grok Build's setup documentation.

This pattern has appeared with other AI-assisted developer tools and echoes broader concerns about what "local" really means when an agent depends on cloud inference to function. For readers tracking similar incidents, a related case of the Grok CLI uploading an entire home directory to GCS and a separate report of Grok uploading a user directory to xAI's servers surfaced around the same period, suggesting this behavior is not an isolated edge case confined to a single code path.

Understanding xAI Grok Build and Its Underlying Stack

Product Context

To understand why this disclosure matters commercially, it helps to understand what xAI Grok Build is. The tool is xAI's entry into the rapidly crowding agentic coding assistant market, designed to let developers run a CLI-based coding agent that can read, edit, and reason about entire codebases using the xAI Grok API. Early versions carried a 0.1 designation; the tested build, 0.2.93, reflects rapid iteration in a competitive market where frequent releases are common. Each session authenticates with an xAI Grok API key, which — as the writer's own reasoning, not a point verified in the report — would generally mean traffic generated during a session is associated with an authenticated account rather than being fully anonymous.

The Model Family

As general product context (rather than a detail confirmed in cereblab's captures), xAI positions Grok 4 for deeper reasoning tasks and xAI Grok Code Fast 1 for latency-sensitive, turn-by-turn coding interactions where response speed matters more than maximum reasoning depth. The xAI Grok Build marketplace provides a distribution layer, allowing developers and teams to discover, deploy, and share agents or extensions built on top of the core Grok Build infrastructure — a distribution surface that would amplify the data-handling implications of any default behavior in the core CLI.

The GCS Architecture Question

The architectural choice to route repository data to Google Cloud Storage — rather than xAI's own branded infrastructure — is itself notable. It suggests the upload pipeline may have been integrated into an existing GCS dependency rather than purpose-built. That said, the underlying cloud provider does not change the privacy calculus for end users: code is reaching a bucket that xAI controls and administers, regardless of whether the physical storage layer belongs to Google.

The Data Volumes in Context

The raw numbers from cereblab's test are worth examining in structured form to appreciate the scale of what was being transmitted versus what was operationally necessary for the agent to function.

Traffic Channel	Volume	Purpose	Disclosed?	Notes
Model request (task context)	~192 KB	Agent reads files to respond to coding queries	Yes (expected)	Proportionate to the task; consistent with normal agent operation
Google Cloud Storage upload	~5.1 GB	Full Git repository + complete commit history sent to grok-code-session-traces	No	Upload not scoped to files the agent accessed; entire object store transmitted
Ratio (GCS upload vs. working context)	~27,000×	—	—	Derived from ~5.1 GB versus ~192 KB; illustrates the disproportionality of the undisclosed channel
Canary credential in .env	Verbatim, unredacted	Confirms that secrets travel with the repository payload	No	Credential appeared in GCS-bound traffic; no evidence of redaction or filtering

For teams running the xAI Grok Build CLI against large monorepos — repositories that frequently reach tens or hundreds of gigabytes in mature engineering organizations — the implied upload would be proportionally larger. A repository containing years of proprietary feature development, database schemas, internal tooling scripts, and infrastructure-as-code configuration is not meaningfully different, from a competitive-intelligence perspective, from handing over a compressed archive of the company's intellectual property to an undisclosed third party.

The Server-Side Fix and Why It Raises Fresh Questions

What Changed — and How

One day after cereblab's report became public, the same researcher retested the identical 0.2.93 client without installing any update. The upload behavior had stopped. The server was now returning disable_codebase_upload: true alongside trace_upload_enabled: false, and across six consecutive retests on the same machine, no repository upload was observed.

The mechanism of the fix is significant: xAI flipped a hidden server-side configuration flag remotely. No client update was released, no version number changed, and no security advisory was published. The official changelog listed version 0.2.98 as the latest release as of July 12, 2026 — the day before the report became public — and contained no mention of repository-upload behavior, the grok-code-session-traces bucket, or any data-transmission change.

What the Fix Reveals About the Architecture

This architectural detail has two faces. On one hand, a remotely configurable upload switch allowed xAI to respond in under 24 hours without requiring every user to update their CLI — a faster response than a mandatory client patch would have permitted. On the other hand, the existence of that server-side switch reveals that the upload behavior was never hard-coded into the client as a technically necessary feature: it was always controllable at the server level. That makes its default-on state during an undisclosed period significantly harder to explain as an accidental oversight rather than a deliberate design choice.

What the Fix Did Not Confirm

Cereblab was careful to enumerate what remained unresolved after the flag flip:

• Verification was performed on one machine and one account only — there is no independent confirmation that the flag flip is global across all users, staged to specific regions or account tiers, or permanent rather than reversible.
• xAI has made no statement confirming whether repositories already stored in the grok-code-session-traces bucket will be deleted, anonymized, or retained indefinitely.
• There is no evidence that xAI trained models on the uploaded code — but absence of evidence is not evidence of absence, and xAI has not published a statement ruling it out.
• There is no evidence that any xAI employee accessed or reviewed the uploaded repositories.
• Cereblab explicitly characterized the finding as a disclosure of undisclosed collection, not confirmed misuse — a distinction that matters ethically and legally, but does not diminish the severity of the collection itself.

Those distinctions matter across legal, regulatory, and ethical dimensions — but they do not change the core finding: data was collected without disclosure, at enormous scale relative to any stated operational purpose, with an opt-out mechanism that did not function as users would reasonably expect.

xAI's Response: Silence Where a Statement Was Needed

No Public Communication

As of the International Cyber Digest report dated July 13, 2026, xAI had issued no public statement about the upload behavior, its intended purpose, the retention period for data already in the bucket, or whether affected users would be notified. There was no security advisory, no blog post, no changelog entry, and no response to the researcher's findings on any public channel. The server-side flag was flipped, and the company said nothing.

Regulatory and Legal Dimensions

For a product pitched to professional developers and enterprise teams — the audience most sensitive to undisclosed code exfiltration — that silence is itself a signal. Data protection frameworks in multiple jurisdictions impose specific obligations that xAI's response, as described, does not appear to satisfy:

• GDPR Article 13 requires that data subjects be informed of the purposes and legal basis for processing at the time data is collected — not after a researcher publishes intercepted traffic.
• GDPR Article 17 establishes the right to erasure; users whose repositories were uploaded without disclosure have a plausible claim to demand deletion of that data.
• CCPA / CPRA in California requires businesses to disclose the categories of personal information collected and the business purpose for collection, at or before the point of collection.
• Contractual exposure arises separately from privacy law: source code covered by a commercial license, employment agreement, or client contract may have been transmitted in breach of those agreements, regardless of whether any personal data regulation was triggered.

Competitive Positioning at Risk

The xAI Grok Build coding agent was positioned to compete directly with Anthropic's Claude Code, GitHub Copilot Workspace, and Cursor — products from companies that have, under competitive pressure and regulatory scrutiny, published detailed data-handling policies, signed data processing addenda for enterprise customers, and in some cases pursued SOC 2 Type II certification. xAI's handling of this disclosure makes that competitive positioning significantly harder to defend in enterprise procurement conversations, where a single security questionnaire item about undisclosed data transmission to a third-party bucket could eliminate the product from consideration entirely.

Practical Guidance for Developers and Security Teams

Until xAI publishes a formal data processing statement covering the xAI Grok Build CLI, security-conscious developers and their teams should consider the following steps:

1. Treat the fix as unverified at scale. The server-side flag was confirmed disabled on one machine and one account. Do not assume the behavior is globally and permanently off without independent verification for your account and region.
2. Audit your Git history before using any AI coding agent. Use tools such as git log --all --full-history -- path/to/secrets or dedicated secret-scanning tools (e.g., trufflehog, gitleaks) to understand what sensitive material exists in your repository's history — not just its working tree.
3. Use dedicated test repositories. When evaluating any AI coding agent, create a repository that contains no production secrets, no proprietary algorithms, and no regulated data. Test there first.
4. Capture your own network traffic. Tools like mitmproxy or Charles Proxy are accessible to most developers. Intercepting your own agent's traffic before trusting it with real codebases is now a reasonable precaution, not an extreme measure.
5. Demand a Data Processing Addendum (DPA). Enterprise procurement teams should require a signed DPA from xAI before deploying Grok Build against any codebase covered by employment agreements, client contracts, or regulated-data obligations.
6. Rotate any secrets that may have been in scope. If you used xAI Grok Build 0.2.93 or earlier versions against a repository containing real credentials, rotate those credentials immediately, regardless of whether you can confirm they were accessed.
7. Monitor the changelog actively. The lack of a public advisory in this incident means you cannot rely on xAI communicating future changes through conventional security disclosure channels. Subscribe to changelog updates and watch for behavioral changes through your own monitoring.

Key Takeaways

• Full Git histories were uploaded silently. The xAI Grok Build CLI (v0.2.93) was sending entire repositories — including full commit history — to a Google Cloud Storage bucket named grok-code-session-traces, with uploads reaching approximately 5.1 GB on a 12 GB test repository.
• The opt-out toggle did not function as advertised. Disabling "Improve the model" in the Grok Build interface had no effect on uploads; the server returned trace_upload_enabled: true regardless, revealing the toggle governed training consent only, not data transmission to GCS.
• Secrets left the machine unredacted. A canary credential planted in a .env file appeared verbatim in intercepted GCS-bound traffic, confirming that secrets in repository history are included in what gets uploaded without filtering.
• The fix was a hidden server-side flag. xAI resolved the behavior within 24 hours by flipping a remote configuration flag — no client update, no public advisory, no changelog entry, and no statement on what happens to data already collected.
• Verification of the fix is limited. The behavior change was confirmed on one machine and one account only; global rollout and permanence are unconfirmed.
• Stored data fate is unknown. xAI has made no announcement about whether repositories already uploaded to grok-code-session-traces will be deleted, how long they will be retained, or who has accessed them.
• "Local-first" claims are directly contradicted. The observed behavior is incompatible with xAI's marketing description of Grok Build as a local-first tool.
• Regulatory exposure is real. GDPR Articles 13 and 17, CCPA/CPRA, and contractual obligations around source code all create potential legal exposure for the undisclosed collection, independent of any confirmed misuse.

What Comes Next for xAI Grok Build

xAI now faces a credibility gap that a server-side flag flip alone cannot close. The immediate technical behavior may have been addressed, but the harder questions demand a formal response that has not arrived: What data is currently stored in the grok-code-session-traces bucket? Who at xAI had access to it? What was the original purpose of the upload pipeline? Will stored repositories be deleted, and on what timeline? Was any uploaded code used to fine-tune or evaluate any version of Grok 4 or xAI Grok Code Fast 1?

Developers and security teams evaluating the xAI Grok Build CLI as part of their toolchain will almost certainly require written data processing agreements and audited data retention policies before any re-engagement involving enterprise or regulated-industry codebases. The incident also sharpens regulatory attention at a moment when AI coding agents broadly are under increased scrutiny over precisely these issues: what leaves the developer's machine, under what authorization, and with whose knowledge.

For xAI — which is simultaneously scaling the xAI Grok API, the xAI Grok Build marketplace, and the underlying Grok 4 model family — the path forward requires a level of transparency commensurate with the access these tools demand. A CLI that can read and reason about an entire codebase is one that must be trusted at a level approaching that of a senior employee with production access. Earning that trust after an incident like this requires more than a quietly flipped flag. It requires a public accounting.

---

Frequently Asked Questions

What is xAI Grok Build?

xAI Grok Build is a CLI-based agentic coding assistant developed by xAI, the artificial intelligence company founded by Elon Musk. It uses the xAI Grok API — authenticated via an xAI Grok API key — to power an AI agent capable of reading, editing, and reasoning about software codebases. As product context, xAI positions the Grok 4 model for complex reasoning tasks and the xAI Grok Code Fast 1 model for fast, turn-by-turn interactions. Early releases carried a 0.1 designation; at the time of this disclosure the latest listed version was 0.2.98, with 0.2.93 being the tested build.

What exactly did the xAI Grok Build CLI upload?

According to the researcher cereblab's technical findings, the xAI Grok Build CLI was uploading entire Git repositories — including the full Git commit history — to a Google Cloud Storage bucket named grok-code-session-traces. On a 12 GB test repository, the upload volume was approximately 5.1 GB. The upload was not scoped to files the agent accessed during the session; it encompassed the entire Git object store.

Did disabling the "Improve the model" toggle stop the upload?

No. Cereblab explicitly tested this. With the toggle disabled, the Grok Build server continued returning trace_upload_enabled: true and the GCS upload proceeded as normal. The toggle controls whether data is used for model training, not whether data is transmitted to xAI's cloud infrastructure.

Has xAI fixed the issue?

The upload behavior was disabled via a server-side configuration flag approximately one day after cereblab's public disclosure — the server began returning disable_codebase_upload: true and trace_upload_enabled: false. However, the fix was verified on only one machine and one account. xAI has issued no public advisory, no changelog entry documenting the change, and no statement about whether the fix is global and permanent, or what will happen to repositories already stored in the bucket.

What should I do if I used xAI Grok Build before the fix?

If you ran the xAI Grok Build CLI (version 0.2.93 or earlier) against a repository containing real credentials or sensitive code, you should: (1) immediately rotate any secrets that may have existed anywhere in the repository's Git history; (2) audit your repository history for sensitive material using tools like trufflehog or gitleaks; (3) consult your legal or compliance team if the repository contained data subject to GDPR, HIPAA, client contracts, or export-control regulations; and (4) consider submitting a formal data deletion request to xAI under applicable privacy law.

Is the xAI Grok Build marketplace affected?

The disclosure specifically concerns the core xAI Grok Build CLI data transmission behavior. Extensions or agents distributed through the xAI Grok Build marketplace that depend on the same core infrastructure may have been subject to the same upload mechanism, but this has not been independently verified. Treat marketplace-sourced agents with the same caution until xAI publishes a formal data handling statement covering the full platform.