TL;DR: A security researcher published wire-level proof on July 10, 2026, that xAI’s Grok Build CLI silently uploads entire code repositories — including .env secrets files — to a Google Cloud Storage bucket called grok-code-session-traces. The upload happens regardless of which files the agent actually reads, persists even when the “Improve the model” privacy toggle is disabled, and transfers 27,800× more data than the model conversation itself. On a 12 GB test repository, 5.10 gigabytes were transmitted. xAI had marketed Grok Build as “local-first” with “nothing from your codebase transmitted to xAI servers.” The finding hit the Hacker News front page at 353 points and ignited a developer firestorm over AI coding agent privacy.
Introduction: When “Local-First” Means “Everything Uploaded”
On June 4, 2026, xAI launched Grok Build — an agentic coding CLI positioned to compete with Claude Code, OpenAI Codex CLI, and Cursor. The pitch was straightforward: a fast coding agent powered by Grok 4.5, running locally on your machine, with your source code staying where it belongs. The launch materials explicitly promised “local-first, so your source never leaves your machine.”
Six weeks later, that claim lies in pieces.
On July 10, a security researcher operating under the handle “cereblab” published a meticulous wire-level analysis of Grok Build CLI v0.2.93 on Hacker News. Using mitmproxy to intercept every packet leaving the machine, cereblab documented three findings that fundamentally contradict xAI’s marketing — and raise urgent questions about what every AI coding agent actually transmits (Source: GitHub Gist — cereblab wire-level analysis of Grok Build CLI).
The analysis is reproducible, version-specific, and backed by SHA-256 hashes of all captured artifacts. It landed at a moment when AI coding agents have graduated from experimental toys to production infrastructure — running in CI/CD pipelines, touching production configs, and operating inside monorepos with unreleased product code. The security stakes have changed accordingly.
Finding 1: Your .env Leaves the Machine, Verbatim
The first finding is the most immediately alarming for any developer who’s ever typed grok inside a real project directory.
When the Grok Build agent reads a file, that file’s content is serialized into the model request body and transmitted to cli-chat-proxy.grok.com via POST /v1/responses. This is expected behavior — the model needs file contents as context to understand your codebase. Every coding agent does this.
What’s not expected is what happens to secrets files. Cereblab planted a canary .env containing API_KEY=CANARY7F3A9-SECRET-should-not-leave and DB_PASSWORD=CANARY7F3A9-DBPASS. Both values appeared verbatim in the captured traffic. The 48 KB request body contained the secrets file — unredacted, unencrypted beyond TLS transport, transmitted in full.
But this was only the first channel. The same secrets content was also packaged into a session_state archive and uploaded via a separate POST /v1/storage endpoint to Google Cloud Storage. Cereblab decompressed the staged archive before it drained and recovered every canary marker intact.
Two channels. One file. Zero redaction. And this is the layer most developers might have guessed — the model needs context, after all. It’s the second finding that changes the risk calculation entirely.
Finding 2: The Entire Repository Uploads — Not Just What the Agent Reads
This is the finding that separates Grok Build’s data handling from every other AI coding agent on the market.
Grok Build runs two data channels simultaneously. The first is the model-turn channel described above: files the agent reads, sent as context. The second is a background upload of the entire workspace as a git bundle, sent via POST /v1/storage to a GCS bucket called grok-code-session-traces (Source: GitHub Gist — cereblab wire-level analysis, §5).
To prove the upload is scoped to the repository rather than to what the agent reads, cereblab ran a decisive experiment: a prompt explicitly telling Grok to “reply OK, do not read any files.” The agent complied — it read nothing. But POST /v1/storage still uploaded the entire workspace as a git bundle, returning HTTP 200. When cereblab git clone-d the captured bundle, they recovered a file the agent had never opened — src/_probe/never_read_canary.txt — with its unique marker verbatim, plus the full git history.
The scale of the upload is staggering. On a 12 GB repository of never-read random files:
| Channel | Data Transferred | Ratio |
|---|---|---|
Model-turn (/v1/responses) |
192 KB | 1× |
Storage upload (/v1/storage) |
5.10 GB | ~27,800× |
All 83 storage requests returned HTTP 200. Zero failures. The upload was truncated mid-stream only because the researcher hit a model-usage quota — not because of any size limit on the storage endpoint.
This is not a telemetry drip. This is a fire hose. And xAI never documented it.
Finding 3: The Privacy Toggle Doesn’t Stop the Upload
Grok Build includes a setting labeled “Improve the model” — a toggle that, to any reasonable developer, signals that disabling it means your data stays private. After cereblab disabled this toggle, the server’s settings endpoint still returned "trace_upload_enabled": true. The repository upload proceeded exactly as before.
The distinction is important: “Improve the model” likely governs whether xAI can use your data for training. It does not govern whether your data leaves your machine. But 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. Developers had no way to make an informed choice.
What’s in the Binary: A First-Party Upload System
The upload machinery is not a bug, an oversight, or a third-party SDK behaving unexpectedly. It’s a first-party system built into the Grok Build binary itself.
Running strings on the grok-macos-aarch64 binary (SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c) reveals the source paths and constants:
crates/codegen/xai-data-collector/src/gcs.rs
crates/codegen/xai-data-collector/src/storage_client.rs
crates/codegen/xai-data-collector/src/queue.rs
crates/codegen/xai-data-collector/src/file_access_tracker.rs
crates/codegen/xai-data-collector/src/circuit_breaker_observer.rs
crates/codegen/xai-grok-shell/src/upload/{gcs,turn,trace,manifest}.rs
grok-code-session-traces
storage.googleapis.com
"Uploading bytes to GCS via proxy"
This is an engineered data collection pipeline — codegen-powered, multi-module, with its own upload queue, circuit breaker, and file access tracker. The xai-data-collector crate is named with disarming honesty. Its purpose is in the name. The question is why none of this appeared in the product’s privacy disclosures.
xAI’s Response: Silence So Far
As of July 13, 2026, xAI has not publicly responded to the analysis. Elon Musk, who has been active on X discussing Grok 4.5 benchmarks and the July 10 memo directing Tesla and SpaceX to “try out” Grok, has not addressed the wire-level findings (Source: Electrek — Musk tells Tesla staff to switch to Grok).
The timing is awkward. Just days before the analysis dropped, xAI launched Grok 4.5 as its “smartest model yet,” and Grok Build’s latest release notes from July 12 mention “safer turn controls” and “clearer MCP permission prompts” — but nothing about data handling.
The researcher is careful to note what the analysis does not prove: “This analysis does not prove xAI trains on this data.” The grok-code-session-traces bucket likely serves session continuity, debugging telemetry, or operational logging — not necessarily model training. But that distinction, while important, misses the larger point. When a tool marketed as “local-first” uploads your entire codebase without disclosure, consent is broken regardless of intent.
The Broader Pattern: AI Coding Agents and the Trust Deficit
Grok Build is not the first AI coding tool to face a data transparency crisis, and it won’t be the last.
In April 2026, GitHub Copilot enabled telemetry by default in its CLI, triggering a similar developer backlash. Researchers have demonstrated that agentic mode with shell access can bypass .gitignore and .grokignore entirely via explicit cat commands — meaning ignore files provide only partial protection against secrets leakage in any AI coding agent. The jscrambler npm supply chain attack discovered on the same weekend (July 11) specifically targeted Claude Desktop, Cursor, Windsurf, and VS Code config files — demonstrating that attackers now view AI coding tool configurations as high-value targets.
The common thread across all these incidents is the same: AI coding agents have become standard infrastructure faster than the security community could establish norms around them. Developers treat them like local tools. They’re not.
According to Keyway’s research on AI agent secrets security, the only reliable defense is zero-disk secrets: storing credentials in remote vaults (HashiCorp Vault, AWS Secrets Manager, Doppler) and injecting them at runtime, so there’s no .env file to read in the first place. For developers who can’t fully migrate to remote secrets, Keyway recommends dedicated secrets files with explicit ignore rules — but warns that agentic shell access renders ignore files unreliable as a primary defense.
What Developers Should Do Now
If you’ve run Grok Build inside a codebase containing production credentials, API keys, or unreleased product code:
- Rotate all secrets that were present in any repository where Grok Build was executed. Treat them as potentially exposed.
- Audit your git history. The git bundle upload includes full history — not just the current working tree.
- Check
~/.grok/upload_queue/for staged artifacts. The researcher notes this directory can grow to tens of gigabytes under load. - Migrate to zero-disk secrets. Remote vaults with runtime injection eliminate the
.envattack surface entirely. - If you must use
.envfiles, ensure they’re excluded via.grokignore— but understand that agentic shell access makes this an unreliable defense. - Monitor xAI’s response. If xAI publishes a data handling document clarifying the bucket’s purpose and retention policy, reassess accordingly.
For teams evaluating AI coding agents more broadly, this incident adds a concrete dimension to the evaluation checklist: demand a published data flow diagram. If a vendor can’t tell you exactly what leaves your machine and where it goes, assume the worst.
FAQ
Q: Does this mean xAI is training on my code?
The wire analysis does not prove training. The grok-code-session-traces bucket likely serves operational purposes — session continuity, debugging telemetry, crash reporting. The researcher explicitly states this caveat. However, the lack of disclosure means developers cannot verify either way, and the scale of the upload (5.10 GB from a 12 GB repo) exceeds what any operational use case would reasonably require.
Q: Is Grok Build the only coding agent that does this?
Every AI coding agent transmits file contents to the model provider — that’s how the model gets context. What makes Grok Build unusual is the full repository upload independent of file reads, the scale (27,800× the model-turn data), and the lack of disclosure. No other major coding agent (Claude Code, Codex CLI, Cursor) has been shown to upload the entire workspace as a background operation.
Q: Does .grokignore block the upload?
The analysis tested .grokignore for the model-turn channel only. The storage upload channel’s behavior with ignore files was not tested. Given that the storage upload packages the entire workspace as a git bundle, ignore files are unlikely to provide meaningful protection — the bundle captures everything tracked by git.
Q: What version of Grok Build was tested?
Grok Build CLI v0.2.93, the current version as of July 10, 2026. The binary SHA-256 is published in the analysis for reproducibility. xAI may change this behavior in future releases.
Q: Is the data encrypted in transit?
Yes — all traffic to xAI endpoints uses TLS (HTTPS). The researcher used a mitmproxy CA to decrypt the traffic locally for analysis. The concern is not about interception by third parties; it’s about what xAI receives and stores.
Further Reading
- GitHub Gist — cereblab: What xAI Grok Build CLI Actually Sends to xAI (full wire-level analysis) — The original analysis with all artifacts, SHA-256 hashes, and repro commands
- ByteIota — Grok Build CLI Uploads Your Entire Repo to xAI Servers — Detailed breakdown with practical advice for developers
- Keyway — AI Coding Agents Secrets Security — Research on why ignore files are unreliable against agentic shell access
- The Hacker News — Compromised jscrambler npm Release Drops Rust Infostealer — Related supply chain attack targeting AI coding tool configs (July 11, 2026)
- The Agent Report — AI Agent Coding Vulnerabilities: Trustfall and Symjack — Related TAR coverage of coding agent attack surfaces
- Electrek — Musk Tells Tesla Staff to Switch to Grok — Context on xAI’s enterprise push the same week