xAI's Grok CLI Secretly Uploads Your Entire Codebase and Secrets

What xAI's Grok Build CLI Actually Sends to xAI

I conducted a wire-level analysis of the Grok Build CLI and discovered it transmits file contents, including unredacted .env secrets, directly to xAI. Furthermore, the tool uploads your entire repository, including git history, to a Google Cloud Storage bucket regardless of what files the AI agent actually reads. This data transmission happens by default and persists even when you disable the 'Improve the model' setting.

None of this proves xAI trains on the data — that is a policy question addressed in §6. What is proven is transmission, acceptance, and storage.
  1. phaseleza

    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.

  2. kordlessagain

    Mitigation for use:

    ```

    export GROK_TELEMETRY_TRACE_UPLOAD=0

    export GROK_TELEMETRY_ENABLED=0

    # or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true

    ```

    The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each Grok Build invocation, not just files you ask it to read, and no visible setting stops it.

    I've built Nemesis8 (n8) for blast radius control and monitoring these sorts of things, from containers: https://github.com/deepbluedynamics/nemesis8

    I've added the mitigation above to the image build for Grok Build instances. There is a lot of telemetry already turned on in n8 containers, so will investigate further.

  3. gitgud

    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…

  4. theplumber

    A lot of people are now upset because xai is running a bulk upload instead of a stream upload like oai or Anthropic.

    Suddenly they became aware that the AI agents are not actually running on their computers. AI agents are just uploading the shit on some servers for how long they want and in exchange of that you pay them and get some work done.

    I am surprised through that nobody is asking if the agents are GDRP compliant or if they are even legal considering they are trained with illegal/copyrighted content or if you are liable for theft because now you own, publish and sell illegal content generated by agents….

    Enough ranting…instead of this stuff people should just admit that after social media, AI is the new frontier towards a kind of zero privacy, at least until you can have local AI/if ever.

  5. freakynit

    "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.

  6. Geee

    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.

  7. j_bum

    I wish a human would’ve written the overview.

    Nonetheless, this is disturbing.

  8. Karmakosmik

    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?

More from this day

2026-07-12