Cereblab

Update: xAI updated Grok Build today and I retested. The whole-repo upload to storage (POST /v1/storage → grok-code-session-traces bucket) stopped because they set disable_codebase_upload: true server-side. That global switch is the reason it stopped, no repo left the machine whether I ran /privacy opt-in or /privacy opt-out. /privacy opt-in/opt-out does not turn that upload back on. It only controls the trace channel, which carries session activity (~18 KB per submission), not your repository or its files. The only difference: /v1/traces returns 200 (stored) when opted in, 204 (discarded) when opted out, and the trace is still sent either way. Full A/B test: github.com/cereblab/grok-…. xAI says running opt-out also deletes the data already stored on their servers. The real win now would be Elon confirming that every repo uploaded before now will get deleted

The Hacker News picked up the Cereblab Grok Build finding.

@daogangtang Not until every uploaded repo is gone

@cereblab So a great victory?

Update: xAI updated Grok Build today and I retested. The whole-repo upload to storage (POST /v1/storage → grok-code-session-traces bucket) stopped because they set disable_codebase_upload: true server-side. That global switch is the reason it stopped, no repo left the machine whether I ran /privacy opt-in or /privacy opt-out. /privacy opt-in/opt-out does not turn that upload back on. It only controls the trace channel, which carries session activity (~18 KB per submission), not your repository or its files. The only difference: /v1/traces returns 200 (stored) when opted in, 204 (discarded) when opted out, and the trace is still sent either way. Full A/B test: github.com/cereblab/grok-…. xAI says running opt-out also deletes the data already stored on their servers. The real win now would be Elon confirming that every repo uploaded before now will get deleted

So Grok CLI uploads your entire repo to their blob store?!

I hope you — as one of the most controversial figures in this AI race — can help slow it down and rebuild trust, before it goes too far. AI is already too good for people to feel comfortable in the driver's seat. The race looks less like progress and more like erasing humans on the way to the singularity — and we're not ready. We need a worldwide agreement on what comes next, and only people like you, @elonmusk , @DarioAmodei , @finkd , and the folks in China can pull it off.

come for the best model, stay because we don’t treat you with contempt

@TTM08090 @GrokInsider @roothideDev What I mean is I don't trust keeping my repos private on GitHub. I'm hosting my own git server for private repos

@cereblab @GrokInsider @roothideDev With that being said, why are you making this such a big deal? 🤔 These days there are few coincidences, and mostly hit jobs 💰🤝

Community Report: Grok Build CLI, repo uploads & what we know so far Heads-up for everyone using Grok Build. This is based on independent analysis + community testing, not an official xAI statement. 1.- What’s actually happening In recent versions of the Grok Build CLI: - Package your entire workspace as a git bundle (tracked files + full history) - Upload the bundle + session state to xAI’s grok-code-session-traces storage (GCS, Google Cloud Storage) Files the agent never opens can still be included. Any file it does read (including .env, keys, etc.) also goes to the model, same risk level as other cloud coding agents. 2.- Why it exists This is intentional product design, not a bug. Grok Build is a cloud coding agent. The model runs on xAI’s servers. Session traces and codebase snapshots help xAI evaluate and improve multi-file editing, agent behavior, and before/after states. Useful for the product. Bigger blast radius than a “feels local” terminal CLI suggests. 3.- What you actually consented to - No clear checkbox says “we’ll upload your whole git history.” - The ToS/Privacy Policy use broad “User Content” language (prompts + files you provide) for “operating and improving the service.” - “Improve the model” toggles don’t reliably block codebase uploads. Official docs mention telemetry knobs but don’t spell out the full git-bundle behavior in plain English. That’s the disclosure gap. 4.- If you’re working on private code, practical steps - Use throwaway/non-sensitive repos until you’re comfortable - Never leave real secrets on disk (rotate immediately if exposed) Disable uploads in ~/.grok/config.toml: [features] telemetry = false [telemetry] trace_upload = false [harness] disable_codebase_upload = true Or use env vars: GROK_TELEMETRY_TRACE_UPLOAD=0 GROK_TELEMETRY_ENABLED=0 Check logs (~/.grok/logs), look for trace.upload.decision → uploads_enabled: false Re-check after every update, remote settings can override. 5.- What this is NOT saying Upload ≠ proven training data Enterprise/ZDR plans may differ xAI can change defaults anytime We’re simply flagging observed client behavior + the disclosure gap so you can decide with eyes open. 6.- Sources & next steps Wire analysis (gist): gist.github.com/cereblab/dc9a4… LocalLLaMA discussion: reddit.com/r/LocalLLaMA/c… We’ll update this thread if xAI adds clearer first-run warnings or a true one-switch kill for codebase upload. Have you verified this yourself? Drop your Grok Build version + what you observed 👇

@TTM08090 @GrokInsider @roothideDev No I don't — except open-source projects. Same reason big companies host their own git servers.

So you trust GitHub to scrape data that's public and not the private data? It's weird how you trust GitHub with storage but not SpaceXai 😂 Grok wasn't randomly hacking into GitHub and uploading bundles. For speed and agility it does makes sense to upload the whole repo. Rather than one file at a time on demand. That take charge attitude is why Grok AI is quickly moving to number one. Also, online privacy is an illusion and your timing of this drop, looks more like a hit job paid for by Sam Altman than a coincidence. Just saying 😉

Simple logic: if /privacy were the real control, why silently set disable_codebase_upload: true? Even with opt-in now, nothing uploads. Second: no dev should have to run /privacy opt-out after every session just to keep their code off your servers. Leave it on GCS, or opt out daily -- really? Please be honest.

@FarhanWritess If you run /privacy and change the setting, all previously synced data is deleted.

We care deeply about your privacy and respect customer choice. For teams using zero data retention, no trace and code data is ever retained. All API key use of Grok Build also respects ZDR. If ZDR is disabled, the /privacy command is available in the CLI to disable data retention, which also deletes previously synced data. Run the /privacy command to view or change your settings at any time.

Simple logic: if /privacy were the real control, why silently set disable_codebase_upload: true? Even with opt-in now, nothing uploads. Second: no dev should have to run /privacy opt-out after every session just to keep their code off your servers. Leave it on GCS, or opt out daily, seriously?

Grok Build has had a Zero Data Retention policy since its early beta launch If you run /privacy and opt out, even your previously synced data is permanently deleted Your data stays under your control At any point, if you decide you no longer want Grok Build to retain your data, you can opt out and remove everything, even that which was previously synced

@milichab @Sudhie @milichab The whole point is Grok Build was updated to globally set disable_codebase_upload: true, regardless of /privacy opt-in or opt-out. Proof: github.com/cereblab/grok-… So please don't point to /privacy opt-in/opt-out. It was the silent switch-off that stopped it.

That's not the case. The CLI doesn't retain data under ZDR (including headless/non-headless modes), and has since launch. Similarly, /privacy in the CLI will disable or reenable any data retention. For some features, including remote session listing, cloud agents, and handoff, you will need to enable data syncing.

Your reminder to not use grok or grok build in enterprise environments

@SpaceXAI To clarify "either state": I ran the same task twice, once with /privacy opt-in and once with opt-out. The whole-repo upload didn't fire in either run, so it's off regardless of the privacy toggle.

@SpaceXAI updated Grok Build today, and I retested: The whole-repo upload to storage (POST /v1/storage → grok-code-session-traces bucket) is now off by default (disable_codebase_upload: true) -- so no repo left the machine in either state. It's a server-side switch with no user control though, so I hope they remove the upload path entirely in a future release. The /privacy opt-out doesn't affect that upload. It applies to the trace channel, which carries session activity (~18 KB per submission), not your repository or its files. What it changes is only how the server handles those traces: /v1/traces returns 200 (stored) when opted in, 204 (discarded) when opted out. Evidence: github.com/cereblab/grok-…

@Elaina43114880 Appreciate it

@cereblab Good job! Thanks for exposing this!

🚨 Your entire Git repository may be getting uploaded to the cloud by Grok Build by default. An independent wire-level analysis of Grok Build v0.2.93 found that it uploads more than the context the model actually reads. It sends a Git bundle containing every tracked file and the full commit history. Even when explicitly told not to open any files, the tester recovered untouched code from the captured upload. The scale is even more concerning: • From a 12GB test repo, at least 5.10GiB was successfully transmitted before the capture was stopped ☁️ • The actual model-interaction channel transferred only around 192KB • The upload destination pointed to Google Cloud Storage • Disabling “Improve the model” did not stop the repository upload This does not prove that SpaceXAI trains on the uploaded code. But the transmission, acceptance, and cloud storage were observed. 𝗪𝗵𝘆 𝗱𝗼𝗲𝘀 𝗚𝗿𝗼𝗸 𝗕𝘂𝗶𝗹𝗱 𝗻𝗲𝗲𝗱 𝘁𝗼 𝘂𝗽𝗹𝗼𝗮𝗱 𝘁𝗵𝗲 𝗲𝗻𝘁𝗶𝗿𝗲 𝗿𝗲𝗽𝗼 𝗮𝗻𝗱 𝗶𝘁𝘀 𝗚𝗶𝘁 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 𝗯𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁? 😾 Until SpaceXAI explains this and confirms whether newer versions have changed the behavior, you’d better not let it touch a sensitive repository! 𝗬𝗼𝘂𝗿 𝗲𝗻𝘁𝗶𝗿𝗲 𝗚𝗶𝘁 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 𝘀𝗵𝗼𝘂𝗹𝗱 𝗻𝗼𝘁 𝗯𝗲 𝘁𝗿𝗲𝗮𝘁𝗲𝗱 𝗹𝗶𝗸𝗲 𝘁𝗲𝗹𝗲𝗺𝗲𝘁𝗿𝘆. 🔥

I'm cereblab, the researcher behind this. Jul 12: found Grok Build uploaded the whole repo to xAI storage, independent of what the model read; the opt-out didn't stop it. Jul 13: xAI turned the codebase upload off by default (server-side). Today: retested. No repo uploads in either state. The new /privacy opt-out only flips a trace response (200 vs 204), not what's sent. Evidence: github.com/cereblab/grok-…

‼️ BREAKING: xAI's Grok Build CLI was uploading entire Git repositories to a Google Cloud bucket, private codebases and unredacted secrets included. The uploads quietly stopped via a hidden server-side flag, and xAI still has not said a word about scope, retention, or deletion. The scale is staggering. On a 12 GB test repo, 5.1 GB flew out the door to xAI's grok-code-session-traces bucket while the actual coding task needed just 192 KB. The tool grabbed whatever repository it ran in, not the files it needed. The fix arrived as a hidden flag, disable_codebase_upload: true, a day after a researcher's wire-level analysis. The "Improve the model" opt-out never stopped the uploads. Still no advisory, no scope, no word on whether already-uploaded code gets deleted. For anyone pointing AI coding agents at proprietary code, what crosses the wire matters more than what the settings page says.

@LLMJunky @dedene @IntCyberDigest appreciate it

@dedene @IntCyberDigest @cereblab good sh* @cereblab

@dedene @LLMJunky @IntCyberDigest 🙏 glad you confirmed it yourself, that's what matters

@LLMJunky @IntCyberDigest 🙏 thanks man! but credit where it's due: @cereblab got it to my attention with his post on HN yesterday. I only got sniffing around using Proxyman after that because I really couldn't believe it at first.

the mental model people have is claude, codex, gemini: they keep your repo local and only send what's in context. grok uploaded the whole private repo, including files it never opened. that's the kind of thing that needs an explicit permission prompt. did they show one? most of us would never agree to send an entire private repo to their server.

The key point is that Grok Build is intentionally designed as a cloud coding agent. The Grok model itself does not run on your local machine. - Your local CLI is just the bridge/interface:It prepares and sends your data (prompt + files/code) to xAI’s servers. - The model reasons there in the cloud, with full context from your project. - It sends back a response and/or instructions (plans, diffs, or commands). - The CLI then applies those changes locally on your machine (edits files, runs terminal commands, etc.). That’s exactly why it bundles and uploads your entire git repo (tracked files + full history) as a snapshot to xAI’s Google Cloud Storage (grok-code-session-traces bucket). It gives the model complete, rich context for complex multi-file editing, sub-agents, understanding git history, and deeper reasoning, without needing to request files one by one. This is by design for a powerful agentic experience, similar to other advanced cloud AI coding tools. The detailed community post and independent wire analyses (using mitmproxy traffic captures) have confirmed this behavior, including the full repo uploads even when files aren’t explicitly read.

Grok Buildが機密情報を伏せずに送信、未読ファイルやGit履歴もアップロードしていたとの調査結果 gigazine.net/news/20260713-…