xAI Grok CLI Exposed Developer Code Through Automatic Whole-Repository Uploads

According to a reproducible wire-level analysis of version 0.2.93, xAI’s Grok Build CLI allegedly transmitted entire Git repositories, including unread files and commit history, to xAI infrastructure by default.

The researcher noted that the behavior also sent the contents of files accessed by the agent, including a test .env file containing simulated credentials, without redaction.

Independent researcher cereblab examined Grok Build traffic on macOS by routing the CLI through a controlled HTTPS interception proxy.

This analysis captured request hostnames, paths, sizes, response codes, and request bodies, using a disposable repository that contained uniquely identifiable canary strings instead of real secrets.

xAI Grok CLI Exposed Developer Code

The most serious finding was the use of a separate repository upload channel. In a test where Grok was explicitly instructed to respond with “OK” and not to access files, the researcher reported that the CLI uploaded a Git bundle via POST /v1/storage; cloning the captured bundle revealed an unread canary file and the complete Git history of the repository.

This test was reportedly replicated with a second, unrelated codebase, which is significant because a cloud coding agent typically transmits only the files it needs to reason about.

Uploading all tracked content and history independently of agent file access significantly broadens the potential exposure of sensitive information.

A scale test involving a 12 GB repository of random content that had never been accessed recorded at least 5.10 GiB transferred via/v1/storage in 73 chunks of approximately 75 MB each before the capture was manually halted.

All recorded storage uploads returned HTTP status 200. At the same time, model-response traffic during the session amounted to only 192 KB, highlighting a reported difference of approximately 27,800-fold.

The analysis also revealed that when Grok accessed a file, its contents were included verbatim in requests to /v1/responses. A test .env file containing fake API keys and database password canaries was found both in the model-turn request body and in a staged session state archive meant for storage upload.

The researcher emphasized an essential limitation: the test confirmed the unredacted transmission of the specific canary values used, but did not establish the absence of all possible secret-redaction mechanisms. It also did not determine whether .gitignore-excluded files were included in repository snapshots.

Binary strings and captured metadata indicated a Google Cloud Storage bucket named grok-code-session-traces, with staged file identifiers referencing `gs://grok-code-session-traces/…`.

The analysis also identified local staging under `~/.grok/upload_queue`, which the researcher warned could consume significant disk space during large uploads.

The report stated that turning off the consumer-facing “Improve the model” option did not prevent the observed codebase uploads in its tests: a server settings response reportedly maintained `trace_upload_enabled: true`, and a Git-bundle upload still occurred after the option was disabled.

However, the evidence does not definitively establish that xAI trained models on the uploaded material; it only demonstrates transmission, successful storage requests, and local staging behavior.

In an update added on July 14, cereblab noted that xAI had disabled the code-upload mechanism on the server side by setting `disable_codebase_upload: true`.

The researcher also indicated that xAI added a privacy opt-out option. However, it was described as a data-retention setting rather than a control to prevent data transmission. The update also mentioned Elon Musk’s public commitment to delete previously uploaded data, which had not yet been independently confirmed to have been completed.

Use the following snippet to safely route Grok Build through a local interception proxy in a controlled test repository. Avoid using it against systems or repositories that you do not own.

# Install and start mitmproxy in a separate terminal
brew install mitmproxy
mitmdump -p 8080

# Trust the locally generated mitmproxy CA on macOS
security add-trusted-cert -r trustRoot \
  -k ~/Library/Keychains/login.keychain-db \
  ~/.mitmproxy/mitmproxy-ca-cert.pem

# Run Grok Build through the local proxy against a test repository
HTTPS_PROXY=http://127.0.0.1:8080 \
SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem \
grok -p "Reply exactly OK. Do not read or open any files." \
  --cwd /path/to/test-repository

The analysis referenced utilized this specific controlled proxy setup to examine the outbound requests made by the Grok Build CLI and to test for repository-upload behavior.

For security teams, this incident underscores the importance of treating AI coding CLIs as high-trust software that may have access to source code, secrets, build artifacts, and Git history.

Until behavior is independently verified in an organization’s environment, developers should use isolated repositories, remove secrets from tracked history, rotate any credentials that may have been exposed, and implement egress monitoring for AI-agent endpoints.

Gain browser-level visibility to expose decrypted phishing pages, speed investigations, and cut credential theft costs -> Power your SOC with ANY.RUN