You install a new coding CLI, point it at a private repo, and run a task. Somewhere in the background, before the model even answers you, a request goes out you didn't type, to a destination you didn't choose, carrying data you didn't select. You'd only know if you were running a proxy and reading the traffic. Almost nobody is. That gap is the subject of a recent Hacker News thread about xAI's Grok Build CLI — and it's worth taking seriously because the findings are specific enough to check, not another round of "cloud AI agents see your code."
This article reflects a wire-level teardown and HN discussion current as of July 2026, plus xAI's documentation as published at the time of research. Confirm current behavior against xAI's own docs before relying on any of it — where this piece flags something as unverified, treat it as a question for your vendor, not a settled fact.
A teardown, not a rumor
The claims driving the HN thread don't come from a blog post speculating about what a coding agent "probably" does. They come from a public wire-level teardown published as a gist, where the author ran Grok Build CLI behind an intercepting proxy, planted canary secrets in a test repository, and captured what actually crossed the network — independent of what the agent claimed to do in its own chat output. A complaint is a feeling; an audit is a reproducible capture someone else can run again and get the same result from.
Three findings came out of it, and they compound rather than stack independently:
- Whole-repo upload. Grok Build CLI uploads the entire tracked contents of a repository plus its git history through a background channel to a Google Cloud Storage bucket, regardless of what files the agent was actually asked to read or touch in that session.
- No client-side redaction. Canary secrets placed in test files were transmitted unredacted before the upload left the machine.
- Separate from the training toggle. This upload channel is separate from, and not disabled by, the model-training opt-out a user might reasonably assume covers "don't send my code anywhere I didn't ask."
What HN actually disagreed about
The strongest reaction in the HN thread — 292 points, 133 comments as of July 2026 — treated the whole-repo-plus-git-history upload as categorically different from ordinary cloud-agent context sending. One commenter: "'It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads' Holy cow!!!! ... this is extremely concerning. This is precisely the reason, even though their pricing is competitive and grok-4.5 is actually good enough, I chose not to go with them." Sending the file being edited is expected; sending every file the agent was never asked to touch, plus commit history that might contain since-rotated secrets, is a different category of exposure.
The fairest pushback didn't defend Grok Build — it generalized the risk: "This is one of the reasons why native proprietary coding agent runners like claude-code, codex, grok-build etc are so dangerous for privacy… you just don't know what 'secret sauce' they'll add in the next update… It's much safer to use something like opencode and use models via their API… however, the tradeoff is that it will never perform as well as it does in their native agent runners…" That's fair: no closed-source native coding CLI is verifiable by users without exactly this kind of independent teardown, and the same limitation applies to Claude Code and Codex, not just xAI.
But a separate commenter supplied corroboration that's specific to Grok Build, not generic to the category: "If you want easily verifiable evidence, run strings on the Grok Build CLI binary and you will see: Codebase upload skipped: disabled by config (harness.disable_codebase_upload=true)." A binary doesn't contain a disable flag for a feature that doesn't exist. That's independent, low-effort, reproducible evidence that the upload path is real, ships on by default, and wasn't disclosed anywhere in the onboarding flow a new user actually sees.
What xAI's own documentation confirms — and doesn't
xAI's enterprise documentation describes a data lifecycle where data is not persisted at the inference layer specifically for organizations on a zero-data-retention (ZDR) tier. Read the contrapositive: for accounts not on ZDR — the default individual and team accounts most Grok Build users are actually running — persistence at the inference layer isn't ruled out. The docs don't name a GCS bucket or a storage upload path, and they don't confirm the teardown's exact mechanism. But they confirm the shape of the gap the teardown found: retention that the default account never opts out of, because ZDR is a tier organizations opt into at the team or enterprise level, not the state you land in after installing the CLI. A solo developer following the documented getting-started flow — install, authenticate, run grok inspect, start prompting — never encounters ZDR as a concept, let alone a decision to make.
The docs also describe sandbox profiles for constraining what the agent can touch on disk and over the network — a real, documented mitigation. But these profiles ship off by default; a user has to know they exist to turn them on. xAI's own launch announcement for Grok Build CLI frames the product around its terminal-native, headless, ACP-compatible workflow, which is useful framing for evaluating what the tool can do — but says nothing about the storage or upload mechanism the teardown surfaced.
Why "everyone does this" doesn't settle it
Claude Code, Codex, and Grok Build all read local files by design, and all three are closed-source, meaning any of them could add new upload behavior in a point release with no changelog anyone reads. A vendor comparison piece from Eigent makes essentially this generic point about cloud coding CLIs sending code context to servers — true, and not news to anyone who's thought about it for five minutes.
What the generic framing misses is the difference between scope and volume. "Cloud agents send code context" describes scope — the category of data a request might touch. It says nothing about volume (the open file versus every tracked file plus git history) or mechanism (a per-request context window versus a standing background channel to persistent storage). The teardown's contribution isn't reminding anyone that cloud agents see code; it's establishing, with a reproducible capture, that this implementation moves more data through more persistent channels than the "send what's relevant to the prompt" model most users assume. Competitors have started marketing against exactly this distinction — Kilo's comparison page positions its own open-source auditability directly against closed native runners like Grok Build, which tells you the market already treats "can you verify what it sends" as a competitive axis.
This also isn't the first time a coding CLI's data-handling language has left practitioners confused rather than reassured. An earlier HN thread about Gemini CLI has a commenter working through the vendor's own retention language and coming up empty: "I'm left somewhat confused... These three sections appear contradictory, and I'm left puzzled and confused. It's a poor experience compared to competitors like GitHub Copilot... or Claude Code, where Anthropic has a policy that code will never be used for training unless the user specifically opts in." Different vendor, different product, same failure: documentation that details training opt-outs while leaving retention and transmission mechanics vague. The pattern predates Grok Build and will likely outlast this controversy.
What to actually do about it
The most useful comment in the HN thread wasn't the angriest one — it described a setup: "I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they: 1. Can only read the working project directory... 2. Have an isolated network namespace... This makes me feel much more comfortable enabling 'yolo' mode." Notice this doesn't say "switch away from Grok" — it describes a filesystem and network boundary that constrains any closed native CLI, audited or not. If you're running an agent with write access and network egress, treat containment as the default posture, not a response to one headline.
Where a vendor offers a documented zero-data-retention tier, use it if your code is sensitive enough to justify the friction — and read the fine print, since per xAI's docs it's scoped to the inference layer and gated to specific account types. Where a CLI supports routing through your own API key against the underlying model rather than the vendor's native agent runner, that path narrows what a wrapper layer can silently add, at the cost the HN counter-argument names honestly: you likely give up some tuned native-runner performance.
And before adopting any closed coding CLI, it's worth checking whether a disable flag like harness.disable_codebase_upload exists in the binary via strings. If you find one, that's your answer about whether the feature it disables was ever going to be disclosed to you otherwise.
What this should mean for vendors
A "we don't train on your code unless you opt in" line leaves several questions open: what gets uploaded, where it's stored, how long, under what account tier. Vendors serious about transparency need to document wire behavior specifically — upload paths, storage destinations, retention windows by tier — not just training policy, which per the Gemini CLI precedent is the one thing vendors already over-explain relative to everything else.
The technical fix implied by this whole episode isn't complicated: default to sending only what a request needs to answer, let organizations opt into broader context capture with informed consent, and stop treating "off by default but present in the binary" as equivalent to "documented." Sandbox profiles that exist but ship off by default put the burden of safety entirely on the user discovering and enabling them; the more defensible design is a sandbox that's on unless a user deliberately opts out for a specific, informed reason — which is close to what practitioners are already building for themselves with bubblewrap. (For a deeper look at the tradeoffs between local and server-side context assembly when an agent needs to reason about a whole codebase, see our guide on how an AI agent understands a full codebase.)
Evaluating a coding CLI's trust posture before you install it
Read the enterprise or security doc even if you're not an enterprise customer — it's usually the only place a vendor writes retention and persistence behavior in specific terms, because enterprise buyers and their legal teams demand it. That doc still describes the infrastructure your account almost certainly runs on.
The single most useful question to ask any coding CLI vendor isn't "do you train on my code" — it's "what persists after my session ends, in which storage system, retained for how long, and does that change by account tier." If the answer isn't documented anywhere you can point to, assume the more exposed default until told otherwise, not the more private one. That's the uncomfortable generalization from this whole episode: undocumented behavior should be assumed present until an independent audit rules it out, not assumed absent until one proves it — a more useful default than either blind trust or singling out whichever vendor got audited first.
FAQ
Does Grok Build CLI upload my whole codebase, not just files it reads?
Yes, per the independent wire-level teardown described above — every tracked file plus git history, through a background channel to Google Cloud Storage, regardless of what the agent was asked to read in a given session.
Is this unique to Grok Build, or do other coding CLIs do the same thing?
Unverified for others. None of the major closed-source native CLIs — including Claude Code and Codex — have source available for users to audit directly. What's specific to Grok Build is that this claim has actually been tested and corroborated; treat other vendors as unverified rather than assumed-safe.
Does turning off "Improve the model" stop this upload?
No. Per the teardown, the codebase-upload channel is separate from the training opt-out. Only the opt-in, team-level zero-data-retention tier addresses data persistence at the inference layer.
What can I actually do about it right now?
Run agent CLIs inside a filesystem and network sandbox (bubblewrap is the tool HN practitioners cited), use a documented ZDR tier or an API-key-only path where available, and check the binary for disable flags like harness.disable_codebase_upload before assuming a feature doesn't exist just because it isn't documented.
Conclusion
The teardown of Grok Build CLI is a sharper trust failure than the familiar "cloud AI agents see your code" complaint because it's specific and checkable, and because xAI's own enterprise documentation corroborates the shape of the gap even without naming the exact mechanism. The fair HN counter-argument — that every closed native coding CLI carries this risk because none are user-auditable — doesn't make this specific, corroborated finding a non-event. The practical response isn't to single out xAI and switch to whichever vendor hasn't been torn down yet; it's to sandbox any closed agent CLI by default, read the enterprise-tier docs even as a non-enterprise user, and hold every vendor to the standard of documenting wire behavior rather than trusting a training opt-out to cover ground it was never designed to cover.
