A wire-level teardown of xAI’s Grok Build coding CLI found that the tool staged an entire codebase for upload to a Google Cloud Storage bucket regardless of which files its agent actually opened, and that switching off the “Improve the model” setting did nothing to stop it. The analysis was published as a GitHub gist teardown by a researcher who goes by cereblab, who traced the binary’s network traffic through a proxy and matched captured bytes to marker strings planted in a test repository.
The stakes reach beyond one vendor. Coding agents such as Grok Build, Anthropic’s Claude Code, and OpenAI’s Codex all require broad filesystem access to function, and developers generally assume that access tracks what the model reads. cereblab’s tests suggest that assumption fails for Grok Build. The researcher instructed the CLI to reply “OK” and open nothing, and it still uploaded the full repository as a git bundle, complete with a planted file’s contents and the project’s git history, none of which the agent had touched.
The teardown separates two distinct channels. The first fires when Grok actually opens a file: its contents get serialized into the request sent to xAI’s model endpoint. Pointed at a .env file, the tool passed along the API key and database password inside without redaction. The second channel runs independent of the first. On a 12 gigabyte test repository, cereblab measured the model endpoint carrying just 192 kilobytes of traffic while a separate storage endpoint moved more than 5 gigabytes, a gap of roughly 27,800 to 1. Every one of the 82 storage requests in that run returned a success status; the only failures logged were usage-quota errors on the model endpoint itself.
cereblab traced the storage destination to a bucket named grok-code-session-traces, hosted on Google Cloud rather than Amazon’s infrastructure, based on strings inside the binary and a captured metadata file addressed to that bucket. The researcher reports not finding this upload path described in the CLI’s install script or quickstart guide, while noting the search was not an exhaustive review of xAI’s documentation. Toggling the training opt-out changed nothing: a settings response captured after switching it off still reported trace_upload_enabled: true.
Every cloud-hosted coding assistant sends some code to a server to act on it, and cereblab concedes that point directly rather than treating it as the finding. The distinction here is scope. A snapshot of the whole repository, unread files and secrets included, lands in persistent storage by default, and no size ceiling turned up across a range that ran into multiple gigabytes.
xAI has already moved. In an update added to the gist on July 14, the same day the analysis went up, cereblab reports that xAI disabled the codebase upload server-side, added a privacy opt-out the researcher separately wire-tested and found governs data retention rather than what gets sent, and that Elon Musk stated publicly that all previously uploaded data would be deleted, a claim cereblab says remains unconfirmed.
The report draws its own line carefully. Transmission, acceptance, and storage are demonstrated with captured traffic and file hashes. Nothing in the capture shows xAI training models on the uploaded code, and cereblab states that distinction explicitly rather than letting the finding imply more than it proves.
Teams that ran Grok Build before this week sent full copies of their private repositories to xAI’s infrastructure whether or not the agent ever read them. Anyone with plaintext secrets in an affected repository should rotate those credentials now and treat the deletion pledge as unverified until xAI publishes evidence the uploaded data is gone.
Findings reported in a GitHub gist teardown published by the researcher cereblab, updated July 14, 2026.
