The Grok CLI Data Leak: What Was Uploaded and What to Do Now
AI coding tools are supposed to help you move faster. What they're not supposed to do is silently package your entire repository, including years of git history and any secrets that were ever committed, and upload it to a cloud storage bucket you never consented to. That's what xAI's Grok Build CLI was doing, and it took an independent security researcher intercepting the tool's network traffic to prove it.
This article covers how the leak was discovered, what the wire-level investigation found, what data was actually exposed, how to check if your repositories were affected, and what xAI's response actually fixes, and what it doesn't.
The discovery
The story broke not through an official disclosure but through a tweet from a user named CyberSatoshi urging anyone who had used Grok Build to run a specific log check.
The command was:
Developers who ran it found log entries containing repo_state.upload.start, confirming that their repositories had been packaged and sent to xAI's servers. One user reported something worse: they had run Grok Build from their home directory, and the logs showed their entire home folder had been uploaded, including SSH keys, a password manager database, personal documents, and photos.
This wasn't a minor telemetry issue. It was a tool marketed as "local-first" actively exfiltrating private data at scale.
The wire-level investigation
The definitive technical account came from cereblab, an independent AI safety researcher who routed Grok Build's network traffic through mitmproxy to intercept and analyze every request leaving the machine. The full analysis is published on GitHub.
The experiment
The setup was deliberately minimal. The researcher gave Grok an idle prompt, "reply OK, do not open any files," and planted a canary file called never_read.txt in the test repository. The logic: if the tool behaves as advertised, nothing beyond the prompt itself should leave the machine.
What the logs showed
The results were unambiguous. Despite the idle prompt, Grok made a POST request to a /v1/storage endpoint. The payload was a complete v2 git bundle.
A git bundle is a single-file archive containing a repository's complete history: every commit, every branch, every file version ever tracked. The researcher extracted the captured bundle and cloned it back into a full repository. It was a verbatim copy of the original, and it contained never_read.txt. The canary file the tool was explicitly told not to open was present in the uploaded archive.
The behavior was unambiguous: Grok was ignoring user instructions, running background uploads without initiation, and sending the full repository including all git history to xAI's cloud storage.
What data was exposed
The severity of this incident comes from what a git bundle actually contains. Developers routinely clean their commit history, removing API keys or credentials that were accidentally committed. Those credentials are gone from the current codebase but they remain in older commits. By uploading the full git bundle, Grok resurrected that history and sent it to xAI's servers.
Beyond git history, the investigation confirmed that local .env files were also being read and their contents sent to a separate /v1/responses endpoint. Even developers with a clean git history could have had their active credentials exposed.
To put this in context, the researcher ran the same analysis on other AI coding tools.
Claude Code, Codex, and Gemini all behaved as expected, transmitting only the contents of files directly relevant to the task at hand. Grok's behavior was a unique deviation from what every other major tool in this space does.
How to check if your data was uploaded
If you've used Grok Build, run the following command to check your logs:
cat reads the log file at ~/.grok/logs/unified.json. The pipe passes that output to grep, which searches for lines containing repo_state.upload.
If the command returns no output, no matching events were found in your logs. If it returns one or more lines, each represents an upload event. The log entries will include the path to the repository that was uploaded.
If you find matches: any credentials that were ever committed to the affected repositories, even if later removed, should be treated as potentially compromised and rotated. This includes API keys, database passwords, cloud provider tokens, SSH keys, and webhook secrets. Deleting the local file doesn't help because the git history that left your machine already contained it.
xAI's response
The server-side kill switch
Before any public statement, xAI made a quiet server-side change. The /v1/settings endpoint, which the CLI calls on startup to get its configuration, began returning two new flags:
trace_upload_enabled: falsedisable_codebase_upload: true
This effectively stopped all clients from triggering the upload. It was fast and it worked, but it was a server-side toggle, not a code change. The upload code itself was still in the binary.
The public statement
xAI followed with a public statement affirming their commitment to privacy and introducing a /privacy command in the CLI for managing data retention settings. Elon Musk separately committed to deleting all previously uploaded user data.
Open-sourcing the codebase
On July 15, 2026, xAI went further, publishing the full Grok Build source code on GitHub under the Apache 2.0 license. The codebase is approximately 844,530 lines of Rust covering the agent loop, tools, terminal UI, and extension system. The tool can now be built from source and pointed at a local inference endpoint.
What the fix actually does and doesn't do
The /privacy command controls retention, not transmission
The /privacy opt-out command sends a request to set {"codingDataRetentionOptOut": true} on xAI's servers.
This is a retention setting, not a transmission block. Your data still leaves your machine. The difference is how the server responds: with opt-out enabled, it returns a 204 No Content instead of 200 OK, indicating the data was received and discarded. You are still trusting xAI's servers to honor the flag and actually discard the data.
The upload code is still in the published source
When researchers inspected the open-sourced repository, they confirmed the exfiltration code is still present. It's disabled by the server-side disable_codebase_upload flag, not removed. That means the current protection depends entirely on xAI keeping that flag set. A future configuration change, whether deliberate or accidental, could re-enable the behavior for all users without any client update. A full fix would remove the upload code from the binary so the behavior becomes architecturally impossible. That hasn't happened.
The open-sourcing is a meaningful transparency step, and the ability to build locally and point the tool at your own inference endpoint is a genuine improvement. But developers who want to verify behavior should know that the code capable of uploading their repositories is still there, held off by a remote configuration flag they can't control.
What to do going forward
If you ran Grok Build before July 13, 2026, treat any credentials that ever appeared in tracked files or git history in the affected repositories as potentially compromised and rotate them. Check your logs with the command above to identify which repositories were affected.
For any AI coding tool going forward, it's worth understanding what data leaves your machine before giving it access to a codebase with real credentials. The cereblab analysis used mitmproxy to capture and inspect all outbound traffic, and the reproduction repository is publicly available if you want to run the same test against any tool yourself.
The Grok incident is a useful reminder that "local-first" is a marketing claim, not a technical guarantee. The only way to verify it is to check the traffic.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.