Does Grok Build Upload Your Entire Repository? The Evidence and What to Do

On July 12, 2026, an independent researcher published a wire-level analysis of xAI’s Grok Build CLI 0.2.93. The report’s central claim is unusually specific: a normal consumer session uploaded the entire tracked Git repository and its history as a bundle, independently of which files the coding agent opened.

The researcher did more than notice network traffic. They captured the upload, cloned the resulting Git bundle, and recovered a file that Grok had been explicitly told not to read. In a separate path, a tracked .env file containing fake API_KEY and DB_PASSWORD values appeared unredacted in model requests and a session-state archive.

That is a serious security finding. It is not, however, proof that xAI trained on the code, that every Grok Build account behaves identically, or that ignored and untracked files are always swept up. Those distinctions matter if developers are going to respond proportionately instead of turning a strong report into a looser allegation.

Update — July 16, 2026: SpaceXAI open-sourced Grok Build under Apache 2.0, reset usage limits, and reiterated July 12 retention changes — full install, license, and PR-policy coverage: Grok Build open source.

Update — July 13: The same researcher retested the same 0.2.93 client six times and observed zero /v1/storage uploads. The server now returned trace_upload_enabled: false and a new disable_codebase_upload: true. That strongly suggests a server-side mitigation after the report, but it has only been verified on one machine and account. xAI had not published an advisory explaining whether the change is global, staged, permanent, or retroactive.

Update — July 14: xAI provided the following official comment on this report:

We care deeply about your privacy and respect customer choice. For teams using zero data retention, no trace and code data is ever retained. All API key use of Grok Build also respects ZDR.

If ZDR is disabled, the /privacy command is available in the CLI to disable data retention, which also deletes previously synced data.

Run the /privacy command to view or change your settings at any time.

This is the first public, on-record response from xAI since the report was published. It confirms the existence of a zero-data-retention (ZDR) mode covering both direct consumer use and API-key use of Grok Build, and points to a /privacy CLI command as the user-facing control for viewing and changing retention settings — including deleting data already synced under a non-ZDR configuration.

It does not, however, close every gap this article identifies. The statement addresses retention under ZDR; it does not confirm whether the July 12 upload behavior (a full Git-bundle transmission to /v1/storage that continued with "Improve the Model" turned off) occurred on accounts with ZDR enabled or disabled, and it does not specify whether /privacy was discoverable in CLI version 0.2.93 at first launch. Until xAI clarifies that, treat the comment as confirmation that a retention control exists and is documented, not as proof the specific transmission behavior reported here was safe under every account configuration. Run /privacy yourself and check the reported server flags (trace_upload_enabled, disable_codebase_upload) before treating any account as verified.

Update — July 14 (later): The story escalated on X within hours of the SpaceXAI post.

Musk's deletion pledge goes further than /privacy self-service: it implies a global wipe of pre-existing SpaceXAI/Grok Build storage, not only per-user CLI toggles. No deletion audit, SLA, or third-party attestation accompanied the post — the same gap that made the original upload scandal bite.

explainx.ai read: Hiring a Skiff-grade privacy engineer to tweet /privacy after a wire-level exfil report is reputation repair, not root-cause closure. Users want answers to why full-repo upload existed, why defaults were not opt-in, and whether home-folder runs (reported in thread replies) were in scope — not only how to delete after the fact.

TL;DR: what is verified, alleged, and still unknown?

What the researcher actually tested

The report came from cereblab, who routed Grok Build traffic through mitmproxy on macOS using a throwaway repository and fake canary values. The binary under test identified itself as:

grok 0.2.93 (f00f96316d4b)
SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c

The test separated two data paths that are easy to blur together:

1. Model-turn traffic sent files Grok actively read to cli-chat-proxy.grok.com/v1/responses.
2. Storage traffic sent repository and session-state artifacts through /v1/storage, with metadata identifying the grok-code-session-traces Google Cloud Storage bucket.

Every cloud coding agent must send some source context to a remote model. The first path is therefore expected in principle, although sending credential files without redaction is a security problem. The second path is the surprising one: a repository-wide snapshot that did not appear limited to context the model needed for the request.

This is the same trust-boundary lesson we cover in our MCP security guide. A tool having permission to read a workspace does not make every possible collection, retention, and secondary-processing behavior obvious or acceptable. Capability, consent, and data lifecycle are three different controls.

The strongest evidence: cloning the uploaded bundle

The decisive experiment used a real 298-file codebase with a unique marker placed in:

src/_probe/never_read_canary.txt

The prompt instructed Grok to reply with OK and not read or open any files. According to the preserved artifacts, Grok uploaded a Git bundle through /v1/storage, which returned HTTP 200. Cloning that captured bundle reconstructed the repository, including the never-read canary and four commits of Git history.

The researcher repeated the test on a second repository and recovered a different unique marker. That closes the most important alternative explanation: the storage traffic was not merely a cache of files the model had opened.

A size-scaling test adds supporting evidence. In one session against a 12 GB repository of random files, model-turn requests carried only about 192 KB, while storage requests transmitted at least 5.10 GiB before the researcher stopped the capture. Seventy-three large chunks of roughly 75 MB each received HTTP 200 responses.

The test did not run long enough to prove that all 12 GB completed. It did show that multi-gigabyte storage uploads continued even after model requests hit usage limits.

The .env finding needs exact wording

The report planted fake secrets:

API_KEY=CANARY7F3A9-SECRET-should-not-leave
DB_PASSWORD=CANARY7F3A9-DBPASS

When Grok read that tracked file, the values appeared verbatim in a /v1/responses request and in a staged session_state archive sent through the storage path. No inline redaction was visible for those values.

What this proves:

• A tracked .env-style file read by Grok was transmitted unredacted
• The same fake values appeared in a session artifact destined for storage
• A generic training opt-out did not prevent those data paths

What it does not prove:

• That all secret patterns evade every redactor
• That an untracked or .gitignored .env is always included in the repository bundle
• That xAI used the data for training
• That business, enterprise, API-key, and zero-data-retention accounts share the consumer behavior

The safest operational assumption is still that anything an agent can read may leave the machine. But a precise article should not upgrade an untested gitignore case into a confirmed fact.

“Improve the Model” is not an upload switch

xAI’s consumer FAQ describes “Improve the Model” as a control over whether new conversations are used for model training. It does not promise that disabling the setting prevents remote inference or all storage.

In the captured 0.2.93 test, turning that control off did not stop the Git-bundle upload. The settings response still included:

{
  "trace_upload_enabled": true,
  "upload_enabled": true,
  "session_registry_enabled": true
}

This is an important distinction, not a semantic escape hatch. A cloud model cannot answer without receiving some context, so “do not train” cannot logically mean “send no data.” But users need a separate, documented control for repository-wide sync or trace uploads—especially when the mechanism collects more than the model appears to need.

Training consent and data minimization solve different problems:

The documentation gap is the real product failure

xAI’s Grok Build quickstart tells users to run the agent from a project directory and offers prompts such as “Explain this repo.” It does not surface a repository-wide Git-bundle upload in that setup flow.

The enterprise deployment documentation provides more detail. It lists the inference proxy, remote session sync, sandboxes, managed controls, and a data lifecycle. It also says the storage.googleapis.com host is needed only for the shell installer and updates in that enterprise configuration. The consumer analysis instead observed codebase artifacts routed through the inference proxy and metadata naming a GCS bucket.

Those statements may refer to different account paths. They still demonstrate why a single generic privacy policy is not enough for a local coding agent. Developers need a product-specific table that says, for every authentication mode:

• Whether the full repository is snapshotted
• Whether Git history is included
• Whether ignored, untracked, and outside-workspace files are excluded
• What triggers each upload
• Where artifacts are stored
• How long they are retained
• Whether training, sync, and telemetry can be controlled independently
• Whether enterprise zero-data-retention applies to every storage path

Until xAI publishes that, teams cannot make a serious data-classification decision.

Why developers are angry — opt-out vs opt-in

The July 14 responses landed after the cereblab report went viral — not in the Grok Build onboarding flow on day one. Thread replies converged on the same complaints:

Skiff pedigree matters: Milich spent four years on end-to-end encrypted email/docs at Skiff (acquired by Notion). That is why his hire at SpaceXAI reads as intentional — but E2E product culture and silent Git-bundle upload defaults are opposite stories until xAI publishes architecture.

What changed after the report

The most important current fact is that the original behavior did not reproduce in the researcher’s July 13 comparison run.

Because the binary did not change, the researcher attributes the July 13 difference to server-delivered configuration. Musk's deletion promise, if executed, would address retention of past uploads — but still would not answer why collection happened, who received the server flags when, or whether copies exist outside SpaceXAI-controlled buckets (inference logs, backups, legal hold).

Still, the update should change the headline from “cannot be stopped” to “was enabled in the documented 0.2.93 test and now appears disabled server-side.” Security reporting should be just as quick to record a mitigation as it is to record the original failure.

What developers should do right now

1. Pause Grok Build on sensitive repositories

Do not run the consumer CLI in repositories containing proprietary algorithms, customer data, regulated information, unreleased security work, or third-party code covered by confidentiality terms until your account’s current behavior is verified and xAI documents the control.

The official Grok Build changelog listed 0.2.98 as the latest documented release on July 12 but did not mention repository-upload behavior. Updating is sensible; the observed mitigation appears to be server-side and therefore needs a documented product guarantee, not only a version check.

2. Rotate credentials, not just files

If Grok Build could read a real .env, assume those credentials may have been transmitted. Revoke and reissue API keys, database passwords, cloud tokens, signing secrets, and webhook credentials. Deleting the local file does not invalidate a credential already exposed.

Also inspect Git history. Removing a secret from the current branch does not remove it from prior commits—the exact reason a full-bundle upload increases risk. Our guide to secrets and system-prompt leaks in GitHub covers the difference between deletion and rotation.

3. Test only in a sanitized export

If you must evaluate the product, create a throwaway directory containing only files you are willing to upload. Do not copy .git, environment files, production configs, customer fixtures, or internal documentation.

Do not treat .gitignore as a verified security boundary here. The published analysis did not fully test it, and ignore rules were built for version-control hygiene—not data-loss prevention.

4. Use network and endpoint monitoring

Enterprise teams should inspect proxy logs, DNS, egress volume, and endpoint telemetry while testing any coding agent. A multi-gigabyte upload from a small prompt is precisely the kind of anomaly data-loss-prevention controls should catch.

Blocking storage.googleapis.com alone may be insufficient because the report captured storage requests through the required inference proxy. The right control is a sanctioned deployment with documented collection behavior, not a brittle hostname block.

5. Run /privacy and document your account state

After July 14, every user can run /privacy in the Grok Build CLI to view retention settings, disable sync, and — per SpaceXAI and Milich — delete previously synced data. Do this before returning sensitive repos to the tool. Screenshot or log the output for compliance records.

Musk's blanket deletion pledge may overlap with /privacy, but do not rely on a tweet for regulated data — request written confirmation from xAI if your org requires it.

6. Prefer explicit data guarantees

For sensitive work, use an enterprise plan with a contractually defined retention policy, an approved self-hosted or local model, or a coding harness that sends only selected context. Our comparison of closed cloud AI and local open-source alternatives explains the trade-off: local tools reduce provider exposure but move model, sandbox, and dependency security onto your team.

How xAI should respond

A credible response would contain more than “we do not train on enterprise data.” xAI's July 14 statement makes a start — it documents a zero-data-retention mode and a /privacy command that lets users view, change, and delete retention settings, including previously synced data. That covers part of item 6 below (a user-facing deletion control) and gestures at item 4 (separating training from retention). It does not yet cover the rest:

1. Confirm which versions and account types created full Git bundles
2. Explain the functional need for repository-wide uploads
3. Publish exact inclusion and exclusion rules
4. Separate training, telemetry, session sync, and repository snapshot controls — partially addressed: ZDR and /privacy are now documented, but the distinction between training opt-out, inference context, session sync, and telemetry (see the table above) still isn't spelled out per-control
5. Default repository upload to opt-in with first-run disclosure (not post-scandal /privacy discovery)
6. Add secret scanning and a hard denylist for credential files — not addressed; the July 14 comment is about retention, not redaction of secrets in transit
7. Provide deletion and incident-response guidance for prior sessions — partially addressed: /privacy + Musk deletion pledge; no verified execution
8. Publish deletion audit or third-party attestation for Musk's "zero anything" claim
9. Commission an independent reproduction of the fixed build

Permission prompts for shell commands do not solve a first-party upload performed by the client itself. The collection path still needs its own user-visible control distinct from the retention setting — and confirmation that the /privacy command was available, and its default state, in the version tested on July 12.

Our verdict

The cautious headline is not “xAI stole every developer’s code.” The evidence does not establish that.

The defensible conclusion is still serious: a reproducible test of Grok Build 0.2.93 on a consumer account captured successful uploads of complete tracked Git repositories and history, plus unredacted fake secrets from a file the agent read. Disabling model training did not disable that upload. A day later, a new server flag stopped repository uploads in six retests on the same account.

By July 14 evening, xAI documented ZDR and /privacy, Andrew Milich affirmed retroactive delete for all users, and Elon Musk promised total erasure of everything uploaded before — 3.4M-view crisis comms for a product launched alongside Grok 4.5. The fast server-side change and deletion pledge are encouraging if verified; until then, Grok Build remains trust-me-bro for sensitive repositories. Run /privacy, rotate secrets, and demand opt-in upload defaults — the industry lesson applies to every agent in our AI coding tools directory: reading source code is part of the job; collecting an entire workspace is a product decision teams must know about before the first prompt.

Related on explainx.ai

• MCP security guide: trust boundaries, tokens, and tool isolation
• System prompts and secrets exposed through GitHub
• Grok Build open source: Apache 2.0 harness, install, local-first
• Grok 4.5 launch, benchmarks, and coding stack
• Top AI tools for coding in 2026
• Closed-source AI vs local open-source alternatives
• Run open-source models locally with OpenCode
• Is Claude Cowork safe? Threat model and security controls
• Connect AI tools safely through MCP

Primary sources: cereblab wire-level report and reproduction · July 13 before/after comparison · reproduction repository · xAI Grok Build documentation · xAI enterprise deployment and data lifecycle · xAI consumer data FAQ · official Grok Build changelog

This article reflects public evidence and official statements through July 14, 2026 (evening UTC). The upload was documented on Grok Build 0.2.93; a same-client retest observed a server-side disable flag; SpaceXAI documented ZDR and /privacy; Musk pledged total deletion of prior uploads without published audit proof. Verify current behavior before deployment.