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 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 has not published an advisory explaining whether the change is global, staged, permanent, or retroactive.
TL;DR: what is verified, alleged, and still unknown?
Question
Current evidence
Was code transmitted?
Yes in the documented test; captured requests received successful responses
Was the whole tracked repo included?
Strong evidence: a captured Git bundle reproduced every tracked file tested plus full history
Yes in two replicated repositories; unique canary files were recovered from uploaded bundles
Were secrets redacted?
Not in the tested tracked .env; fake key values appeared verbatim
Did “Improve the Model” stop uploads?
No in the 0.2.93 consumer test; upload-related server flags stayed enabled
Did xAI train on the code?
Not proven; transmission and storage are different from training use
Are gitignored files uploaded?
Not established by the report; the secret file in the documented test was tracked
Has the behavior changed?
In six July 13 retests, a new server flag disabled codebase uploads; xAI has not publicly documented the change or its rollout scope
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:
The test separated two data paths that are easy to blur together:
Model-turn traffic sent files Grok actively read to cli-chat-proxy.grok.com/v1/responses.
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:
text
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.
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:
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:
Control
Question it answers
Training opt-out
May this content improve future models?
Inference context
Which files must be sent to answer this request?
Session sync
What is stored so a session can resume elsewhere?
Telemetry
What traces are retained for debugging or analytics?
Retention/deletion
How long does each artifact exist, and how can it be removed?
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.
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.
Test state
July 12 capture
July 13 retest
Client
Grok Build 0.2.93
Same 0.2.93 client
trace_upload_enabled
true
false
disable_codebase_upload
Not present / not enabled
true
/v1/storage repository uploads
Observed and captured
Zero across six runs
Public xAI explanation
None
None located
Because the binary did not change, the researcher attributes the difference to server-delivered configuration. That is a plausible inference, not proof of why xAI changed it. The result also does not tell us whether prior stored artifacts were deleted, whether every consumer account received the flag, or whether other session-state telemetry still operates.
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. 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 should:
Confirm which versions and account types created full Git bundles
Explain the functional need for repository-wide uploads
Publish exact inclusion and exclusion rules
Separate training, telemetry, session sync, and repository snapshot controls
Default repository upload to off or ask for explicit consent
Add secret scanning and a hard denylist for credential files
Provide deletion and incident-response guidance for prior sessions
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 needs its own user-visible control.
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.
The original behavior crosses a trust boundary most developers would expect to be documented explicitly. The fast server-side change is encouraging, but until xAI explains the purpose, scope, retention, rollout, and deletion status, Grok Build should not be treated as verified for sensitive repositories.
The broader 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 should demand to know the difference.
This article reflects public evidence available on July 13, 2026. The upload was documented on Grok Build 0.2.93 using a consumer login; a same-client retest then observed a server-side disable flag on one account. Verify current behavior and consult xAI’s latest security guidance before making a deployment decision.
