xAI's Grok Build CLI Uploads Git Repositories to a Google Cloud Bucket

TL;DR Highlight

Packet captures showed Grok Build CLI uploading whole repos; a silent server-side flag then stopped it

Who Should Read

Developers and security owners planning to run AI coding CLIs against private internal codebases

Core Mechanics

The whole repository was uploaded
- Researcher cereblab captured Grok Build CLI 0.2.93 on macOS with mitmproxy.
- All tracked files plus full Git history went to a bucket named grok-code-session-traces.
Upload was about 26,000x the task traffic
- On a 12 GB test repo, the model request channel carried about 192 KB.
- The storage upload carried roughly 5.1 GB.
Uploads were independent of files the agent opened
- The upload ran regardless of which files the agent actually opened for its coding task.
Secrets left unredacted
- A canary credential (a fake key planted to detect leaks) in .env appeared verbatim in the captured traffic.
Turning off "Improve the model" did not help
- With the toggle off, the server still returned trace_upload_enabled: true and uploads continued.
- The setting covers training consent, not whether code leaves the machine.

Community Reactions

Earlier HN discussion exists
- A note says the behavior was first discussed in the post "What xAI's Grok build CLI sends to xAI: A wire-level analysis", which drew 203 comments.
- This article covers the follow-up retest.

How to Apply

Capture AI CLI traffic with mitmproxy
- Before adopting a new coding agent CLI, run it against an empty test repo with a fake .env behind mitmproxy.
- Check for the fake key string and the upload volume to non-model hosts.
Plant a canary secret before real code
- Put an identifiable fake key in the test repo's .env.
- If it shows up in captures, do not use the tool on internal code.
Restrict egress instead of trusting toggles
- Allowlist the domains AI CLIs may reach from dev environments.
- Block storage uploads to anything besides the model API.

Try It

copy & run

# Paste into Claude or ChatGPT: pre-adoption data-exfiltration check plan for an AI coding CLI (simplified version of the captures in the article)

Before using the AI coding CLI "{{CLI name}}" on internal code, I want to audit it.
I plan to capture traffic with mitmproxy. My OS is {{OS}}.

Give me step by step:
1. Commands to create an empty test repo and a fake .env (canary key)
2. How to configure mitmproxy to intercept the CLI's HTTPS traffic
3. What to check in captures: whether the canary key leaves in plaintext, upload volume to non-model storage hosts, and differences when settings toggles are off
4. A checklist to judge the result

Next to try: paste the capture summary and ask for a verdict on exfiltration and risk

Terminology

mitmproxyA proxy that intercepts HTTPS traffic so you can read it. Like a mail carrier who opens the letters.

Canary credentialA fake key planted on purpose to detect leaks. It acts like a canary in a coal mine.

Git historyAll past commits in a repo. Deleted files and old secrets can still live there.

Server-side flagA config value the server sends down, so behavior can change without a client update. Users have a hard time noticing the change.