# Grok Build Secretly Uploaded Entire Codebases to xAI Storage, Including Files Never Read by the Model


Researcher discovers xAI's coding assistant transmitted complete Git repositories and unredacted secrets to cloud storage without user awareness, while competitors sent only necessary files.


## The Threat


xAI's Grok Build coding command-line interface was uploading entire Git repositories—complete with full commit history, unread files, and unredacted credentials—to a Google Cloud Storage bucket controlled by xAI, according to security research published on July 14, 2026. The discovery, made by independent researcher cereblab, reveals a significant gap between what developers believed was being transmitted and what actually left their machines.


The most striking detail: on a 12 gigabyte repository, the model received only about 192 kilobytes of data necessary to complete its task. Yet 5.10 gigabytes—roughly 27,800 times more data—flowed to xAI's storage infrastructure. This 27,000x disparity suggests systemic over-collection rather than incidental data handling.


The uploads were segmented into 73 chunks of approximately 75 megabytes each, all returning HTTP 200 success responses. Every upload correlated precisely with total repository size, not the subset of files the coding agent actually needed or opened. The destination bucket, named grok-code-session-traces and hardcoded in the Grok Build binary, accepted everything xAI decided to send.


Most critically: developers had no opt-out. A planted test file named src/_probe/never_read_canary.txt was uploaded and stored despite explicit instruction not to open it—and despite the model never reading it. The same unread file appeared in every cloned bundle, proving transmission occurred regardless of necessity.


## Background and Context


Cloud-based coding assistants inherently transmit source code to remote servers—that's how they function. Models like Claude Code, GitHub Copilot, and Google's Gemini must receive file content to analyze and generate suggestions. Developers accept this trade-off as the cost of AI-powered development tools.


What distinguishes this incident is scope. Competitors sending only the files required for a specific task represents the industry baseline. xAI's wholesale repository transmission went far beyond that boundary.


Grok Build is xAI's attempt to compete with Claude Code and Copilot, released as a CLI tool that reads developer workspaces and generates code, fixes bugs, and answers questions. The tool integrates with Git repositories, giving it awareness of the codebase structure. That integration became the vulnerability: Grok Build weaponized that awareness to transmit data well beyond necessity.


The researcher's methodology was sound. By intercepting HTTP traffic between the Grok Build CLI (version 0.2.93) and xAI's infrastructure, cereblab captured complete upload requests, re-downloaded them from the storage bucket, and verified contents by cloning the Git bundles locally. The test included a canary file as proof of concept—a marker file the agent was explicitly told not to open—and recovered it unchanged from storage.


Replicated testing on a second, unrelated repository produced identical results: full repository upload, complete commit history, and no filtering for necessity or sensitivity.


## Technical Details


### The Upload Mechanism


Grok Build maintained two separate communication channels:


1. Model inference channel (/v1/responses): Small, necessary payloads containing files the agent needed to complete its task

2. Storage channel (/v1/storage): Massive uploads of the entire repository


The metadata.json configuration file referenced in Grok Build's binary explicitly pointed to the Google Cloud Storage bucket path: gs://grok-code-session-traces/. This wasn't accidental; the configuration was hardcoded and staged for use.


### Credentials in Storage


The research uncovered a second, separate issue: unredacted environment files. When Grok Build opened a .env file during a task, its contents went into two places simultaneously:


  • The model's context window (expected)
  • The session state archive bound for storage (problematic)

    • Test credentials—API_KEY and DB_PASSWORD values—landed in storage with no redaction. While cereblab used placeholder values to avoid leaking real secrets, the behavior pattern makes the risk clear: any developer using Grok Build with active credentials in their local .env files exposed those credentials to xAI's infrastructure.


    ### The Toggle That Didn't Work


    Most concerning: Grok Build's user-facing "Improve the model" toggle—ostensibly designed to let developers opt out of data collection for model training—had no effect on repository uploads. Even with the toggle disabled, the /v1/storage uploads continued.


    Server responses even after disabling the toggle returned trace_upload_enabled: false for model training but didn't address codebase uploads at all. The control was exposed to users, but it governed only *one* data path. The wholesale repository transmission operated independently, leaving developers no option to prevent it from their interface.


    ## How This Compares to Competitors


    Cereblab's comparative testing against Claude Code and GitHub Codex revealed the distinction:


    | Tool | Repository Upload | File-Level Transmission | Behavior |

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

    | Grok Build | Full repo + history | Yes (and only necessary files) | Both channels active |

    | Claude Code | None | Only required files | Files only |

    | GitHub Codex | None | Only required files | Files only |

    | Google Gemini | None observed | Quota-limited test incomplete | Files only (when tested) |


    Grok Build stands alone in bulk-uploading the entire workspace. This is not a distinction without difference—a repository can contain years of commit history, deprecated code with embedded secrets, internal documentation, API endpoints, and customer data never intended for external transmission.


    ## Implications for Developers


    ### Immediate Exposure


    Any developer who used Grok Build version 0.2.93 on a non-public repository may have transmitted:


  • Proprietary source code to xAI's infrastructure (stored indefinitely until policy clarifies)
  • Commit history revealing design decisions, architectural patterns, and past vulnerabilities
  • Unredacted credentials from environment files (API keys, database passwords, OAuth tokens)
  • Internal URLs and infrastructure details embedded in code or configuration
  • Customer data that may exist in development branches or test fixtures

    • Developers cannot assume xAI has deleted these repositories or will limit access. The company has not published a data retention policy, deletion timeline, or access controls for the grok-code-session-traces bucket.


    ### Regulatory Considerations


    Developers working with sensitive data—healthcare, finance, payment processing—may face compliance violations. HIPAA, PCI-DSS, GDPR, and similar frameworks require data minimization. Uploading entire repositories without explicit informed consent likely violates those principles.


    Teams using Grok Build in restricted environments may have inadvertently breached data residency requirements or compliance policies that prohibit cloud transmission of certain data categories.


    ## xAI's Response


    On July 13, 2026—one day after the research was published—the Grok Build binary version 0.2.93 stopped making storage requests when cereblab retested. Six subsequent tests showed zero /v1/storage uploads. Server responses began returning disable_codebase_upload: true and trace_upload_enabled: false.


    Notably, the client binary didn't update; xAI toggled the behavior server-side. Developer Peter Dedene reported the same flag returned for his account, suggesting the change was global—or at least not limited to cereblab's session.


    xAI has not yet:

  • Confirmed whether the change is permanent
  • Explained why the feature existed
  • Disclosed how much data was collected or retained
  • Announced a deletion timeline for stored repositories
  • Addressed the unredacted credentials in storage

    • ## Recommendations


    For Developers Using Grok Build:


  • Assume exposure: Treat any repository uploaded to Grok Build as compromised. If it contained secrets, rotate them immediately.
  • Audit commit history: Review Git history for any embedded credentials, internal URLs, or sensitive data that may now be in xAI's possession.
  • Check environment files: Verify .env files don't contain active production credentials. Use separate config management for sensitive data.
  • Monitor for access: Watch for unusual account activity or unauthorized access to systems referenced in your codebase.

    • For Development Teams:


  • Restrict Grok Build in CI/CD pipelines: Do not allow Grok Build in automated workflows where it might access production code or secrets.
  • Update security policies: Clarify which cloud coding tools are permitted and under what conditions.
  • Credential rotation: Establish a regular rotation schedule for any credentials that may have been exposed during testing.
  • Policy review: Audit your compliance obligations. If you handle regulated data (healthcare, finance), consult legal before using cloud coding assistants.

    • For xAI:


  • Publish a detailed explanation of what data was collected, when, and for what purpose
  • Announce a timeline for deletion of stored repositories
  • Implement true user controls that govern repository uploads, not just model training
  • Conduct a security audit of the storage bucket access patterns and retention policies
  • Update terms of service to disclose all data transmission, not just model training

    • ---


    ## HackWire Analysis


    This incident exposes a critical gap between user expectations and actual behavior in cloud coding tools. Developers know they're sending code to remote models—that's the trade-off. What they *don't* expect is for an entire repository, including files never opened by the model and unredacted credentials, to be uploaded and stored indefinitely.


    The most damaging aspect is the false sense of control. xAI exposed a toggle to disable model training, and developers who toggled it off would reasonably assume their code was protected. They were wrong. The repository uploads continued regardless, because xAI built two separate data paths but only exposed one to users. That's not a technical limitation; it's a design choice that prioritized data collection over transparency.


    Pattern recognition: this mirrors past incidents where cloud providers quietly collect data "for system improvement," then face backlash when discovered. It also parallels the browser privacy problem—every major browser collects telemetry beyond what users think they're consenting to. The difference is browsers are free services; developers pay for Grok Build or assume they're the customer, not the product.


    The hidden risk is regulatory exposure. Developers in regulated industries likely violated compliance policies by using Grok Build without understanding what gets transmitted. If Grok Build was used on healthcare code, payment systems, or customer data, those developers now face audit trails showing unauthorized cloud transmission. HIPAA violations carry substantial penalties.


    The concrete next step: xAI needs to publish a full transparency report—what was collected, how long it's stored, who has access, and how deletion requests are handled. Until then, any developer using Grok Build should assume their entire codebase is now in xAI's possession and act accordingly: rotate credentials, flag past commits for review, and demand clarification from xAI.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Breaches](https://www.hackwire.news/category/breaches) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Data Privacy](https://www.hackwire.news/category/privacy)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)