needhelp
← Back to blog

Grok Build CLI Quietly Uploaded Your Whole Repo — .env Files Included

by needhelp
Security
AI Agent
Privacy
xAI

A researcher going by cereblab found that xAI’s Grok Build CLI, version 0.2.93, was copying entire git repositories — secrets, full history, everything — to a Google Cloud Storage bucket without telling the user.

What happened

The tool made two kinds of outbound requests. Model turns went to POST /v1/responses. But a separate POST /v1/storage call bundled the entire working tree plus the full .git history and shipped it to gs://grok-code-session-traces.

That bucket is owned by xAI. The upload ran as a side effect of simply using the CLI — no “export” button, no prompt, no warning.

The numbers are staggering. With a 12 GB test repo and no files actually read by the model, /v1/responses transmitted ~192 KB. /v1/storage sent 5.10 GiB across 73 chunks. That’s a 27,800× gap. The model used 192 KB of context; xAI’s servers got your whole repo.

The canary test

cereblab planted a file called never_read_canary.txt with a unique string. The prompt was literally “Reply with exactly: OK. Do not read or open any files.” The model complied with the text. The canary string was recovered from the uploaded bundle.

So the exfiltration wasn’t driven by the model reading files on demand. It was a built-in pipeline that ran regardless of what you asked.

Why opting out didn’t work

There’s a setting called “Improve the model.” Turning it off is supposed to stop training use of your data. cereblab’s capture showed the server still returned trace_upload_enabled: true and upload_enabled: true. The upload kept happening.

The CLI has a --deny flag that restricts which files the model can read. That only blocks reads. It does nothing about network egress — the bundle was already on its way out.

The gist puts the conclusion bluntly: “Opting out does not stop your repository from leaving the machine.”

The cross-tool leak

The capture showed the tool also swept up files under ~/.claude/. That’s a different product’s config directory. Keys for unrelated services — cereblab cites a Baidu Miaoda API key — left the machine along with your repo.

Another researcher who reproduced the findings discovered 339 automatic uploads in their logs. One of those uploads contained their entire home directory — potentially exposing SSH keys, password manager data, browser profiles, everything.

The remote kill switch

On July 12, as the story went viral, something happened that xAI never announced: the same client binary, with the same SHA-256 hash, suddenly started receiving different server responses.

disable_codebase_upload: true. trace_upload_enabled: false.

Uploads stopped. No client update. No changelog. No notification.

This means xAI has always had the ability to remotely enable or disable data collection on any Grok CLI installation, at any time, without the user knowing. They just chose to leave it on by default and never mention it.

Musk responds

On July 14, Elon Musk replied to the controversy with a single word: “True.” He followed up:

“As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain.”

xAI simultaneously announced a /privacy command for the Grok CLI:

  • /privacy — shows your current data retention status
  • /privacy opt-out — disables retention and triggers retrospective deletion of already-synced data

Andrew Milich, head of Grok Build, confirmed that changing privacy settings triggers deletion of previously synced cloud data. Enterprise customers get “Zero Data Retention” (ZDR) mode.

But here’s what hasn’t changed: no security advisory was issued. No explanation for why entire repositories were collected without consent. No independent audit of the deletion. The v0.2.98 changelog omitted any mention of repository uploads entirely.

How to check if you were affected

  • Run the CLI behind a MITM proxy: HTTPS_PROXY=http://127.0.0.1:8080. Watch for POST /v1/storage hitting the grok-code-session-traces bucket.
  • Search the binary / strings for the hardcoded bucket name grok-code-session-traces.
  • cereblab’s repro repo ships a verify.sh that re-downloads and unpacks the returned bundles so you can see exactly what left.
  • Check outbound egress logs for traffic to Google Cloud Storage during any Grok CLI session.
  • Run /privacy in the Grok CLI to see your current data retention status.
  • Another researcher found 339 uploads by checking their own logs — if you’ve used the tool at all, assume your repos left the machine.

What to do

  • Run /privacy opt-out immediately to disable further data retention and request deletion of already-uploaded data.
  • Uninstall the affected version (0.2.93) entirely.
  • Block egress to Google Cloud Storage at the network layer — a firewall rule or a Clash reject rule: (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com).
  • If you must keep using it, add to ~/.grok/config.toml: 
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • Rotate every credential that ever sat in a repo you opened with this version. .env files are often tracked or live in the working tree, and .gitignore does not protect you — the bundle carried tracked files regardless. Treat everything as compromised.

Data can be deleted. Trust, not so easily.

References

Share this page