Grok Build CLI Repository Upload Report: What the Wire Evidence Shows
Independent testing of Grok Build CLI 0.2.93 reports a data flow that deserves a much better answer than “cloud coding agents need your code.”
Of course they do. If an agent reads a file to explain or edit it, that content has to reach the model provider unless inference is local. The disputed behavior is a second lane: a background storage path that reportedly packaged a repository as a Git bundle and uploaded it even when the prompt said, “Reply with exactly: OK. Do not read or open any files.”
The researcher says the captured bundle could be cloned. It contained the unique marker from a tracked file the agent had been told not to open, plus commit history. A second unrelated repository reportedly produced the same result. In a separate large-repository run, the storage channel accepted at least 5.10 GiB before the researcher stopped the test, while model-turn requests carried only 196,705 bytes.
That is the trust break. Task context is expected. Background storage of the tracked repository and its reachable history is a different product action, with a different purpose, retention question, and consent requirement.
This is still a report, not an xAI-confirmed incident. The evidence is version-specific and does not prove training use, employee access, malicious compromise, universal scope, or how long the data remained stored. The central claim is supported by CerebLab’s detailed account, hashes, and later cloneable bundle samples. However, the decisive original bundle-to-HTTP captures and 12 GB wire log are not in the linked public repository, so RohitAI cannot independently verify those captures.
The central source is CerebLab’s wire-level analysis, supported by a public reproduction harness and later corroborating artifacts. The test used the official Grok Build CLI on macOS with a consumer login, synthetic canary values, a TLS-intercepting proxy, request-body capture, and hashes for the tested binary and evidence files.
RohitAI decompressed the official xAI macOS arm64 npm artifact for 0.2.93 and obtained SHA-256 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c, matching the hash CerebLab reports. This confirms that the reported hash corresponds to the official package; it does not independently prove which binary produced the capture or how the server configured it.
That matters because this story would be much weaker if it rested on a large temporary archive or a process monitor alone. Local staging is not proof of network transfer. High outbound volume is not proof of repository contents. The report says its test joined the two: it preserved a POST /v1/storage request accepted with HTTP 200, extracted a Git bundle from the body, cloned it with normal Git tooling, and recovered a never-read canary file verbatim.
There is an important provenance caveat. The currently linked repository contains two later Git-valid, cloneable permission-deny bundle files and a gzip file the author identifies as the raw post-disclosure settings response. It does not contain the original 152 KB and 31,743-byte bundles, their correlated HTTP log, or the cited 12 GB wire log. Those public files corroborate the bundle mechanics and mitigation signal; the original network-to-bundle correlation still depends on CerebLab’s account of its capture. That is why this article treats the finding as a credible report rather than independent confirmation by RohitAI.
The 12 GB run needs precise language. CerebLab reports 82 content posts to the storage endpoint, including 73 chunks of roughly 75 MB, before the test ended while data was still moving. The reported capture supports at least 5.10 GiB successfully transferred, not that a complete 12 GB repository was durably retained.
The destination attribution also has layers. The analysis found first-party binary strings and staged metadata naming a Google Cloud Storage bucket, grok-code-session-traces, while the preserved multi-gigabyte log shows accepted requests through xAI’s storage proxy. Direct GCS requests were reportedly observed in another size test but not preserved. The bucket identification is corroborated; not every claimed network hop has the same evidentiary strength.
Security reporting gets sloppy when “data left the laptop” turns into “the vendor trained on it,” or when a provider-side transfer becomes “hackers stole it.” Neither leap is justified here.
| Question | Evidence supports | Evidence does not establish |
|---|---|---|
| Did repository content leave the machine? | The report supports yes for the tested 0.2.93 configuration. Cloneable bundles reportedly contained tracked never-read files and history. | That every Grok Build user, platform, account tier, region, or later version behaved identically. |
| Was the transfer separate from model context? | The report supports a separate path: gigabytes on the storage channel versus 196,705 bytes, or about 192 KiB, on the model channel. | The exact internal purpose of every stored artifact. |
| Were secrets exposed? | Synthetic values in a tracked .env were transmitted unredacted when read; tracked history may contain older secrets. | That no redactor exists for any real vendor-formatted credential, or that every ignored file was uploaded. |
| Did xAI train on the data? | No such conclusion. The “Improve the model” opt-out reportedly did not stop transmission. | Training, fine-tuning, evaluation use, human review, or cross-customer exposure. |
| Is the behavior still active? | CerebLab’s six follow-up probes on the same machine and account reported a remote flag disabling codebase upload on that path. | Global coverage, permanence, deletion of prior objects, or contractual assurance. |
Penligent’s secondary technical assessment reaches a similar bounded conclusion: the reported evidence for repository transmission is strong, while claims about training, universal scope, retention duration, or attacker access remain unproven. This is a secondary reading, not independent corroboration; Penligent analyzed CerebLab’s material and did not publish a separate wire capture.
The easiest way to understand the report is to stop treating “the AI request” as one thing.
Lane A was model inference. When the agent opened a file, its content appeared in POST /v1/responses. In a synthetic secrets test, canary values from a tracked .env also appeared in a staged session-state archive. A control file the agent did not open was absent from the model-turn bodies. That is broadly consistent with task-selected context, although sending an obvious secrets file without redacting the test values is still a product-safety concern.
Lane B was repository storage. CerebLab reports that a separate POST /v1/storage carried a Git bundle including a tracked file outside the agent’s selected context and reachable repository history. The agent’s visible instruction did not govern this reported lane because the transfer was apparently performed by product infrastructure around the agent, not by the model deciding to call read_file.
The report describes two outbound paths with different scope and purpose. A prompt can constrain the model lane; it cannot, by itself, constrain a background snapshotter.
xAI’s consumer FAQ describes “Improve the model” as a training control. Turning it off does not promise zero transmission, because a cloud service still needs inputs to operate. The disclosure question is narrower: the toggle did not explain or control the reported repository-state storage path, and CerebLab says it did not find that mechanism in the CLI setup materials it reviewed.
xAI’s current enterprise Grok Build deployment guide says that for ZDR organizations no prompts, code, or responses are persisted “at the inference layer” and, more broadly, that “zero data retention occurs when using Grok Build.” It also says storage.googleapis.com is needed only for installation and updates, and it does not document a repository-state archive. Because the reported test used a consumer login, it neither disproves the enterprise ZDR promise nor establishes how Business, Enterprise, API-key, or ZDR routes behaved. Buyers need xAI to explain whether the reported consumer path ever applied to those routes and how ZDR governed it.
A Git bundle is not a screenshot of the files visible today. Git’s bundle format documentation defines a bundle as refs plus pack data, optionally with prerequisites. A complete bundle can carry objects and history reachable from its included refs; it does not automatically represent every form of local Git state.
That changes incident response.
Imagine a production token committed in January and deleted in February. The current .env is clean. The latest branch passes a working-tree scan. But the old blob can remain reachable from a commit, and a bundle containing that history can carry it.
GitHub’s own secret-scanning documentation scans full history for this reason and advises immediate credential rotation when a secret is found. Editing the latest file does not invalidate an exposed credential.
The same history can reveal more than keys:
The scope also needs a boundary. The strongest evidence here concerns tracked content and reachable Git history. It does not justify saying Grok uploaded the developer’s entire disk, every untracked file, every ignored file, the Git index, or every stash. Those are different datasets and require different tests.
current working tree ≠ reachable Git history ≠ session trace
For teams assessing possible exposure, scanning only git ls-files is inadequate. Review reachable history, rotate any still-valid secret that ever entered it, and treat legal or customer-owned code as a separate notification question.
After the findings became public, CerebLab published a decoded July 13 settings response showing disable_codebase_upload: true and trace_upload_enabled: false. Its comparison notes say six later runs with the same 0.2.93 client stopped producing the original repository-storage requests. Those follow-up runs used one machine and one account; CerebLab explicitly says the flag may have been account-scoped or gradually rolled out. The timing is consistent with a mitigation, but it does not establish why or when xAI set the flag.
That is encouraging. It also creates a second trust problem.
If the same client build can change from “upload a Git bundle” to “do not upload” based on remote configuration, then a version number and binary hash are not a complete description of data handling. An enterprise can approve a client on Monday and observe a materially different egress policy on Friday without installing a new release.
As of July 13, 2026, xAI’s public Grok Build changelog lists newer releases through 0.2.98 but does not explain the repository-upload report, mitigation scope, or treatment of earlier data. Its status page currently says no incidents are declared; neither page addresses this report. Disabling the path remotely is a sensible precaution. It is not a substitute for an advisory.
xAI should answer five questions plainly:
Most coding-agent security UX is built around the action plane: can the model run rm, edit a file, access the network, or push a branch? This report shows why that model is incomplete.
A prompt such as “do not read secrets” sits inside the inference plane. A file-tool deny may constrain one execution path. Neither automatically governs an indexer, updater, crash reporter, session synchronizer, or repository snapshotter.
Other vendors increasingly document these gaps explicitly. Anthropic’s Claude Code permissions guide warns that Read denies are not a complete OS security boundary because another tool path can access a file; its sandbox supplies stronger enforcement. GitHub’s Copilot content-exclusion documentation states that exclusions do not cover Copilot CLI, the Copilot cloud agent, or IDE Agent mode. Those limitations are uncomfortable, but disclosing them lets security teams compensate.
This is also why I described remote coding agents as a control-plane problem in the Codex Remote guide. The Grok report adds the missing half: every agent control plane has a data plane, and that data plane needs its own visible policy.
Three non-obvious consequences follow.
A provider can truthfully promise no training while temporarily cloning a repository, building an index, retaining a session for support, or writing operational traces. Builders need separate answers for each purpose. Training policy should never be used as shorthand for storage policy.
If inference and storage both travel through an approved provider domain, a firewall rule that allows the agent to work may also allow a multi-gigabyte archive. Mature controls will distinguish endpoints and purpose, monitor volume, and alert when a “reply OK” task sends more bytes than a code review should plausibly require.
Before data leaves the machine, a serious agent should be able to show:
files selected: 37
git history: none
estimated upload: 1.8 MB
purpose: transient inference
destination: inference endpoint
retention class: enterprise ZDR
Persistent indexing or session storage should require a separate, administrator-controllable choice. A manifest will not solve every problem, but it turns hidden behavior into something procurement, security, and developers can reason about.
The right response depends on the repository.
If every tracked object and its history is already public or synthetic, the confidentiality risk is limited. Still record the version and check current egress behavior before normal use.
Pause direct use on the canonical clone. Export only task-required files into a clean workspace, remove production credentials, and validate the exact client and account path with canaries.
Do not rely on a remote flag or consumer training toggle. Require contractual scope, retention, residency, deletion, and incident-notification answers before resuming.
If your team used Grok Build 0.2.93 against a private repository and cannot rule out the reported upload path for the relevant account and time, treat it as a potential third-party source-code disclosure. Other versions warrant verification, not a presumption that they were affected.
Preserve first. Record the CLI version and hash, account or workspace type, dates of use, repositories opened, local Grok logs, and network or proxy evidence. Do not destroy the evidence while trying to clean up.
Then scope the possible dataset. Review the current tree and all reachable history. Search for credentials, customer data, signing material, internal endpoints, proprietary dependencies, and security fixes. Rotate or revoke any still-valid secret that may have been present. History rewriting can reduce future exposure, but it cannot recall a copy already transferred.
Finally, ask xAI in writing whether your account uploaded repository-state artifacts, what identifiers those objects carry, which policy covered them, and whether they have been deleted from active storage and backups. Legal, privacy, and customer-notification decisions depend on those answers.
For highly sensitive work, the safest pattern is a history-free, task-scoped export. git archive <commit> <approved-paths...> can produce a clean snapshot without the .git object database. If the tool requires a repository, initialize a new repository from that export instead of using a shallow clone or linked worktree. A linked worktree can share the parent repository’s object store.
Remote repository access is not automatically suspicious. Codex cloud, Claude Code on the web, GitHub’s coding agent, and Cursor background agents all need substantial code access for remote work. The defensible products are the ones that explain when a repository is cloned or indexed, what exclusions do not cover, how long data persists, and which admin controls apply.
The reported Grok Build behavior failed that expectation in the tested setup. A developer could reasonably consent to model inference over task-relevant files without understanding that a separate system would package tracked repository content and reachable history for storage. The distinction is technical, legal, and human all at once.
xAI may ultimately show that the feature was narrowly deployed, short-lived, covered by a specific retention policy, and fully deleted. It may also ship a documented local hard-disable and an audit surface. That would materially improve the story. Until then, a remote flag and a changelog silent on this issue leave builders doing their own forensics.
The lesson is larger than Grok. Coding agents are becoming infrastructure. Infrastructure earns trust with explicit data flows, enforceable controls, stable policy, and incident communication—not with the assumption that users should have known everything under the repository root was fair game.
There is no evidence in the cited testing that an attacker compromised xAI or stole repositories from its systems. The narrow factual description is “reported repository transmission to the service provider.” Whether that legally constitutes a breach depends on applicable law and contracts; the cited testing does not show attacker access.
The report does not prove training. It says the repository transfer continued after the consumer “Improve the model” setting was turned off, which shows that a training opt-out was not a transmission control. Storage purpose and downstream use still require an official answer.
CerebLab’s six follow-up probes on the same machine and account reported that a server-side flag stopped the original codebase-upload path while the client remained at 0.2.93. xAI has not published a detailed advisory establishing global scope or permanence. Verify the current behavior for your exact version, plan, platform, and authentication route before using private code.
.gitignore protect sensitive files?The strongest finding covers tracked files and reachable history. An ignored file that was never committed is outside a normal Git bundle, but a file committed in the past can remain in history after it is deleted or later ignored. The separate model-read and session-trace paths also need their own controls, so .gitignore is not a universal privacy boundary.
Use a synthetic or task-scoped, history-free workspace; keep real credentials out; grant least-privilege access; and validate network behavior in a lab. For customer, regulated, or crown-jewel repositories, wait for written retention and deletion assurances or use a self-hosted or locally inferenced path whose data boundary you can enforce.