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.
If a harness wants to upload the whole codebase in one batch, it should explicitly inform the user about it. Instead of exfiltrating the data without consent.
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…
> however, the tradeoff is that it will never perform as well as it does in their native agent runners
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
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.
I don’t know why anyone would use Grok Build when they could use Cursor, with access to both Grok-4.5 and Composer-2.5-Fast and astonishingly cheap prices, and easy access to Opus if you need it.
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.
+1 for bubblewrap, unsharing everything and then adding back everything your agent needs saves the trouble of updating a docker image and allows you to give selective access to local tooling. I actually go as far as to run nearly every. single. application. in bwrap that doesn't come with native sandboxing. I share credential authentication via sockets, had to build custom schemas for k8s and docker since they still don't have a way to do remote attestation...
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.
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.
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.
this 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:
> 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.
77 comments
[ 4.9 ms ] story [ 69.5 ms ] threadHoly 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.
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.
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
https://news.ycombinator.com/newsguidelines.html
Edit: I suppose I'd better add that this is not a defense of $THAT_GUY - just an attempted defense of HN comment quality.
Edit 2: Could you please stop posting unsubstantive comments and flamebait generally? It's not what this site is for, and destroys what it is for.
For example, we ban accounts that post things like https://news.ycombinator.com/item?id=48878096 and your account history unfortunately has quite a bit of this. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
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…
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
It's not a great state of affairs, but that's where we are.
Choose wisely my friend.
Nonetheless, this is disturbing.
This is another reason to use open source harnesses and open weight local models.
This has to be the most successful mass surveillance campaign of all time
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.
I find Deepseek to be a great compromise between cost and performance. Anthropic and OpenAI are simply too expensive at this point.
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.
For CC I have a template here https://kaveh.page/blog/claude-code-sandbox
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.
https://electrek.co/2026/07/10/musk-tells-tesla-staff-switch...
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.
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.