Grok Build Quietly Uploads Entire Repos to GCS

XAI's Grok Build CLI silently uploads entire git workspaces to a Google Cloud Storage bucket on every session, including files the agent never accesses and unredacted secrets, even when the privacy toggle is disabled. Wire captures show the tool moving 5.10 GiB of data from a 12 GB repository versus 192 KB for model context, a 27,800× ratio. The disclosure failure undermines the product's 'local-first' marketing and raises security concerns for developers using agentic CLIs on private code.

Dev Tools https://sourcefeed.dev/c/dev-tools Article Grok Build Quietly Uploads Entire Repos to GCS The privacy toggle only covers training consent. Full workspace uploads still run by default. Priya Nair https://sourcefeed.dev/u/priya nair Agentic coding CLIs are no longer toys. They sit on production monorepos, CI runners, and machines that hold customer schemas and unreleased product code. That makes silent data paths a first-class security concern, not a privacy footnote. Wire captures of xAI https://x.ai 's Grok Build CLI v0.2.93 show the tool packaging and uploading entire git workspaces to a Google Cloud Storage bucket on every session. Files the agent never opens go along for the ride. Secrets in .env files travel unredacted. The UI toggle most people would treat as a kill switch does not stop it. Marketing called the product "local-first." The packets say otherwise. This is not the usual "the model needs context" story. It is a disclosure failure that changes how you should evaluate any agentic CLI before it ever touches a private tree. Two channels, one of them massive Independent analysis of live traffic mitmproxy on macOS, consumer SuperGrok login found two parallel paths out of the machine. The first is the model-turn channel: POST /v1/responses to cli-chat-proxy.grok.com . When the agent reads a file, that content is serialized into the request. Expected. A canary planted in a secrets file API KEY=CANARY7F3A9-SECRET-should-not-leave appeared verbatim in that traffic, along with mock database credentials. Also expected once you accept that agents read .env files. Uncomfortable, but at least scoped to what the model touches. The second channel is the problem. A separate POST /v1/storage path packages the workspace and ships it as a git bundle or equivalent archive toward a GCS bucket named grok-code-session-traces . Paths look like gs://grok-code-session-traces/repo changes dedup/v2/… . On a 12 GB test repository of files the agent was never told to open, that channel moved 5.10 GiB across 73 chunks of roughly 75 MB each. All storage requests returned HTTP 200. The model-turn channel moved about 192 KB . That is roughly a 27,800× ratio between what the model needed and what left the machine. Cloning a captured bundle recovered a probe file the agent had been explicitly instructed not to open, marker intact, plus full git history. The upload is not "files the agent read." It is the tracked workspace. Binary strings point at first-party Rust crates xai-data-collector , upload modules under xai-grok-shell and the bucket name itself. This is product behavior, not a third-party plugin. The toggle does not mean what it looks like Grok Build exposes an "Improve the model" control. Most developers will read that as "stop sharing my code." Disabling it still left the settings endpoint returning trace upload enabled: true . The repository upload continued. Community reverse-engineering surfaced suppression-style flags disable codebase upload=true , trace upload=false that do not appear in the official setup flow. Enterprise Zero Data Retention is mentioned in secondary write-ups as a path for teams that have it, but the consumer and default experience is the one most people actually run. None of the wire work proves xAI trains on the uploaded bundles. Session continuity, debugging, and operational telemetry are plausible reasons for a session-traces bucket. That distinction matters. Transmission, acceptance HTTP 200 , and storage are what the captures prove. Intent after the bits land is a policy question with no public retention answer in the materials developers see at install time. The real break is consent. "Local-first" plus a privacy toggle that does not gate the multi-gigabyte path is not informed consent. It is a settings page that trains users to feel safe while a background collector does something else. What this means if you actually ship code If you ran Grok Build against any repo that held live secrets, treat those credentials as potentially exposed and rotate them. That includes keys in .env , cloud credentials, database URLs, and anything that sat in tracked history. Git bundles carry history. A secret you deleted last month can still be in the object that left the machine. Practical containment steps, ordered by usefulness: Stop further uploads first. Community and audit tooling point at config under ~/.grok including config.toml mitigations . Verify the flags work on your version before you trust them. Do not assume a UI toggle is enough. Inventory what already left. Local logs under ~/.grok for example logs/unified.jsonl and related session artifacts retain upload receipts: which trees were packaged, byte counts, GCS object paths, and whether the decision looked local or remote. Audit scripts that read those logs without re-exfiltrating secret values are the right shape of tool here. Ignore files are partial protection. A .grokignore is reported in practitioner write-ups, but official enterprise docs do not clearly document it in the materials cited. Treat it as best-effort until you prove it on your build. Agentic shells can also cat past ignore lists when they have shell access. That is a class risk across vendors, not unique to Grok. Zero-disk secrets beat ignore lists. If credentials never live in the working tree, a full-repo upload cannot steal them. Inject from a vault at runtime. Painful for local DX. Correct for anything that touches production config. Enterprise path only if ZDR is real and contractual. Without a published data processing agreement and residency story that matches your counsel's requirements, European and regulated teams have no clean compliance path for a tool that ships full history to a named third-party GCS bucket by default. Compare this to API-style agents that send task-relevant context only. Those still see whatever you put in the prompt or tool results, including secrets the agent decides to read. They do not, on the public evidence, package the whole git graph into a storage bucket on every session. That difference is load-bearing when the blast radius is "every tracked file plus history," not "this one cat ." Supply chain without the malware Call it supply-chain style because the trust model matches: you install a vendor binary, it runs with the privileges of your shell, and it moves proprietary source off-box through a path you did not explicitly enable. There is no exploit payload here. There is product telemetry that looks like exfiltration when measured against the marketing and the toggle. The market is already grading agents by wire behavior. mitmproxy https://mitmproxy.org , canary files, and a throwaway repo with fake secrets are cheap. Expect the same test against the next CLI that claims local-first. Vendors that document storage endpoints, retention, and a real off switch will look boring. Boring is what you want for a tool that can see your monorepo. If you build agentic CLIs yourself, the lesson is blunt. Background full-workspace upload needs the same UX weight as model training consent. Hide it behind a remote-flipable flag and a mislabeled toggle, and the security community will publish the packet capture. Rightly. Grok Build's capture does not prove malice. It proves that "local-first" is currently a slogan, not a property you can verify from the settings page. Until vendors treat full-repo telemetry as a deliberate, documented, default-off feature, treat every new agentic CLI as hostile until the wire says otherwise. Sources & further reading - Grok CLI uploaded the whole home directory to GCS https://twitter.com/i/status/2076598897779020159 — twitter.com - Grok Build CLI Uploads Your Entire Repo to xAI Servers | byteiota https://byteiota.com/grok-build-cli-uploads-repo-xai-servers/ — byteiota.com - xAI Grok CLI Uploads Full Repos and Secrets, Opt-Out Ignored | AI Weekly https://aiweekly.co/alerts/xai-grok-cli-uploads-full-repos-and-secrets-opt-out-ignored — aiweekly.co - What xAI Grok Build CLI actually sends to xAI - a wire-level analysis grok 0.2.93 · GitHub https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547 — gist.github.com - grok-upload-audit/README.md at main · MaydayV/grok-upload-audit https://github.com/MaydayV/grok-upload-audit/blob/main/README.md — github.com Priya Nair https://sourcefeed.dev/u/priya nair · AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to. Discussion 0 No comments yet Be the first to weigh in.