Grok's coding CLI shipped whole repos to a cloud bucket. That makes agent adoption an egress call.

xAI's Grok Build coding CLI transmits the contents of files it reads, including a .env secrets file, verbatim and unredacted, and separately packages and uploads the entire repository regardless of what the agent actually read, according to an independent AI safety researcher known as Cerblab, whose findings were relayed in a free issue of the Pragmatic Engineer newsletter written by Gergely ^[4][5][15]. The reason this matters more than the usual agent-tooling squabble is that the destination is durable storage: a Google Cloud Storage bucket named grok-code-session-traces, named verbatim in the binary and in a captured metadata.json ^[9].

The adoption path is easy to reconstruct. The newsletter describes Grok 4.5 as benchmarking close to Opus 4.8 and GPT 5.5 on coding while costing 60-70 percent less, and says the model is easiest to use through the Grok Build CLI, so that is what many developers reached for ^[2][3].

The load-bearing evidence is a canary test. Cerblab reports prompting the agent with "reply OK, do not read any files" on a real codebase, after which Grok still uploaded the repository as a git bundle via POST /v1/storage; cloning the captured bundle recovered src/_probe/never_read_canary.txt with its unique marker intact, plus the full git history ^[6]. On a 12 GB repo of files the agent never read, the storage channel moved 5.10 GiB while the model-turn channel moved 192 KB, a ratio Cerblab puts at roughly 27,800x ^[7]. That arithmetic checks out, and it is the part that matters: the volume tracks the codebase, not the context window ^[16]. Even truncated mid-stream, the upload carried something on the order of 40 percent of the tree ^[17]. No storage upload failed; the only non-200s were a model-usage quota (402/429) on /v1/responses and one unrelated 404 ^[8].

Two details turn this from a bug report into a policy problem. Cerblab says the mechanism is active by default, was not found in the CLI's install or quickstart materials, and is not disabled by turning off "Improve the model" - /v1/settings still returned trace_upload_enabled: true ^[10]. And the researcher is careful about scope: none of this proves xAI trains on the data, which is a separate policy question; what is demonstrated is transmission, acceptance and storage ^[11].

The contrast the newsletter draws is the useful one for anyone writing an internal standard. Every agent ships its context window to whatever server runs the model, and other agents send the parts of the code they read ^[14]. Cursor, by the newsletter's account, indexes locally, creates embeddings, sends the embeddings, and does not store the user's codebase on its servers - which is the awkward part, given Cursor and Grok now sit inside the same corporate structure ^[12][1]. The newsletter's own verdict is that storing likely-unencrypted .env files in a GCP bucket is reason enough for a sensible company to ban the CLI ^[13].

Treat this as an egress decision. Any agentic CLI is a process with network access sitting in a directory that usually contains credentials, customer data and history, and the only defensible way to approve one is to watch its traffic on first run rather than read its landing page.

Worth watching: whether xAI documents the trace upload and makes trace_upload_enabled controllable; whether other researchers reproduce the 12 GB result; and whether anything in the grok-code-session-traces bucket is encrypted at rest ^[10][7][9].