alt Hacker NewsWhat xAI's Grok Build CLI Actually Sends to xAI
Comments
I imagine the terms and conditions state:
-All disputes to be dealt with by arbitration
-You agree to not have a trial by Jury
If you go with an Elon company, you kinda have to expect ruthlessness
Do people really trust that guy or any service he owns?! Actually never mind I forgot there’s always fools in this world
"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.
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…
Isn'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 adjust your expectations, I think it's be better to upload the code to their servers instead of sending it through context over and over again.
Isn't that expected? I always assumed the agent owns (at least) the current workspace (whatever dir it's launched in) and so can do whatever it wants in there. If they actually use this try and do things in the backend and saving prompt RTTs and tool calls that would be in my interest, no?
This is exactly why tools like Landstrip[1] exist. Sandboxing is a good mitigation to an extent, but it cannot address every class of attack. If an agent allows untrusted content to influence privileged decisions, the underlying design still has a large attack surface. Claude Code is also susceptible to this class of issue because of how its plugin interface works.
I wish a human would’ve written the overview.
Nonetheless, this is disturbing.
will this endup in their "macrohard" (automate any business) project?
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
May I put some contents against GCP's AUP in my repo, wait for Grok Build to upload them, and report the bucket to Google?
> The "Improve the model" toggle makes no difference — ON or OFF, the whole repo is uploaded the same way.
Oh wow that's real bad. I'm assuming most AI shops' own harnesses do something similar when you opt in for their data collection, but them doing it even if you turn it off is diabolical.
One reason to want to upload the entire codebase is that it allows them to have the model inspect the codebase during "thinking" without going back to the client to do real tool calls.
It's not a really great reason, because what's the downside of going back to the client? But that's the best reason I can think of.
How do these findings compare to Codex, Claude code, and cursor
With all the coding agent options, you're choosing to trust your computer, code, and business to whichever harness, model, and provider you pick.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
I'd be happier if that gist had been actually written by a human. As it is, I have very little way of verifying, until someone else can confirm the findings, that the AI tool that produced that report didn't hallucinate part or all of it. It might all be accurate, for all I know, the point is that I'm having a hard time trusting an AI-generated report until it's been verified.
Does anyone know if there's anyone else who has reproduced these findings for themselves yet?
Grok Build has had impressive performance in a couple of my projects. And fast. So this revelation has been very disappointing...
I will say, a majority of the code I'm writing now is fully through an online LLM. If a company wanted to reconstruct a project I'm working on, they could just replay all of the tool calls from their logs, if they decide to retain the data (I did this locally once to recover a project that I mistakenly clobbered in Git).
Still, this is a big overstep IMO. At the very least, they should make it clear in their terms of service and privacy policy, and not hidden through legalese. Not all usage of Grok Build will be through their enterprise plan which offers ZDR.
Claude gets its own UNIX account on my dev machine. I would never trust it not to read .ssh or other sensitive private information in my home directory or elsewhere.
In view of this, I should probably go further and bubblewrap it to restrict /etc, /proc and other things it legitimately does not need to do its job. I already do that for programs such as Steam (and games therein) to mitigate the possibility that they may spy on me.
> 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
To be fair, most coding agent cli's by the labs do this and are opt in by default, it's just this does too
This is precisely why I run a custom fork of CLIProxyAPI on a private railway server for all my agentic coding. The OG version is indispensable already and has XAI Oauth support, so you can use your subscription to call Grok from any Anthropic OR OpenAI compatible client (Claude Code, Pi, Codex, you name it). To be honest, though, I am bummed, as I do really like the grok build client. The TUI is great in the ways that matter without going out of its way to make it clear that "I'M A MID-LATE 2020s TUI LOOK AT ALL THE NOT USUAL STUFF YOU CAN DO WITH ME".
Grok aside, this has become an increasingly large concern of mine, especially now that I've expanded my usual provider rotation beyond the big 2. Out of arguably reasonable paranoia, I recently bolstered my own personal CLIProxyAPI fork to use an algo similar to gitleaks/betterleaks to, on the fly, scan the incoming (i.e. from my coding agent) stream for any secrets that may have been transmitted from disk, replace them with a unique identifier, send that off to the upstream provider, and then replace the secret (mapped to that identifier in memory, encrypted and with TTL) before sending any response back. That way, if the "secret" is either not really a secret and/or truly is needed in whatever tool call or response, the replacement is seamless to the client but the provider never sees your code.
No, it's not foolproof: it can't prevent some upstream actor from, say, using the on-disk key to your secret in a rogue tool call that uploads it from your device directly to an endpoint of theirs, but the low-hanging fruit like this is, IMO, the equivalent of not leaving all your windows open when you're naked. Virtually no downside or inconvenience to you, gets probably 3-4 9s of cases where someone would be inclined to see something they shouldn't because it's that easy.
The alternative is literally having to approve every read request (is this even a thing now?) and spend the mental energy ensuring that each and every file could not possibly contain a secret. I'd rather just code by hand at that point.
haha so they just stealing entire codebases?
I wonder how many of you guys actually read this kind of reports (or even skim through)? At the first glance it looks to me like someone just asked an agent for a security review of this CLI and then pasted results to the gist.
When I see a report like that I just assume it's a low-effort AI slop and stop reading immediately. Why would I read it since I can do the same with my agent and with that understand it better? Or if I'm really lazy then just copy paste this report and ask for a summary or have a discussion.
How is this not on the frontpage, this should be editorially pinned given the number of programmers here
the Grok Build CLI phoning home with your code is just xAI's way of making sure someone, somewhere, is actually reading your pull requests
So xAI now has a "legal" copy of all of Tesla's code? Convenient.
https://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
Now, where are the people afraid of the Chinese AI companies, who claim they are going to copy their very precious code...?
sam altman: aww you're sweet
elon musk: hello human resources
Both Grok and Claude Code are malware.
This is another reason to use open source harnesses and open weight local models.
Friendly reminder: since Musk now owns Cursor, there are a bunch of really good open-source alternatives you can use.
It still somewhat blows my mind that xAI is allowed to operate in Europe given e.g. GDPR et al. Closest I can come to is Musk is above the law even in the EU given his relationship to Trump.
[dead]
The simplest way to disable uploading your repo is disabling it in the config.
[harness]
disable_codebase_upload=truethis is bad... but just for chuckles, i asked grok cli to check disclosure and look through the binary and logs to see which config would stop it from doing that. no idea if it truly works, but here it is:
Config after fix (~/.grok/config.toml)
[harness]
disable_codebase_upload = true
[telemetry]
trace_upload = false
[features]
telemetry = false
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, with .git read-only and sensitive directories hidden (mounted as empty directories).
2. Have an isolated network namespace; they can only access the internet through an HTTP proxy hosted on a Unix socket, can only access specific LLM provider hostnames, and exclude the tool's own hostname.
For example, with Crush, I will let it access *.openrouter.ai (LLM providers) but not *.charm.land (Crush's domain for auto-updating the LLM list).
This makes me feel much more comfortable enabling "yolo" mode and letting the tools do everything.