Developers report Grok CLI uploaded private repos without consent

• Developers reported involuntary uploads of private repos through Grok CLI, with Gergely Orosz's initial post saying devs contacted him after codebases were uploaded without consent.
• The strongest technical evidence is cereblab's wire-level analysis, which scaling01's summary framed as two leak surfaces: read files sent verbatim, plus a whole-repo storage upload.
• xAI's own API security docs say non-ZDR API requests and responses are stored for 30 days, and altryne's screenshot captured the enterprise-only ZDR language.
• The opt-out story split from the storage story: Gergely Orosz's ZDR post focused on data-retention defaults, while the wire analysis said turning off “Improve the model” did not stop repo upload.
• Follow-up testing points to a quiet server-side shutdown of the upload path, but the linked analysis remains the historical artifact people are citing.

cereblab's gist has the useful nasty bit: /v1/responses carried files the agent read, while /v1/storage carried a repo bundle. The repro repo includes a mitmproxy harness, canary repos, and captured bundles. xAI's enterprise deployment docs describe a six-phase Grok Build data lifecycle for ZDR organizations; the public changelog listed v0.2.98 on July 12 without an incident note about repo uploads.

Orosz said multiple developers contacted him after Grok CLI uploaded codebases without their knowledge or consent. He described the trust impact bluntly: “Trust burnt like there’s no tomorrow.”

The concern spread beyond a single report. Gergely also connected the issue to Cursor's pending Grok exposure, asking who would trust Cursor with serious work if Cursor “becomes Grok” in a reply about Cursor.

The default posture was the part engineers latched onto. In dbreunig's phrasing, “upload all your code, even if you're not working on it, unless you specifically opt out” was a wild position dbreunig's reaction.

The linked wire-level analysis tested Grok Build CLI 0.2.93 on a normal consumer login and separated the traffic into two paths:

1. Model-turn payload: files Grok read were serialized into POST /v1/responses; the analysis says a .env secrets file was sent verbatim and unredacted.
2. Storage snapshot: Grok packaged tracked repository files plus git history and sent them through POST /v1/storage to a Google Cloud Storage bucket named grok-code-session-traces.

The analysis explicitly says it proves transmission, acceptance, and storage, not training. That distinction matters because xAI's API security FAQ says xAI does not train on API inputs or outputs without explicit permission.

The cleanest evidence was a byte-count mismatch. In a 12 GB random-file repo, cereblab's analysis says /v1/responses moved 196,705 bytes, while /v1/storage moved 5.10 GiB before the capture stopped.

That is the source of the 27,800x claim. The model-turn channel was small enough to rule out bulk file ingestion there; the storage channel was large enough to track the repo, not the prompt.

The same analysis says the repo snapshot was recovered as a git bundle. A never-read canary file appeared verbatim after cloning the captured bundle, and a second unrelated repo reproduced the same pattern.

The comic version was accurate enough to sting: Grok CLI on one side, a Google Cloud bucket on the other.

xAI's public API security docs say requests and responses are stored for 30 days for abuse auditing unless Zero Data Retention is enabled. The same docs say ZDR is “exclusively available to enterprise accounts” and adds an x-zero-data-retention response header.

The Grok Build question was narrower than model training. The wire analysis said disabling “Improve the model” left trace_upload_enabled: true and did not stop the repo snapshot path.

xAI's Responses API docs also describe server-side state as on by default for continuations, with local storage requiring store: false. That is API behavior, not proof of Grok Build's CLI storage path, but it shows why engineers immediately asked which retention layer applied.

Orosz contrasted Grok with Cursor because the Cursor architecture he previously documented used indexing and embeddings rather than storing raw source on the backend. The Pragmatic Engineer Cursor article says Cursor's chat works by using codebase indexes, with no source code stored on the backend.

That comparison turned the incident into a harness-design story. Sending relevant context for a model turn is expected; uploading a full repo snapshot plus git history is the behavior that changed the trust calculation.

Teknium said Hermes was not the component doing the Grok CLI upload. His distinction: Hermes sends the same conversation context regardless of API, while ZDR settings are controlled at the provider account layer.

Teknium's follow-up made the boundary even narrower: Hermes does not upload repos or other extra data on behalf of users, and it cannot control xAI's retention policy. In later replies, Teknium also said Hermes does not send “random extra data” to Grok, Google Cloud, or xAI in one reply in another reply.

Orosz framed the incident as free advertising for open-source coding harnesses. His argument was simple: an open harness cannot add a hidden repo-upload path without someone noticing, absent “next-level hacking” in a follow-up.

The Hacker News thread around the wire-level analysis moved in the same direction, with commenters discussing filesystem and network sandboxing for coding agents. Ben Hylak put the hardline version in one sentence: arbitrary hard-drive file upload is malware Ben Hylak's reaction.

Penligent's follow-up says later runs of the same Grok Build 0.2.93 client returned a new disable_codebase_upload: true flag, and the prior /v1/storage repo uploads were no longer observed.

The repro repo's comparison note says six July 13 capture runs saw zero POST /v1/storage uploads, with trace_upload_enabled: false and disable_codebase_upload: true visible on the wire.

xAI's v0.2.98 changelog listed auth pinning, /context token costs, terminal setup changes, and tool-flow fixes. It did not list a repo-upload incident, deletion status for prior uploads, or a scope statement for the server-side change.