"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads" Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but 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.
There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access. Imagine if the CLI pulled your SSH keys or other sensitive information by mistake? Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake. 1 - https://github.com/ashishb/amazing-sandbox
What xAI's Grok build CLI sends to xAI: A wire-level analysis
71–80 of 251 posts
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#72Isn't it assumed that the AI agent is allowed to read your files in the directory you launch the harness? Most agents read your code on the first prompt, including any secrets you have there, which you shouldn't have. Also the .env file is for local environment, and shouldn't contain any actual secrets. AI agents should be isolated from any actual secrets, because they can't be trusted to follow instructions. If you…
Yes. There's very little story here. Maybe Grok is being like 10% more aggressive than other providers in how they assemble context (more likely: it was faster to ship this way), but any provider has the ability to do the same thing, and will happily do it if it helps improve results. Authors acknowledge this openly, but it's buried:
> "Cloud AI tools send context; this is normal." True, and conceded: any cloud coding agent must send code to its server to act on it. The novel deltas here are (a) a secrets file (e.g. .env) is transmitted unredacted, (b) the content is persisted to a named GCS bucket, not just processed transiently, and (c) the upload mechanism is not surfaced in the CLI's setup materials (§7) and on by default.
This is the entire controversial portion of the finding, in a single paragraph.
As far as the .env thing goes, you shouldn't be putting unencrypted .env files in the accessible path of any LLM. If you do, you're asking for trouble. It would obviously be better if Grok identified secrets and ignored them, but this is not a behavior you should rely on.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#73This 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…
I agree with you, but Codex is open source.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#74Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#75> It transmits the contents of files it reads — including a .env secrets file — to xAI, verbatim and unredacted. This has to be the most successful mass surveillance campaign of all time
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#76This 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 a major problem in its own right. Yes, not updating an XP SP1 RCE immediately is dangerous, but in the last couple decades I've seen far more damage inflicted from automatic updates than what I think the lack of them would have caused.
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#77The simplest way to disable uploading your repo is disabling it in the config. [harness] disable_codebase_upload=true
> simplest way to disable uploading your repo is disabling it in the config Have you verified this flag is respected?
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#78Earlier quoted context omitted.
using them in VSCode all the time for months now. Qwen from Alibaba Cloud, Deepseek from deepseek.com. none of them upload entirety of codebase or even attempt to. in fact, opposite. Chinese AI seem to post-process heaviliy locally. they are always using head / tail, grep, sed, and do as much as they can locally and extrac meaningful data and send home (AI inference chunks). only what is really needed. it is actually…
> none of them upload entirety of codebase or even attempt to. How do you know? Did you do an analysis like OP did?
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#79Earlier quoted context omitted.
There is a reason I run all such CLIs inside a sandbox [1] giving limited directory access. Imagine if the CLI pulled your SSH keys or other sensitive information by mistake? Programmers do make such mistakes all the time. I don't want to count on whether "uploading all files it can access" is intentional or a mistake. 1 - https://github.com/ashishb/amazing-sandbox
What’s described here isn’t connected to the agentic/AI nature of the software at all. Every single program you run as a regular user could potentially do this.
Why would you let a markdown linter access your ssh keys?
Re: What xAI's Grok build CLI sends to xAI: A wire-level analysis
#80 Config after fix (~/.grok/config.toml)
[harness]
disable_codebase_upload = true
[telemetry]
trace_upload = false
[features]
telemetry = false