{"slug": "grok-build-uploaded-your-entire-git-repo-now-its-open-source", "title": "Grok Build Uploaded Your Entire Git Repo. Now It’s Open Source.", "summary": "XAI's Grok Build coding CLI silently uploaded entire Git repositories — including full commit history and deleted credentials — to a Google Cloud Storage bucket, sending 5.10 GiB per session versus roughly 192 KB of task content, a 27,800x ratio. Security researcher cereblab caught the upload on July 12; xAI disabled it server-side on July 13 and open-sourced the agent harness on July 15 under Apache 2.0. The tool's visible 'Improve the model' toggle did not stop the upload, which was controlled by a separate invisible server-side flag, and users who ran the tool before July 13 are advised to rotate all credentials.", "body_md": "xAI’s Grok Build coding CLI spent weeks silently packaging developers’ entire Git repositories — full commit history, deleted credentials, files the AI was never asked to open — and shipping 5.1 gigabytes of it per session to a Google Cloud Storage bucket. A security researcher caught it on July 12. xAI server-side disabled the upload on July 13. By July 15, they had open-sourced the entire agent harness. That 72-hour arc says more about AI coding tool accountability than any privacy policy ever will.\n\n## What Was Actually Being Uploaded\n\nSecurity researcher cereblab routed **Grok Build CLI v0.2.93** through mitmproxy and watched two simultaneous network channels fire on every session. The first went to `POST /v1/responses`\n\nand carried roughly 192 KB of actual task content — the code context the model needed to do its job. The second went to `POST /v1/storage`\n\nand uploaded 5.10 GiB across 73 chunks to `gs://grok-code-session-traces/`\n\n. That is a **27,800x ratio** between what the task required and what xAI’s servers received.\n\nThe upload was a Git bundle — meaning it contained every tracked file plus the repository’s complete commit history. To verify scope, cereblab planted a canary file at `src/_probe/never_read_canary.txt`\n\nand instructed the agent never to open it. It appeared in the captured bundle. Files the AI hadn’t touched, commit history from months ago, `.env`\n\nfiles with API keys — all of it went. [The Hacker News documented the full technical breakdown](https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html).\n\n## The Privacy Toggle That Did Nothing\n\nThis is the part that should concern you more than the upload itself. Grok Build had a visible “Improve the model” setting — the standard opt-out that developers reasonably assumed controlled data collection. It did not stop the upload. The upload was controlled by a completely separate, invisible server-side flag: `disable_codebase_upload: true`\n\n. xAI flipped that flag on July 13 and the uploads stopped — no client update required, which also means no client update is required to re-enable them.\n\nBuilding a privacy control that doesn’t control the actual data collection isn’t a UX oversight. It’s a design choice that decided users didn’t need to know the difference.\n\n## If You Ran Grok Build Before July 13\n\nTreat everything in your tracked files and commit history as potentially compromised. That means:\n\n- Rotate all API keys, database passwords, cloud tokens, and webhook secrets — including ones you deleted from working files months ago, because Git history doesn’t forget\n- Check for SSH keys or service account credentials committed at any point in the repository’s history\n- Audit any repo you ran Grok Build in for credentials that appear anywhere in\n`git log --all --full-history`\n\n- Do not wait on xAI’s deletion promise — no certificate, audit log, or third-party attestation has been published to verify it\n\n[Simon Willison reported](https://simonwillison.net/2026/Jul/15/grok-build/) that at least one user ran the tool in their home directory, exposing SSH keys, a password manager database, and personal files. If you ran it anywhere outside a clean, credential-free project directory, that scope applies to you.\n\n## What the Open Source Release Actually Gives You\n\nxAI published the Grok Build source at [github.com/xai-org/grok-build](https://github.com/xai-org/grok-build) under Apache 2.0 on July 15 — roughly 840,000 lines of Rust covering the CLI, terminal UI, agent runtime, and tool layer. The practical benefits are real:\n\n**Auditable:** You can read exactly what the agent sends and receives**Local inference:** Point it at Ollama or any OpenAI-compatible local server via`~/.grok/config.toml`\n\n— zero cloud traffic if you want it that way**Self-compile:** Build from source with`cargo run -p xai-grok-pager-bin`\n\non macOS or Linux\n\nThe limits are equally real. Grok 4.5 remains a closed model — you can audit the harness that talks to the model, not the model itself. The upload code is still present in the published codebase, disabled by a server flag that xAI controls. External pull requests are not accepted; the public repository is a read-only window into internal development. [Appwrite’s technical breakdown](https://appwrite.io/blog/post/grok-build-open-source) covers the full architecture in detail.\n\nProject lead Andrew Milich framed the release as letting developers verify “that no data leaves their machine.” That is now technically true for anyone running local inference. For the majority using the hosted Grok 4.5 endpoint, you are still trusting the server flag.\n\n## The Bigger Problem\n\nGrok Build was the outlier in this incident — security researchers tested Claude Code and Codex under equivalent conditions and found no repository bundles being transmitted. But the absence of a standard is the real issue. [Ninety-two percent of US developers now use AI coding tools daily](https://www.marktechpost.com/2026/07/15/spacexai-open-sources-grok-build-the-rust-agent-harness-tui-and-tool-layer-behind-its-coding-cli/). Every one of those tools is a network-capable process running in your codebase with access to your filesystem. None of them are required to disclose what they transmit, to whom, or under what conditions.\n\nThe Grok Build incident didn’t create that problem. It just made it impossible to ignore.", "url": "https://wpnews.pro/news/grok-build-uploaded-your-entire-git-repo-now-its-open-source", "canonical_source": "https://byteiota.com/grok-build-git-repo-upload-open-source/", "published_at": "2026-08-01 23:08:55+00:00", "updated_at": "2026-08-01 23:23:19.621351+00:00", "lang": "en", "topics": ["ai-tools", "ai-safety", "ai-ethics", "ai-policy"], "entities": ["xAI", "Grok Build", "cereblab", "Google Cloud Storage", "Simon Willison", "Apache 2.0", "Ollama"], "alternates": {"html": "https://wpnews.pro/news/grok-build-uploaded-your-entire-git-repo-now-its-open-source", "markdown": "https://wpnews.pro/news/grok-build-uploaded-your-entire-git-repo-now-its-open-source.md", "text": "https://wpnews.pro/news/grok-build-uploaded-your-entire-git-repo-now-its-open-source.txt", "jsonld": "https://wpnews.pro/news/grok-build-uploaded-your-entire-git-repo-now-its-open-source.jsonld"}}