Grok Build CLI Uploads Full Repos, .env Secrets: Report
12 Jul 2026
What happened
A new analysis of xAI's Grok Build CLI (version 0.2.93, build f00f96316d4b) claims the tool uploads entire code repositories — including secrets files like .env — to a Google Cloud Storage bucket, regardless of what the coding agent actually reads or what privacy settings a user has selected.
According to the report, the CLI transmits data through two separate channels: a live model turn via POST /v1/responses, and a broader session-state archive via POST /v1/storage. The storage uploads reportedly land in a bucket named grok-code-session-traces.
The numbers behind the claim
To test the behavior, researchers ran a 12 GB repository composed of files the coding agent never read. Despite that, the /v1/storage channel transferred 5.10 GiB of data. By comparison, a single model-turn request via POST /v1/responses was just 48,070 bytes — a gap of roughly 27,800× between the two channels. The report notes the Grok binary contains the string "Uploading bytes to GCS via proxy" embedded in its code, which it points to as evidence of the upload mechanism.
Privacy settings don't appear to stop it
Perhaps the most notable finding: disabling xAI's "Improve the model" setting did not stop the storage upload mechanism, according to the report. The /v1/settings endpoint reportedly still returned trace_upload_enabled: true even after the toggle was switched off — meaning the setting a user might reasonably interpret as an opt-out doesn't seem to govern this particular data flow.
The practical implication: any credentials, API keys, or proprietary code stored in a repository processed by the CLI could be transmitted to xAI's cloud infrastructure regardless of user consent settings, and independent of whether the agent ever touched those files during a session.
What's still unclear
Several important questions remain open. The report does not indicate whether xAI has publicly acknowledged or responded to these findings. There's no information on how long uploaded data is retained, who at xAI can access it, or whether this behavior is an intentional design choice (for debugging or model training) versus a bug. It's also unclear whether enterprise or team accounts have different upload configurations than individual consumer logins, or whether any full opt-out mechanism exists. Notably, the source of this analysis is a single published gist — there is no independent corroboration or official statement from xAI included in the report.
Why founders should care
If your team uses Grok Build CLI or similar AI coding agents, this report suggests you may want to treat repository-level exposure as a real possibility rather than an edge case. Specifically:
- Founders using the tool could reasonably want to audit which repositories and secrets may have already been transmitted to xAI's infrastructure during past sessions.
- Toggling a privacy or "model improvement" setting may not be sufficient to prevent data collection — this case suggests such settings can be decoupled from underlying storage mechanisms entirely.
- Teams managing sensitive credentials might consider isolating
.envfiles and API keys from any repository directory accessible to AI coding agents until vendors clarify their data-handling practices. - More broadly, this is a reminder to request explicit, written documentation from AI dev-tool vendors on exactly what data is transmitted, through which channels, and where it's stored — before granting these tools repository access.
The opportunity angle
For founders building in the developer tools space, this kind of report may point to unmet demand. Teams evaluating AI coding assistants could increasingly prioritize vendors that offer verifiable, user-controlled telemetry and demonstrable secrets redaction — an area where a transparency-first competitor could differentiate itself.
Bottom line
The report describes a specific technical behavior observed in one version of one tool, based on a single independent test. Absent an official response from xAI or independent corroboration, founders should treat this as a signal to investigate their own exposure and demand clearer documentation — not as a confirmed, company-wide policy statement.