xAI Grok CLI Secretly Uploads Entire Codebase and User API Keys to Google Cloud Storage

Forum topic · 小凯 · 2026-07-13

Summary

Security researcher cereblab published wire-level packet captures on July 13 showing that xAI's official Grok Build CLI (npm package @xai-official/grok, version 0.2.93) bundles the current working directory into before_codebase.tar.gz and after_codebase.tar.gz files and uploads them via a side-channel POST endpoint to a Google Cloud Storage bucket named grok-code-session-traces. The uploads occur before and after every task regardless of tool usage. The archives also include external files such as ~/.claude.json, Claude Code global configuration, Skill files, and API keys like MIAODA_API_KEY from .claude/settings.local.json. After researcher mylifcc publicized the same finding on July 12, xAI added a server-side disable_codebase_upload=true flag on July 13 while preserving trace_upload_enabled=true; the client binary hash was unchanged, leaving a hidden kill switch to resume uploads. The onboarding toggle labeled "Improve the model" controls training opt-in, not data egress, and is misleading users. This report compares the privacy posture of Grok CLI, Claude Code, and Codex, and warns that AI agent tools now wield OS-level permissions without equivalent audit frameworks.

Key points

Silent side-channel uploads: Wire-level captures show @xai-official/grok@0.2.93 POSTs before_codebase.tar.gz and after_codebase.tar.gz to Google Cloud Storage gs://grok-code-session-traces before and after every task, regardless of whether the model uses file tools or even when it replies with a single word.
Scope far exceeds model file reads: A canary file that the agent never accessed was retrieved intact from the GCS bucket, proving the upload scope is "anything in the working directory," not "files the model actually read."
External configs and secrets harvested: When Grok CLI scanned ~/.claude/ to support Claude Code migration, it packaged those files as supplemental_file entries, including .claude/settings.local.json containing MIAODA_API_KEY.
Magnitude: A 12 GB test repository produced 5.10 GB of successful uploads across 73 chunks and 83 HTTP 200 responses, making the upload channel roughly 27,800× the volume of the model-call channel.
Misleading privacy toggle: The onboarding option labeled "Improve the model" maps to improve_model_opt_in=false while trace_upload_enabled remained true. Uploads continued with the toggle off.
Server-side rollback with hidden reactivation path: On July 13 xAI added a server-controlled disable_codebase_upload=true field without changing the client binary hash, meaning xAI can flip the field back at any time and all users will resume uploading unknowingly.
No xAI statement: As of publication, xAI has issued no official statement or third-party audit commitment (SOC 2 / ISO 27001).

Industry comparison

| Vendor | CLI | Default behavior | User visibility | Known privacy incidents | |---|---|---|---|---| | Anthropic | Claude Code | No independent upload channel outside model context | Low | 6/30 steganography tagging of Chinese users (no data exfiltration) | | OpenAI | Codex | No independent upload channel outside model context | High (clear training opt-out) | None | | xAI | Grok Build | Full codebase + external configs uploaded to a GCS bucket | Zero (toggle semantics decoupled from upload behavior) | 7/13 wire-level proof + silent server-side rollback |

Systemic concern: AI agents at OS-level privilege without audit frameworks

AI agent CLIs today can execute shell commands, scan filesystems, and control browsers — privileges historically reserved for operating systems and antivirus software, which are governed by SELinux, AppArmor, code signing, TPM, VirusTotal, and ICSA Labs certification. No comparable standards exist for AI agents: no requirement to disclose local file reads, no mandate for explicit consent before uploads, and no third-party audits of local behavior.

Confirmed worst-case outcomes

All data uploaded before the July 13 server-side change remains in the GCS bucket; xAI has not disclosed retention, deletion, or downstream use.
Closing the CLI does not retroactively remove already-uploaded codebases or secrets.
Training use has not been proven, but the existence of the bucket makes training use technically zero-cost.

Immediate actions for developers

1. Uninstall: npm uninstall -g @xai-official/grok. 2. Treat all API keys, SSH keys, and tokens that ever coexisted with Grok CLI as compromised and rotate immediately. Critical paths: .env, ~/.aws/credentials, ~/.config/gh/hosts.yml, ~/.ssh/, ~/.claude/. 3. Move sensitive credential files out of standard paths before launching any AI agent CLI. 4. Audit outbound traffic from developer machines for unsanctioned POSTs to cli-chat-proxy.grok.com and gs://grok-code-session-traces.

Open questions

Will xAI publish a statement, delete all GCS data, and commission a third-party audit?
Will other agent vendors (Anthropic, OpenAI, Cognition, Cursor) face independent audits of their local CLI behavior?
How will Chinese regulators, which recently issued advisories on Claude Code, respond to Grok CLI?

Sources

数字生命卡兹克 deep reconstruction: https://mp.weixin.qq.com/s/6c6vGMJAVMbh6UhNVw4dcg
cereblab packet analysis (byteiota mirror): https://byteiota.com/grok-build-cli-uploads-repo-xai-servers