xAI Grok Build CLI uploads full repo and .env secrets by default

Developers using xAI’s Grok Build CLI assume the tool only sends the snippets it reads to the model. A recent wire‑level teardown shows the binary uploads the entire repository—including every tracked file and its Git history—as well as raw .env contents. The data is sent to a Google Cloud Storage bucket named grok‑code‑session‑traces and is not mentioned in the official docs. Because the upload happens by default, even “disable improve the model” settings do not stop it. This behavior has immediate privacy and compliance implications for anyone handling sensitive code.

What happened

The analysis captured traffic from version 0.2.93 of the Grok CLI. When a user runs a normal build, the tool makes two distinct HTTP calls: a POST to /v1/responses that includes the live model turn, and a POST to /v1/storage that uploads a session_state archive. The archive contains the verbatim contents of every file read—including .env files—and a full Git bundle of the repository. In a test with a 12 GB repository, the storage endpoint transferred over 5 GiB while the model‑turn channel transferred only 192 KB, confirming that the bulk upload is independent of what the model actually reads.

The storage endpoint resolves to a Google Cloud Storage bucket (gs://grok-code-session-traces/…) hard‑coded in the binary. The upload is enabled by default; the CLI reports trace_upload_enabled: true even when the “Improve the model” flag is turned off. No failures were observed for storage uploads, and the only non‑200 responses were unrelated quota errors on the model‑turn endpoint.

Why it matters

Sending an entire codebase—including secrets—to a remote bucket creates a clear vector for data leakage. Organizations that store proprietary algorithms, confidential APIs, or regulated data could inadvertently expose themselves to compliance violations. Even if xAI does not currently use the uploaded data for model training, the mere possession of raw source and environment variables raises legal and trust concerns. Developers need to understand that the CLI’s default behavior bypasses typical security controls and that existing documentation does not disclose this telemetry.

How to think about it

Treat the Grok CLI as a potentially untrusted data exporter. Before running it on sensitive code, isolate the execution environment with a sandbox (e.g., bwrap or gvisor) and mount a filtered network namespace that only permits connections to the LLM provider. Remove or encrypt .env files and any other secret material from the repository prior to invocation. Consider wrapping the CLI in a script that intercepts the storage POST and redirects it to a controlled endpoint, or use a proxy that blocks uploads to grok-code-session-traces. Finally, audit the binary for hard‑coded endpoints and verify that any opt‑out flags are truly effective.

FAQ