O que o Grok Build CLI da xAI realmente envia para a xAI(gist.github.com)
gist.github.com
What xAI's Grok Build CLI Actually Sends to xAI
https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
135 comments
with bubblewrap it's better to pull a rootfs from dockerhub (eg. debian:unstable) then bootstrap it into a fully fledged distro rootfs living in its own folder. install the AI agents right into it, then create launch scripts that invoke bwrap with the distro rootfs (readonly) and a custom read-write /home/user and run whatever you want inside it - it will not see anything important outside the directory you give it. you can also run multiple agents each invisible to the others.
for bonus points you can uplift the bwrap container into an actual sandbox by invoking gvisor (`runsc ... do ...`) from inside it, or a virtual machine monitor like muvm. I'm really fond of this pattern because you can trust bwrap to set up the environment, then you just need a sandbox tool to lock it down.
bwrap by itself will probably be sufficient against most adversaries as assuming proper config it would require committing to using a linux kernel 0day to escalate privs.
for bonus points you can uplift the bwrap container into an actual sandbox by invoking gvisor (`runsc ... do ...`) from inside it, or a virtual machine monitor like muvm. I'm really fond of this pattern because you can trust bwrap to set up the environment, then you just need a sandbox tool to lock it down.
bwrap by itself will probably be sufficient against most adversaries as assuming proper config it would require committing to using a linux kernel 0day to escalate privs.
Thanks for the suggestions. I've used debootstrap to build a Debian rootfs for bwrap before, but my threat model is simpler: nothing sensitive lives outside $HOME on my machine. So I just ro-bind the system dirs I need and give the sandbox a tmpfs home (one-shot apps) or a persistent fake home (stateful apps, under ~/.var/app/<appname>). This is good enough for my case.
The gvisor layering looks promising though. I'll take a look and see if it would be useful.
The gvisor layering looks promising though. I'll take a look and see if it would be useful.
What's your mechanism for doing this?
Think they are referring to this
https://github.com/containers/bubblewrap
I use bubblewrap to unshare all namespaces (net, pid, ipc, user) and ro-bind necessary system paths like /etc, /lib, create a tmpfs home, mount the project folder under it (writable), then mount tmpfs over sensitive directories inside the project to hide them.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.
For the network part, a daemon outside the sandbox serves a filtering HTTP proxy on a Unix socket. I mount the Unix socket into the sandbox and bridge it to localhost with socat. With the net namespace unshared, the app can't reach the network at all except through this proxy, which only allows LLM providers.
By separating the coding tool from the LLM provider, I feel safer: the coding tool cannot leak anything on its own. It can only talk to the LLM provider, so a real leak would require the provider to be complicit too. And any sensitive files, inside or outside the project, are hidden by the mount namespace, which I suppose is hard to escape.
Do people really trust that guy or any service he owns?! Actually never mind I forgot there’s always fools in this world
Shades of:
> People just submitted it. I don't know why. They 'trust me'. Dumb f..ks.
- Zuckerberg circa 2004, in case anyone is out of the loop
> People just submitted it. I don't know why. They 'trust me'. Dumb f..ks.
- Zuckerberg circa 2004, in case anyone is out of the loop
there are 2.7 m starlink subscribers in US, I don't think they are fools.
Those are people without a better option.
Big difference vs xAI, where the sentiment is valid.
Big difference vs xAI, where the sentiment is valid.
that's like 1% of the US
we definitely have that level of mental deficiency in this country..
we definitely have that level of mental deficiency in this country..
Sure bud … carry on
There is a German proverb, that goes roughly like this: "eating shit is good for you, billions of flys can't be wrong!"
"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.
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.
Does OpenAI also have access to all github repos via partnership with microsoft?
GitHub Copilot engineer here working on identity, safety, and privacy - no, even Microsoft doesn’t have access to all GitHub repos.
As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additional layer of entitlements to gate and audit access to any sensitive data, including user data.
Very few employees within GitHub proper even have access to view private repositories, and in the rare cases where that’s done for legal or safety reasons the repository owner is notified.
There are currently no OpenAI employees with access to GitHub systems, so there’s about 4 layers of protection in place to prevent private repositories access. We do genuinely take user data protection and privacy seriously.
As years have passed since the acquisition “company” delineations have blurred a bit, but Microsoft employees still need to go through a separate onboarding process to access any GitHub company resources (internal repositories, telemetry, documentation, etc.), and then we have an additional layer of entitlements to gate and audit access to any sensitive data, including user data.
Very few employees within GitHub proper even have access to view private repositories, and in the rare cases where that’s done for legal or safety reasons the repository owner is notified.
There are currently no OpenAI employees with access to GitHub systems, so there’s about 4 layers of protection in place to prevent private repositories access. We do genuinely take user data protection and privacy seriously.
This is a nice answer to the question "how is GitHub preventing rogue employees at Microsoft from stealing my private repositories?". Like, it's good to know I'm covered if Microsoft accidentally hires a North Korean spy or something.
But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.
Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.
(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)
But if Microsoft really was selling private repo content to OpenAI, it probably wouldn't go through those access controls. It'd be an executive-level decision with enough force to plow through all the red tape, and it'd be implemented as a data pipeline or similar automated process that wouldn't trigger the same kind of notification as, like, a Trust and Safety employee taking manual action.
Probably the better evidence here is in GitHub's ToS where they say in pretty strong/binding terms that they aren't doing this: https://docs.github.com/en/site-policy/github-terms/github-t... . If they are secretly selling your data to OpenAI they haven't left themselves a ton of wiggle room if people ever found out.
(Probably the biggest loophole they could use is to send private repo content to an OpenAI service for scanning/safety purposes. The ToS allows this and they're almost certainly doing it with other services like PhotoDNA. Then OpenAI can just violate whatever agreement they have not to store the data sent to that service.)
I’m one of the people directly responsible for ensuring that those terms are properly enforced. Presently I’m arguably the person for Copilot data specifically.
Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.
Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at [email protected]!
Current talk of the town in the data retention space is around AI safety. There’s been a recent slew of blog posts and academic papers around how LLM harms can manifest over multiple agentic turns, from individually innocuous requests. Identifying this inherently necessitates user data retention which we do everything possible to avoid (not even meaning data sharing as is alluded to in this thread, I mean literally persisting prompts and completions anywhere outside of ephemeral memory). I’ve been the one advocating for having the storage of any data retained for safety and security purposes to be as heavily access controlled and audited as is possible.
Also, if AI safety is a space that is interesting to you, we’re hiring! Manager, developer, and applied science roles, or we can figure out the HR shenanigans if you don’t fit any of those archetypes. If interested shoot me an email at [email protected]!
(FWIW, in my conspiracy theory, the data sharing would be buried in the part of the company responsible for making sure that people don't upload e.g. CSAM to private repositories, so the Copilot people wouldn't be directly aware of it. I might've edited that in after you already started writing your reply though.)
Still in my bubble! I am not involved in the human review or automated analysis portions of the safety pipeline for CSAM/TVEC harms, but my team is responsible for the data handling around identifying and responding to such content.
As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.
As of 11 days ago our vision support is GA (https://github.blog/changelog/2026-07-01-copilot-vision-is-g...) and let’s just say the technical implementation wasn’t the long pull there. Figuring out the what and how of responsible data handling around what I hope is agreeably harmful use was… quite a journey.
That's great that you're working on that, but I imagine GitHub has been scanning repository content for illegal material for longer than eleven days
(This thread kind of seems like a series of non-sequiturs, where you keep responding to concerns by discussing controls that don't address that particular concern. I'm not sure if I should be reading between the lines of that.)
(This thread kind of seems like a series of non-sequiturs, where you keep responding to concerns by discussing controls that don't address that particular concern. I'm not sure if I should be reading between the lines of that.)
How do you define "access" here? Microsoft has demonstrated that it can delete any GitHub repo at will. Maybe there's some shell entity between corporate "Microsoft" and "GitHub" that's doing the dirty deeds without attribution...
Access meaning read, modify, delete, etc. Pretty standard definition, unless you know of a different meaning of access I’m not privy to.
Microsoft can certainly request that we perform actions against repositories, as can governments, customers, random people on the street, etc. Whether action is taken in those cases is a question for lawyers to fight over, but we have the engineering guardrails in place to require it to be an intentional, audited action.
I appreciate the spicy question tho, even if misguided!
Microsoft can certainly request that we perform actions against repositories, as can governments, customers, random people on the street, etc. Whether action is taken in those cases is a question for lawyers to fight over, but we have the engineering guardrails in place to require it to be an intentional, audited action.
I appreciate the spicy question tho, even if misguided!
Can you state with absolute сertainity that no entity outside your github unit can exfiltrate data at will?
This is not spicy, this is basic infosec.
This is not spicy, this is basic infosec.
Nobody can say that with absolute certainty, so obviously not.
And since you presumably knew that already (as it is basic infosec) then yes it is spicy, or simply antagonistic.
And since you presumably knew that already (as it is basic infosec) then yes it is spicy, or simply antagonistic.
If we lower the threshold from "absolutely" to "absent third-party breaches" what would you say?
Even with your rephrasing you’re looking for an answer in absolutes which is generally impossible, but unpacking your line of questioning, what it really amounts to is how “in the know” I am or am not.
To the best of my knowledge I know about every ongoing company AI safety and user privacy initiative, and none of them involve permitting access to copilot user content to any second party or third party entity.
Of course, that’s tautological. I don’t know what I don’t know, but I’m senior enough and with broad enough scope that I’m at least read in on what I believe is the majority of high level business initiatives.
I’m not trying to be evasive, this is just the reality of any organization - I only know what I know. Everything within my scope of awareness indicates that there is no copilot user content access outside of our publicly published terms of service.
To the best of my knowledge I know about every ongoing company AI safety and user privacy initiative, and none of them involve permitting access to copilot user content to any second party or third party entity.
Of course, that’s tautological. I don’t know what I don’t know, but I’m senior enough and with broad enough scope that I’m at least read in on what I believe is the majority of high level business initiatives.
I’m not trying to be evasive, this is just the reality of any organization - I only know what I know. Everything within my scope of awareness indicates that there is no copilot user content access outside of our publicly published terms of service.
So they can exfiltrate with impunity _and_ you will never admit it.
This is nothing new, status quo in fact. But thank you for this acknowledgment by evasion.
This is nothing new, status quo in fact. But thank you for this acknowledgment by evasion.
Can you prove what you are saying, you have to, if not, you are talking to us like we are idiots.
Prove which part?
Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.
Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.
Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.
Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!
Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.
Prove that I work at GitHub? Username + LinkedIn can show (not prove) that easily.
Prove that we have an entitlements system which regulates and audits access? I could point you to https://github.com/entitlements, but it’s all private repositories so that won’t prove much either.
Prove that there are no OpenAI employees with access to GitHub systems? Not sure how I’d do that without dumping (what you would still need to trust me is) the entirety of our org chart/HR system, which I’m not willing to do because I do enjoy being employed and am not exactly obfuscating my identity here.
Prove that HN has a strong anti-Microsoft bias? Well that one is pretty easy actually, you’re helping prove it yourself!
Let’s be real, we now live in a post-truth world. Nothing can truly be proven or disproven outside of formal logic and mathematics. You can either believe what I’m saying as good faith insider knowledge sharing (which is unfortunately rare nowadays) or you can not. Makes no difference to me.
It would be _extremely_ surprising if private repos were available via that contract. Corporations wouldn't use GitHub at all if anyone other than those given direct access had read/copy permission.
It wouldnt be _that_ surprising since they committed widespread copyright violations building the models, plus the recent Apple IP theft...
Disclosing private repos against the owner's intent is a much more immediate and significant business risk than violating the license of open source code.
Maybe that shouldn't be the case, but it is.
Maybe that shouldn't be the case, but it is.
This speaks to OpenAI's approach to things. But it doesn't speak to Microsoft and Microsoft would need to provide the access.
this might be relevant about microsoft.
Federal Cyber Experts Thought Microsoft’s Cloud Was “a Pile of Shit.” They Approved It Anyway:
https://www.propublica.org/article/microsoft-cloud-fedramp-c...
Federal Cyber Experts Thought Microsoft’s Cloud Was “a Pile of Shit.” They Approved It Anyway:
https://www.propublica.org/article/microsoft-cloud-fedramp-c...
They were caught stealing Apple trade secrets, dude. Nothing is beneath them.
Nothing is beneath Altman, maybe, but Satya isn’t that dumb. MSFT cares about OAI but giving access to private data and trade secrets voluntarily would be catastrophic for them.
Doesn’t feel like the type of mistake Satya would make.
Doesn’t feel like the type of mistake Satya would make.
The AI systems ingest tons of copyrighted data and that is stealing/theft(or so we peasants were told). It’s not like they don’t know they are doing. It looks like MSFT doesnt care that much either.
How did book publishers figure out ai stole from them? Can people use a similar way to figure out if their private repos have become part of the training corpus?
I could see there being different rules for enterprise accounts.
Absolutely not. That would be an absurd violation. If you have Copilot enabled then they can use your interaction data for training but you can turn that off as well
That's not what the article says.
it's straight up data exfiltration and should be illegal
I was hesitant to try the free trial exactly because I haven't found any info about what data was required to share...
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
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
The readme is confusing. You say it has bubblewrap, but you also have an FAQ saying why not to use bubblewrap? Another FAQ says why not to use sandbox-exec for mac, yet the link for mac goes to sandbox-exec?
But in this particular case isn't the problem that it's sending everything in the sandbox? Rather than what it might do in an otherwise un-sandboxed system?
> But in this particular case isn't the problem that it's sending everything in the sandbox?
If a CLI is touching certain files, they are likely to be leaked one way or the other.
Why not reduce the attack surface?
When does someone visit your house? Do they get unfettered access to your bedroom & safe as well?
If a CLI is touching certain files, they are likely to be leaked one way or the other.
Why not reduce the attack surface?
When does someone visit your house? Do they get unfettered access to your bedroom & safe as well?
It would be extremely naive to assume Elon, or even a real human had a hand in this. The whole analytics pipeline is very likely vibecoded and never reviewed by a human.
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…
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…
Give enough usage, you can reconstruct an entire codebase via tool calls alone, and it'll be entirely undetectable because it's all done server side. Whatever grok's doing is just more blatant, but using opencode or whatever doesn't create a meaningful security boundary. It's like the meme of using cheetos as a lock.
I agree with you, but Codex is open source.
Is the server side open-source too, as gruez brought up in the sibling comment?
Technically they can still do potentially any- and everything undetected there; and for what it’s worth, even with a closed-source client bad behavior would get detected eventually through network inspection.
Technically they can still do potentially any- and everything undetected there; and for what it’s worth, even with a closed-source client bad behavior would get detected eventually through network inspection.
> the next update
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.
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.
I'm using my own agent, but i can't risk blocking the company account with it.....
last time I checked, codex is still open source w Apache-2.0 license
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.
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.
It will have to be sent through the context again. That's how LLMs work.
The only reason to do this is so that Musk has clean training data for his next model. Project setup, popular libraries, CI workflows, etc.
The only reason to do this is so that Musk has clean training data for his next model. Project setup, popular libraries, CI workflows, etc.
Even if it's uploaded once, it's still being ran through inference. It saves a bit of HTTP traffic I suppose.
> Isn't it assumed that the AI agent is allowed to read your files in the directory you launch the harness?
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.
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.
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.
[1]: https://github.com/landstrip/landstrip
[1]: https://github.com/landstrip/landstrip
Also, I'm not particularly fond of using VM/microVM for sandboxing agents. This aligns with my line of thought: https://www.linkedin.com/pulse/why-your-microvm-sandbox-solv...
I wish a human would’ve written the overview.
Nonetheless, this is disturbing.
Nonetheless, this is disturbing.
Yeah this could be boiled down to maybe 2-3 paragraphs with maybe a few code blocks to show what's uploaded. This AI report is just a slog to read through and turned me off after 10s of skimming.
Or even just that a human had iterated a bit more with the LLM to improve the style.
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?
No, there’s the normal messages API which is what’s used to read files and deliver responses.
The author has identified a second endpoint which exfils your whole project folder, into a GCP storage bucket. Anyone who designs large scale distributed systems can tell this is to scoop up training data.
The author has identified a second endpoint which exfils your whole project folder, into a GCP storage bucket. Anyone who designs large scale distributed systems can tell this is to scoop up training data.
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.
will this endup in their "everything app"?
guess you do not need to build "everything" yourself, when you can steal it.
The icing on the cake is that users are ostensibly paying for the privilege. What a business model...
If I had no morals and was running one of these companies I would be stealmaxxing before anyone notices the scale of the grift and regulations start getting in the way.
I'm not saying they are doing this, but that's what the incentives are lined up for.
If I had no morals and was running one of these companies I would be stealmaxxing before anyone notices the scale of the grift and regulations start getting in the way.
I'm not saying they are doing this, but that's what the incentives are lined up for.
exactly. looks like this is what they doing
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.
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.
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.
more like it allows them to steal your trade secrets, app designs, internal business knowledge, or even just replicate whatever code/app/tool/process you had.
what was your private code, becomes their code now.
what was your private code, becomes their code now.
Your trade secret is already gone the moment you unleashed non local ai agents on your codebase.
This is why I keep a separate repo for important parts that I do not want competitors to get access to, and only use ai on dumb parts which I don't care if get leaked tomorrow.
This is why I keep a separate repo for important parts that I do not want competitors to get access to, and only use ai on dumb parts which I don't care if get leaked tomorrow.
there is difference between:
A) leaking structured fully working complete set of files (full working recipe) that is not relevant to AI queries at all.
B) adhoc random queries, bits and pieces, grep of chunks of random files and local bash post-processing for AI queries at hand. which is hard to use for anyting anyways, and will end up in just corups of trainig data (CommonCrawl quality — meaning, not good). (not full recipe).
A) leaking structured fully working complete set of files (full working recipe) that is not relevant to AI queries at all.
B) adhoc random queries, bits and pieces, grep of chunks of random files and local bash post-processing for AI queries at hand. which is hard to use for anyting anyways, and will end up in just corups of trainig data (CommonCrawl quality — meaning, not good). (not full recipe).
If you’re worried about this why are you using a third party AI in the first place?
Running any query in Claude or Codex could result in the AI reading/uploading any file in your codebase.
Running any query in Claude or Codex could result in the AI reading/uploading any file in your codebase.
key point: Grok is not even using the files they upload.
they send home entirety of codebase that they do not even use for user AI queries.
and why use cloud AI for coding? how is this even a question in 2026? if you don't, you can't compete with somone who does use it.
they send home entirety of codebase that they do not even use for user AI queries.
and why use cloud AI for coding? how is this even a question in 2026? if you don't, you can't compete with somone who does use it.
[deleted]
Possibly, but people were worried about this with cloud hosting when it first came out, and it turned out to be a total nonissue.
Not the same thing. Cloud hosting couldn't get away with stealing your stuff. They would lose all trust, which was far more valuable than any individual piece of content.
But AI is literally all about stealing and reselling content under the protection of "AI did it" and "whoopie, we'll take a slap on the wrist". It's reasonable to assume all of the frontier companies are doing this to the maximum extent they can get away with.
But AI is literally all about stealing and reselling content under the protection of "AI did it" and "whoopie, we'll take a slap on the wrist". It's reasonable to assume all of the frontier companies are doing this to the maximum extent they can get away with.
they are literally going after "creating everything app" and "everything business" (macrohard).
they are litearlly ingesting and integrating your app/business into theirs.
they are litearlly ingesting and integrating your app/business into theirs.
Yeah, I'm not sure the level of trust extended to a company like Amazon or Google will also be extended to one run by Elon Musk, who is notorious for not respecting terms like this.
I think it’s so people can “remote control” from their phones even if their computer is offline, via a container somewhere. Then they can get back to local dev, syncing the changes from their GCP bucket.
Seems reasonably useful to me - not give-Elon-my-entire-repo useful, but useful. The fact that they made it something you can’t opt out of and wasn’t disclosed at all really reinforces that they shouldn’t be trusted with it.
How do these findings compare to Codex, Claude code, and cursor
Cursor is the closest as it uploads your entire source code to build a search index.
SpaceX bought cursor, so one and same now
Oh and they just shipped Grok in Cursor. Yay.
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.
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?
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.
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.
But you also have handed over your secrets, dotfiles and API keys alongside with your source code to xAI.
I'm afraid you have been scammed.
I'm afraid you have been scammed.
A bit hyperbolic, no? A majority of code is now written through Claude and similar services.
How is it hyperbolic when it's literally the subject of the post? Did you not read the OP?
The "scam" part is the hyperbolic part
If I buy one thing and get a worse alternative, I usually call that a scam. $30k for a car, and it feels the need to summarize my location patterns and sell that to adtech agencies without bothering to even notify me? That's a scam. $X for a code generation tool, and it feels the need to ship all my passwords and other sensitive information to a known user-hostile entity? Also a scam. The fact that I can ~clip the antenna~ sandbox the malicious code doesn't make it not a scam; it might be a practical stopgap, but the offenders still basically got away with it.
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.
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.
Claude reads secrets all the time. It just also tells me when secrets enter context and reminds me that they should be rotated later.
> 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
This has to be the most successful mass surveillance campaign of all time
Downloading the SSN/tax/etc data from the entire US wasn't bad either.
since github. or you truly believed your code was private in private repos? I never understood that belief of a label on a button.
since jira-cloud, or you truly believed your processes were private?
leaks are assured, but centralisation amplifies impact. no one cares if your self-hosted something gets owned _because_ it does not affect anyone else.
...
since jira-cloud, or you truly believed your processes were private?
leaks are assured, but centralisation amplifies impact. no one cares if your self-hosted something gets owned _because_ it does not affect anyone else.
...
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.
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.
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.
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.
haha so they just stealing entire codebases?
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...
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...?
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 hard to force Chinese AI modesl to read full files, they really do not want to see them. even 400 lines files, is usally hit first for first line, first 50 lines. and at most 200 lines chunk reads, and give up at one or two reads.
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 hard to force Chinese AI modesl to read full files, they really do not want to see them. even 400 lines files, is usally hit first for first line, first 50 lines. and at most 200 lines chunk reads, and give up at one or two reads.
> none of them upload entirety of codebase or even attempt to.
How do you know? Did you do an analysis like OP did?
How do you know? Did you do an analysis like OP did?
no analysis. only based what I see in VSCode tool calls.
For me, them allowing API usage on coding plans so we can use any harness, and returning the full unabridged reasoning back are how they earned my trust.
same here. API access + low price is why I am using Chinese models
The second I opened Deepseek, it had my harness scan my entire home dir. Not sure what's worse here.
Weird. I have seen it asking the harness to do `find ~ -type f | grep` to try and find my agent configuration .json file when I asked it to add a MCP server. Stupid, but they weren't sending the files back home. This was with older models though. Newer ones are a bit smarter than that.
sam altman: aww you're sweet
elon musk: hello human resources
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.
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.
Mostly like enforcement is slow and I’m not even sure if someone has sent in a complaint.
The Nazi Mecha Hitler in action I guess…
The 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?
Have you verified this flag is respected?
I verified it statically that the config value is checked and skips the upload code if it is set to true. I don't have a subscription, so it would be cool if someone could verify it statically.
This is completely made up. The Grok Build CLI reference lists no such thing. Whatever LLM you asked probably hallucinated this.
>completely made up
If you want easily verifiable evidence, run strings on the Grok Build CLI binary and you will see:
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)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:
Config after fix (~/.grok/config.toml)
[harness]
disable_codebase_upload = true
[telemetry]
trace_upload = false
[features]
telemetry = false
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.