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.
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...
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.
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.
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.
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
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.
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?
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.
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.
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 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.
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.
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:
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.
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.
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 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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
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...
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...
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.
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.
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
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.
And I run most of them inside sandbox now.
Why would you let a markdown linter access your ssh keys?
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?
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.
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.
What's your mechanism for doing this?
> 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
Downloading the SSN/tax/etc data from the entire US wasn't bad either.
Do people really trust that guy or any service he owns?! Actually never mind I forgot there’s always fools in this world
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.
Sure bud … carry on
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…
I'm using my own agent, but i can't risk blocking the company account with it.....
> 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.
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.
Yeah. Not the Desktop App though.
its an electron app you an inspect it
last time I checked, codex is still open source w Apache-2.0 license
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 ```
I wish a human would’ve written the overview.
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.
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.
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.
exactly. looks like this is what they doing
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 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.
Even if it's uploaded once, it's still being ran through inference. It saves a bit of HTTP traffic I suppose.
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.
Claude reads secrets all the time. It just also tells me when secrets enter context and reminds me that they should be rotated later.
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
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.
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.
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.
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).
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.
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.
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.
they are literally going after "creating everything app" and "everything business" (macrohard).
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.
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
None of them upload the whole repo, which is what this link claims it does. That's unheard of.
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.
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.
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.
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.
haha so they just stealing entire codebases?
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...
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.
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.
> none of them upload entirety of codebase or even attempt to.
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.
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.
The simplest way to disable uploading your repo is disabling it in the config.
> simplest way to disable uploading your repo is disabling it in the config
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: