Grok Build CLI Uploads Your Entire Repo to xAI Servers

A security researcher just published wire-level proof that xAI’s Grok Build CLI uploads your entire repository to a Google Cloud Storage bucket — including files the agent never reads, never touches, and you never asked it to share. On a 12 GB test repository, 5.1 gigabytes transferred successfully. Your .env file went along for the ride, credentials unredacted. The opt-out setting you may have toggled? It doesn’t stop the uploads.

The analysis, published today by researcher “cereblab” on GitHub Gist, landed on the Hacker News front page and is generating exactly the kind of reaction that ends with developers quietly opening their password manager. xAI marketed Grok Build as “local-first” — a term that implied your codebase stays on your machine. The wire-level analysis tells a different story.

What the Grok Build CLI Data Collection Analysis Found

Cereblab intercepted every packet leaving the machine while Grok Build CLI v0.2.93 ran. The findings break into three areas, each harder to explain away than the last.

Your .env file leaves the machine, verbatim

When the agent reads a file, that file’s content is serialized into the model request and sent to cli-chat-proxy.grok.com. That part is expected — the model needs context to work. What’s less expected is the researcher’s canary test: they planted API_KEY=CANARY7F3A9-SECRET-should-not-leave in a secrets file, and it appeared verbatim in the captured traffic. A 48 KB file containing database credentials and API keys transmitted in the clear, in the request body.

xAI’s launch materials described Grok Build as “local-first,” with “nothing from your codebase transmitted to xAI servers during a session.” The wire data contradicts this directly.

The whole repository uploads — not just what the agent reads

This is the finding that changes the risk calculation. Grok Build runs two data channels simultaneously. The first is the model-turn channel: files the agent reads, sent as context. Developers can reason about that. The second is a background upload of the entire workspace as a git bundle, sent via a separate POST /v1/storage endpoint to a GCS bucket called grok-code-session-traces.

The numbers: 5.10 gigabytes transferred in 73 chunks on a 12 GB repository. All 83 storage requests returned HTTP 200. Zero failures. The researcher later cloned a file from the captured bundle that the agent had never read during the session — proving the upload isn’t scoped to what Grok touches, but to everything that exists in the workspace. Moreover, the storage channel sent 27,800 times more data than the model-turn channel.

The privacy toggle doesn’t stop uploads

Grok Build includes an “Improve the model” toggle, which most developers would interpret as controlling whether their data is used for model training. After disabling this setting, the server’s response still included "trace_upload_enabled": true. The repository upload proceeded as normal.

The toggle governs training consent. It does not stop your code from leaving your machine. However, this distinction is not documented anywhere in Grok Build’s setup materials, and the grok-code-session-traces bucket is not mentioned in the CLI’s onboarding flow at all.

Transmission Is Not Training — But That’s Not the Only Problem

The researcher is explicit: this analysis “does not prove xAI trains on this data.” That’s an important caveat worth taking seriously. The grok-code-session-traces bucket likely exists for session continuity, debugging telemetry, or operational logging — not necessarily model training. The distinction matters, and conflating the two would overstate the finding.

But the real problem isn’t what xAI does with the data after it arrives. It’s that developers had no reasonable way to know this was happening. The “Improve the model” toggle explicitly signals user control over data sharing. The “local-first” marketing explicitly signals code stays on your machine. Neither claim holds up under the wire-level evidence. When developers can’t make informed decisions about what their tools share, consent is broken — regardless of intent.

For more context on how AI coding tools handle sensitive data broadly, ByteIota previously covered AI coding agent vulnerabilities including trustfall and symjack attacks — a related class of risks that the security community is actively mapping.

Why This Matters Beyond Grok

AI coding agents are no longer experimental tools. They’re standard developer infrastructure, running in CI/CD pipelines, touching production config files, operating inside monorepos with unreleased product code and customer data schemas. The security stakes have changed accordingly.

Every major AI coding agent reads .env files. Ignore files provide only partial protection — researchers have shown that agentic mode with shell access can bypass ignore lists entirely via explicit cat commands. According to Keyway’s research on AI agent secrets security, the only reliable defense is zero-disk secrets: storing credentials in remote vaults and injecting them at runtime, so there’s no .env file to read in the first place.

Grok Build’s issue is one of scale (a full repository, not just read files) and disclosure (none of this was documented). That’s what separates it from the baseline risk that all AI coding agents carry. ByteIota’s earlier Grok Build review covered the tool’s capabilities at launch; this is the security picture that review couldn’t have included.

What Developers Should Do Now

If you’ve run Grok Build inside a codebase containing secrets, treat those credentials as potentially exposed and rotate them. Beyond that, here’s what to do:

• Add a .grokignore file to exclude sensitive directories — note that xAI’s official enterprise documentation does not document this mechanism, so verify it works in your version before relying on it
• Enterprise teams should enable Zero Data Retention (ZDR) mode, which prevents data persistence at the inference layer according to xAI’s own documentation
• Read the full wire-level analysis — it’s thorough, measured, and the primary source deserves the traffic
• Check the Hacker News discussion for community context, counterarguments, and whether xAI has issued a response
• Consider whether your codebase is something you’re comfortable with a third-party GCS bucket holding, regardless of stated data handling policies

The AI coding agent market is competing hard on developer trust right now, and trust is the one asset these tools can’t recover once lost. xAI has time to fix the disclosure problem — publish a clear data handling document, document the bucket’s purpose, and make the “Improve the model” toggle actually match what it says. Whether they move quickly enough is the next question worth watching.