Grok Build Uploads Entire Git Repositories to xAI Storage, Not Just Files It Reads

# Grok Build Exposed Entire Git Repositories to xAI Cloud Storage—With Secrets and History Intact

A security researcher has disclosed that xAI's Grok Build coding assistant was uploading complete Git repositories—including full commit histories, unread files, and unredacted credentials—to cloud storage without explicit user consent. Testing by the researcher identified a 27,800x disparity between the data the AI model actually needed and what was being transmitted to xAI's servers, suggesting wholesale repository collection rather than targeted file access.

## The Threat

Grok Build, xAI's AI-powered CLI tool for code generation and analysis, was uploading entire tracked Git repositories to a Google Cloud Storage bucket (grok-code-session-traces) operated by xAI. The uploads included:

The researcher, publishing under the handle cereblab, demonstrated the behavior through controlled testing in version 0.2.93. The uploads occurred on a separate network channel from the model API itself, making the data exfiltration quantifiable and distinct from normal model inference.

## Technical Details: The Evidence

Cereblab's analysis revealed a stark mismatch between intended and actual data transmission:

| Metric | Value |

|--------|-------|

| Repository size | 12 GB |

| Data sent to model API | ~192 KB |

| Data sent to storage | 5.10 GiB |

| Disparity ratio | ~27,800x |

| Upload chunks | 73 at ~75 MB each |

| All chunks returned | HTTP 200 |

The storage uploads were directed to the same Google Cloud bucket referenced in Grok Build's binary and metadata files. The researcher planted a honeypot file—src/_probe/never_read_canary.txt—specifically flagged in the task instructions as off-limits. When the researcher retrieved the intercepted upload, the canary file appeared verbatim in the repository bundle, along with full commit history dating back years.

The credential exposure was equally clear. When Grok Build read a .env file during a coding task, the file's contents (including placeholders like API_KEY and DB_PASSWORD) were transmitted to the model turn and simultaneously archived in a session_state bundle destined for storage. While the researcher used fake credentials to avoid real-world compromise, the unredacted transmission of sensitive configuration files represents a fundamental data handling failure.

Importantly, the volume of uploaded data scaled directly with total repository size across multiple test runs, not with files actually accessed. This pattern is consistent with bulk repository collection, not selective file gathering.

## Background and Context

Cloud-based AI coding tools necessarily transmit source code to remote servers to function—that is architecturally inevitable. Claude Code and Codex send the files they open. Gemini Code Assist does the same. Users of these tools implicitly accept that limitation when enabling cloud features.

Grok Build was different. Testing showed that xAI's tool was uploading the entire repository—including files never touched by the model—on a scale orders of magnitude beyond what the model inference pipeline required. This represents a boundary violation: transmitting data that served no functional purpose for the coding task at hand.

The behavior appeared to be intentional, governed by metadata xAI included in the tool's configuration. The destination bucket name was hardcoded, and the server responded with metadata directing chunk assembly. Yet the upload mechanism was entirely opaque to users. Grok Build offered a toggle labeled "Improve the model," which users assumed would control data transmission to xAI's servers. That assumption was incorrect.

### The Settings Control Failure

When users disabled "Improve the model," intending to prevent data use for training, Grok Build continued uploading entire repositories. The server's /v1/settings response maintained trace_upload_enabled: true even when the user-facing toggle was off. The researcher's analysis revealed that xAI exposed only one control to users—one governing training use—while the actual data transmission operated on a separate, hidden channel. These are two distinct operations:

1. Using data for model improvement (user-facing toggle)

2. Uploading code to cloud storage (no user-facing toggle)

Only the first was controllable; the second was not. This asymmetry meant users could not meaningfully consent to or refuse repository uploads.

## Implications for Organizations

Organizations using Grok Build faced multiple risks:

Unlike model training—where a researcher might argue that input data could be discarded after inference—the storage uploads suggest persistent, archival retention. The bucket architecture and metadata suggest the data was retained for later analysis or use.

Smaller teams and solo developers using Grok Build for closed-source projects faced the same exposure, with no easy mechanism to audit what was transmitted or to refuse the behavior.

## Grok Build's Response and Current Status

On July 13, 2026—one day after cereblab's initial testing—the behavior abruptly changed. Cereblab retested the same 0.2.93 binary six times and observed zero /v1/storage uploads. The server began returning disable_codebase_upload: true and trace_upload_enabled: false.

Other developers, including Peter Dedene, reported the same server-side flags appearing in their accounts, suggesting the change was not isolated to a single user but was a coordinated server-side rollout.

Critically, no client-side update was required. The Grok Build binary remained at version 0.2.93 while its backend behavior changed—indicating xAI's infrastructure now prevents uploads from that version. However, xAI has not:

## Recommendations

### For Grok Build Users

1. Assume repository data was transmitted. Do not rely on xAI's silence to conclude your code is safe. Request explicit confirmation from xAI about data retention and deletion policies.

2. Rotate any credentials that may have been in tracked repositories. Even if xAI claims not to have trained on the data, the files were accessible to xAI infrastructure.

3. Review commit history for sensitive data. Identify .env files, API keys, customer information, or internal URLs that may have been uploaded in prior commits.

4. Pause Grok Build usage until xAI publishes a transparent security report and explains the scope of the data collection.

### For Organizations

1. Audit Grok Build deployments. Identify teams using the tool and notify them of the data transmission behavior.

2. Implement network controls. Block or monitor outbound connections to grok-code-session-traces and xAI's API infrastructure if Grok Build must continue to be used.

3. Update AI tool policies. Specify which cloud coding assistants are permitted and require explicit acknowledgment of data transmission risks.

4. Request information from xAI. Demand transparency on data retention, deletion timelines, and access controls over uploaded repositories.

## HackWire Analysis

This incident exposes a critical pattern in AI tool governance: the gap between disclosed and actual data transmission. Users were presented with a single control—training data opt-out—and reasonably assumed it governed all data leaving their machines. xAI's infrastructure reveals a more complex reality: storage and archival happen independently of training decisions.

The scale of the disparity (27,800x) is not a rounding error or a minor leak; it indicates intentional bulk collection. Whether that collection was for debugging, model improvement via non-training analysis, or capability research remains unclear—xAI has not explained its purpose.

Grok Build is not unique in transmitting code to cloud infrastructure. But wholesale repository collection sits in a different category than selective file transmission. Claude Code and Codex can justifiably claim they send only what the model needs; Grok Build cannot make that claim.

The shutdown on July 13 is welcome but insufficient. Silence on data handling, retention policies, and prior uploads leaves organizations unable to assess real-world risk. If xAI retains the uploaded repositories for any purpose—debugging, capability research, future training, or vendor partnership—those files represent a persistent security liability.

Most concerning is the usability of the honeypot file. That xAI's infrastructure accepted, stored, and returned a file explicitly marked as off-limits suggests the upload mechanism had no awareness of user intent. The tool uploaded everything it found, user guidance be damned.

— HackWire Editorial

---

## Related Coverage