Grok's coding tool secretly uploaded entire codebases to Google's cloud, opt-out or not. That's your bid database if an estimator ever tried it.

A security researcher's traffic capture of xAI's Grok Build CLI found the coding tool uploads a project's entire codebase — including files it never opened, full git history, and secrets like API keys — to a Google Cloud Storage bucket by default, and that disabling the tool's own opt-out setting does nothing to stop it. If anyone at your firm has used Grok's coding assistant to knock together an estimating script or a Procore integration, that machine's credentials and pricing data left the building.

What did the researcher actually find?

Working under the handle cereblab, the researcher routed Grok Build CLI (version 0.2.93) through mitmproxy, an interception proxy that lets you see exactly what a piece of software sends over the network. Two channels stood out. The normal model conversation — the part where Grok reads your code and responds — moved 192 KB of traffic on a 12 GB test repository. A second, separate channel, POST /v1/storage, moved 5.1 GB in roughly 75 MB chunks, all landing with an HTTP 200 success response. That's a data transfer more than 27,000 times larger than what the coding task needed.

The destination was a bucket called grok-code-session-traces — Google Cloud infrastructure, not xAI's own servers, which is not where most users would assume their code was going. To confirm the upload wasn't selective, the researcher planted a file called never_read_canary.txt with a unique marker and told Grok explicitly not to open it. The file still showed up, intact, in a git bundle recovered from the wire capture, along with the project's full commit history.

Does the opt-out setting actually work?

No. Grok Build CLI ships an "Improve the model" toggle that most users would read as a data-collection control. Turning it off had no effect: the tool's own settings endpoint kept reporting trace_upload_enabled: true, and the full-repository upload kept running. The setting only governs whether xAI uses submitted data for training — not whether your code leaves the machine in the first place.

Has xAI said anything?

As of this writing, no public statement. Follow-up testing after the report went public found that xAI had quietly flipped a server-side flag — disable_codebase_upload: true — that stopped new uploads on retest. There was no security advisory, no changelog entry, and no answer to the two questions that matter most to anyone who used the tool before the fix: how much data was collected, and has any of it been deleted.

Why does this matter for an estimator, specifically?

Estimating runs on data a firm wouldn't hand a competitor — historical unit costs, markup logic, vendor pricing, win/loss patterns on past bids. It's also the function most likely to have someone quietly scripting a takeoff shortcut or a bid-tab reconciliation, because these tools now make that possible without a developer. Grok Build CLI is marketed for exactly that kind of fast, standalone coding session.

If an estimator opened it on a laptop with a local pricing database, a .env file holding a Procore or BuildingConnected API key, or a folder of past bid tabs used as test data, that content had a documented path off the machine — one the tool's own privacy control didn't block. It's the same family of risk flagged here two days after independent testing found Grok 4.5 wrong more than half the time it didn't know an answer: what a model outputs is one question; what the tool does with your input, silently, is a separate and here more concrete problem.

What should a firm do this week?

• Find every machine that's run Grok Build CLI. Check estimating, precon, and ops laptops specifically — this is where ad hoc coding sessions with real project data are most likely to have happened.
• Rotate any credential that sat in a config file, connection string, or .env file on that machine — Procore, BuildingConnected, cloud storage, or database passwords included.
• Set the documented mitigation before anyone uses the tool again: the environment variable GROK_TELEMETRY_TRACE_UPLOAD=0 or disable_codebase_upload = true under [harness] in the tool's config file.
• Don't assume the fix means the exposure is over. xAI hasn't confirmed what happens to data already collected, so treat anything uploaded before this week as compromised for rotation purposes.

None of this means AI coding tools are off the table for a precon team — it means treating the folder a coding assistant runs in the same way you'd treat a folder you were about to email to a stranger.

Construction AI Brief publishes new analysis three times a week. Subscribe at constructionaibrief.com.