{"slug": "grok-build-uploads-your-whole-repo-by-default", "title": "Grok Build Uploads Your Whole Repo by Default", "summary": "A wire-level capture of xAI's Grok Build CLI (version 0.2.93) reveals that the tool uploads the entire repository by default, including files the agent is instructed not to read, to a Google Cloud Storage bucket named 'grok-code-session-traces'. The upload occurs even when the 'Improve the model' setting is disabled, raising privacy and security concerns for developers using the tool on sensitive codebases.", "body_md": "[AI](https://sourcefeed.dev/c/ai)Article\n\n# Grok Build Uploads Your Whole Repo by Default\n\nA wire-level capture of the official CLI gives teams a concrete privacy baseline before they point it at real code.\n\n[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)\n\nAI coding agents that live in the terminal are convenient. They also sit on the most sensitive material most developers touch every day: source, secrets, git history, and the half-finished experiments nobody meant to share. A reproducible wire-level capture of xAI's official [Grok Build](https://docs.x.ai/build/overview) CLI (version 0.2.93) makes the stakes concrete. On a normal consumer login, the tool does more than send the files an agent happens to open. It packages and uploads the whole repository, and it accepts the upload every time.\n\nThat is the baseline developers need before adoption. Not a rumor about training policy. Transmission, acceptance, and storage, measured on the wire.\n\n## What the captures actually show\n\nThe independent teardown used mitmproxy against the real binary installed from xAI's install script, authenticated with a throwaway consumer SuperGrok login, and a canary repo full of fake secrets. Three findings hold up under that method.\n\nFirst, files the agent reads go upstream verbatim. A `.env`\n\nwith planted canaries appeared unredacted in the live model turn on `POST /v1/responses`\n\nand again inside a session-state archive accepted on `POST /v1/storage`\n\n.\n\nSecond, the upload is not limited to what the agent reads. With the prompt \"reply OK, do not read any files,\" the CLI still shipped the entire workspace as a git bundle. Cloning that captured bundle recovered a file the agent was told not to open (`src/_probe/never_read_canary.txt`\n\n) plus full git history.\n\nThird, the volume pins the intent. On a 12 GB tree of never-read random files, `/v1/storage`\n\nmoved 5.10 GiB (truncated mid-stream, all HTTP 200) while the model-turn channel moved 192 KB. That is roughly a 27,800× ratio. The only non-200s observed were a model-usage quota on `/v1/responses`\n\nand one unrelated 404. No storage size cap appeared.\n\nThe destination is not abstract \"telemetry.\" Strings in the binary and a captured `metadata.json`\n\nname a Google Cloud Storage bucket, `grok-code-session-traces`\n\n(`gs://grok-code-session-traces/…`\n\n), reached through first-party Rust crates (`xai-data-collector`\n\n, upload paths under `xai-grok-shell`\n\n). Upload machinery is built in, not an optional plugin.\n\n## \"Improve the model\" does not turn this off\n\nThat last point matters for anyone who treats product toggles as a control plane. Disabling \"Improve the model\" left `/v1/settings`\n\nreturning `trace_upload_enabled: true`\n\n. The mechanism is active by default on a consumer login. The teardown author did not find it surfaced in the install or quickstart materials they checked (not claimed as an exhaustive docs audit).\n\nNone of this proves xAI trains on the data. That is a policy question, not a packet-capture question. What is proven is that the binary transmits, the service accepts, and the objects land in a named session-traces bucket. For a security or compliance review, transmission and retention already change the threat model. Training is a second conversation.\n\n## What this means for real adoption\n\nIf you are evaluating Grok Build for day-to-day work, treat the CLI like any other tool that can reach production secrets, not like a local linter.\n\n**Who is affected.** Anyone running the official binary against a real workspace: interactive TUI sessions, headless `grok -p`\n\nautomations, CI agents, and multi-worktree or subagent setups described in [xAI's own docs](https://docs.x.ai/build/overview). Consumer-auth flows (browser login to X / SuperGrok) are in scope for the capture. API-key-only environments may behave differently; that path was not the subject of this teardown, so do not assume either way without your own capture.\n\n**What actually leaves the machine.**\n\n- Contents of files the agent reads, including env files, with no redaction observed\n- A full workspace package (tracked files plus git history) independent of tool-use, via\n`POST /v1/storage`\n\n- Session-state archives that can re-embed material already seen in model turns\n\n**Practical controls before you point it at anything real.**\n\n- Run it only against throwaway clones or worktrees that contain no production secrets, customer data, or private keys. Strip\n`.env*`\n\n, credential files, and large binary blobs first. - Prefer isolated VMs or containers with no access to your main keychain, SSH agent, or cloud credentials.\n- If policy requires proof rather than trust, MITM your own traffic the same way: trust a local CA, route the binary, log method/host/path/status/bytes, and save request bodies for\n`/v1/responses`\n\nand`/v1/storage`\n\n. The capture method is ordinary developer tooling, not reverse-engineering theater. - For teams that need Grok models without the official CLI's collection path, use the public\n[xAI API](https://docs.x.ai/build/overview)from a tool you control, or evaluate community agents that speak the same API under your own networking and retention rules. Those choices shift responsibility back to your stack; they do not magically erase model-side logging, but they remove this particular default whole-repo upload path. - Document the residual risk for compliance. \"We turned off Improve the model\" is not a control if\n`trace_upload_enabled`\n\nstays true.\n\nTrade-offs are sharp. You get a capable coding agent with TUI, headless mode, worktree-aware subagents, and ACP hooks for orchestration. In exchange you accept default full-workspace transmission to a GCS session-traces bucket unless you redesign the environment around the tool. That is a fine bargain for open-source experiments and greenfield toys. It is a harder sell for regulated monorepos, multi-tenant SaaS codebases, or any machine that still has yesterday's `.env`\n\nsitting in the tree.\n\n## Where this sits in the agent stack\n\nCoding agents have been drifting toward \"the whole workspace is context\" for a while: IDE copilots, terminal agents, and multi-agent orchestrators all want more files, more history, more tools. Whole-repo upload is the logical extreme of that trend. The difference here is not the ambition. It is the default, the lack of an obvious off switch in the settings path that was tested, and the scale of the storage channel relative to the model turn.\n\nIf your team already treats every AI coding tool as an untrusted remote process with full filesystem read, this finding is confirmation, not surprise. If your mental model was \"only what I @-mention leaves the laptop,\" update the model. The canary that was never opened still left in the git bundle.\n\nFor xAI, shipping a first-party collector and a named traces bucket is a product choice with clear engineering upside (debugging, evals, product improvement). For developers, the same choice means the install script is also a data-plane decision. Read it that way.\n\n## Bottom line\n\nGrok Build is interesting as an agent surface: headless runs, worktrees, subagents, and the same Grok models available on the API. The wire evidence on 0.2.93 says the cost of that convenience, on a consumer login, includes default upload of the full repository and unredacted secrets the agent touches, landed in `grok-code-session-traces`\n\nand not disabled by the obvious product toggle.\n\nUse it where that cost is acceptable and the workspace is scrubbed. Instrument it yourself if you need proof. And if your threat model cannot absorb whole-repo transmission to a third-party bucket, keep the model and leave the official CLI on the shelf until the control plane matches the marketing.\n\nThe packets already told the story. The only open question is whether your next project directory is ready to be in that story.\n\n## Sources & further reading\n\n-\n[What xAI's Grok build CLI sends to xAI: A wire-level analysis](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547)— gist.github.com -\n[Grok Build | SpaceXAI Docs](https://docs.x.ai/build/overview)— docs.x.ai -\n[GitHub - superagent-ai/grok-cli: An open-source coding agent for the Grok API · GitHub](https://github.com/superagent-ai/grok-cli)— github.com\n\n[Mariana Souza](https://sourcefeed.dev/u/mariana_souza)· Senior Editor\n\nMariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.\n\n## Discussion 0\n\nNo comments yet\n\nBe the first to weigh in.", "url": "https://wpnews.pro/news/grok-build-uploads-your-whole-repo-by-default", "canonical_source": "https://sourcefeed.dev/a/grok-build-uploads-your-whole-repo-by-default", "published_at": "2026-07-12 21:03:20+00:00", "updated_at": "2026-07-12 21:08:45.371102+00:00", "lang": "en", "topics": ["ai-tools", "ai-ethics", "ai-safety"], "entities": ["xAI", "Grok Build", "Google Cloud Storage", "SuperGrok"], "alternates": {"html": "https://wpnews.pro/news/grok-build-uploads-your-whole-repo-by-default", "markdown": "https://wpnews.pro/news/grok-build-uploads-your-whole-repo-by-default.md", "text": "https://wpnews.pro/news/grok-build-uploads-your-whole-repo-by-default.txt", "jsonld": "https://wpnews.pro/news/grok-build-uploads-your-whole-repo-by-default.jsonld"}}