Dev ToolsArticle The privacy toggle only covers training consent. Full workspace uploads still run by default.
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's Grok Build CLI (v0.2.93) show the tool packaging and up 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
(includingconfig.toml
mitigations). Verify the flags work onyourversion before you trust them. Do not assume a UI toggle is enough.Inventory what already left. Local logs under~/.grok
(for examplelogs/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 secretvaluesare 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 alsocat
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, 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.