This photograph shows a smartphone bearing the logo of Grok, a generative artificial intelligence chatbot developed by US artificial intelligence company xAI in front of a European Union flag in Brussels on January 12, 2026. Nicolas TUCAT/Getty Images

A security researcher's wire-level analysis published July 12 proved that xAI's Grok Build CLI was packaging developers' entire tracked repositories — full Git history, committed secrets, and all — and sending them to a Google Cloud Storage bucket, at a volume roughly 27,800 times greater than the data the coding task actually required. The analysis reached the front page of Hacker News on July 14 and prompted Elon Musk to promise deletion of all previously uploaded user data. No formal security advisory has been issued. The upload code remains in the current binary.

Developers who ran the tool on codebases containing real API keys, database passwords, or cloud tokens should treat those credentials as potentially exposed and rotate them immediately — regardless of what their privacy settings said at the time.

What the Wire Capture Found

The analysis was conducted by a researcher publishing under the handle cereblab, who routed Grok Build CLI version 0.2.93 through the open-source mitmproxy interception proxy on macOS and released the complete network captures as a public GitHub Gist.

The method requires no jailbreak and no elevated access. Because Grok Build CLI does not certificate-pin against mitmproxy's custom certificate authority, any developer can replicate the audit by routing the tool through the same proxy and reviewing what actually crosses the network. That low barrier to verification is part of why the findings spread quickly.

The central finding was a channel mismatch that is difficult to explain as incidental telemetry. On a 12 GB test repository, Grok's live model-turn channel — POST /v1/responses, which receives the files the agent actually reads to answer coding questions — moved approximately 192 KB. A parallel channel, routing to POST /v1/storage, moved 5.10 gigabytes across 73 chunks, each approximately 75 MB, every one of which returned HTTP 200. That storage upload ran regardless of which files the agent opened or was instructed to read.

The destination was a Google Cloud Storage bucket named grok-code-session-traces, accessed under paths of the form gs://grok-code-session-traces/repo_changes_dedup/v2/…. Neither the bucket nor the upload behavior appeared in Grok Build's setup documentation or quickstart materials at the time of the analysis.

To make the finding unambiguous, cereblab planted unique canary markers throughout the test repository. A .env file contained API_KEY=CANARY7F3A9-SECRET-should-not-leave and a mock database password. Both appeared verbatim and unredacted in the captured traffic — in both the live model-turn channel and in a session_state archive routed to the storage bucket. The researcher then cloned the captured Git bundle and recovered a file — src/_probe/never_read_canary.txt — that the agent had been explicitly instructed not to open. Its unique marker was intact. The upload was not scoped to what Grok accessed; it covered everything tracked in the workspace.

The Git bundle format carries additional risk that the storage volume alone does not capture. A Git bundle is a single-file representation of a repository's complete object history — every commit, every version of every file, including secrets that were committed and later removed from the working tree, as documented in the official Git bundle documentation. Deleting a .env file from the repository does not remove its contents from the bundle if it was ever committed. That history traveled with every upload.

What the Privacy Toggle Actually Controls

Perhaps the most consequential finding beyond the data volume was what could not stop the uploads.

Disabling the "Improve the model" setting — the primary user-facing privacy control in Grok Build — had no effect on the repository upload. After cereblab toggled the setting off and reran the CLI, the /v1/settings endpoint continued returning trace_upload_enabled: true, and the storage channel continued accepting chunked Git-bundle uploads without interruption.

This matters because the "Improve the model" toggle and the storage upload address different things at the architecture level. Training consent controls whether xAI uses data to improve future versions of the model. Data transmission controls whether the data leaves the developer's machine in the first place. These are two separate mechanisms, and Grok Build had only one of them exposed to the user. Developers who believed they had opted out of data collection by disabling model improvement had not stopped their codebases from being uploaded — they had only withheld consent for a specific downstream use of data that was already leaving their machines.

This architectural distinction is not unique to Grok Build. Any AI coding tool can, in principle, separate training consent from transmission scope. What made Grok Build exceptional was the combination: transmitting at 27,800 times the volume required for the coding task, persisting the data to a named storage bucket, and providing no separate, documented control for the storage upload itself.

xAI Responds on Social Media; No Advisory Follows

On July 13 — the day after the analysis went public — cereblab retested the same version 0.2.93 binary and found the upload behavior had stopped. The server now returned disable_codebase_upload: true alongside trace_upload_enabled: false. Across six separate retests, no repository uploads were observed. Peter Dedene, a developer who independently tested the tool, reported the same server flag returning on his account, establishing that the server-side change was not confined to a single machine.

The manner of the fix raised its own concerns. The mitigation was applied remotely and invisibly, with no client-side software update, no changelog entry, and no public announcement. The official changelog listed version 0.2.98 as the latest release on July 12 — the day before the shutdown — without any reference to repository-upload behavior. A subsequent analysis of version 0.2.99, current at the time of disclosure, found the upload code still present in the compiled binary, held off only by the server-side flag. That means xAI retains the technical ability to re-enable uploads for any or all users without issuing a software update.

xAI employees responded to the disclosure on X, disputing the characterization that the company was indefinitely retaining uploaded code. They stated that Grok Build has supported Zero Data Retention (ZDR) since launch, and that users without ZDR enabled can run the /privacy command to change their preference and trigger retroactive deletion of previously synced data. Andrew Milich, head of Grok Build, confirmed that modifying privacy settings would result in the system deleting previously synchronized data retroactively.

ZDR, as currently structured, covers enterprise teams and users accessing Grok Build via API key. For individual subscribers on SuperGrok or X Premium Plus — the access tiers most individual developers use — the /privacy command is the only self-service control offered.

Elon Musk went further on July 13, posting to X: "As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. Zero anything whatsoever will remain." He acknowledged that retaining some data is useful for debugging, but confirmed the full deletion would proceed regardless.

That commitment had not been independently verified as of July 14. xAI has not published a timeline for the deletion, a method for users to confirm their data has been removed, a breakdown of how many users were affected, or a description of which repositories were captured.

What the Analysis Proves — and Does Not

The cereblab report is careful to delineate the boundaries of its findings.

The captured wire traffic proves transmission, acceptance, and storage. It does not prove that xAI trained models on the uploaded code, that employees accessed the stored repositories, or that gitignored files were swept into the bundle — the upload mechanism appears to be driven by the file_access_tracker crate and appears to cover tracked files plus commit history, but gitignored and uncommitted files were not separately tested. The canary credentials used were formatted strings rather than high-entropy tokens, so the analysis does not establish whether a format-aware redactor exists for certain key types.

The 5.10 GB capture was also truncated mid-stream, meaning the full upload of a 12 GB repository was not captured end-to-end — though the evidence establishes that multi-gigabyte uploads succeeded with zero failures across the tested range.

What the analysis does establish, through comparative canary testing, is that Grok Build's behavior was a specific outlier. GitHub Copilot, Cursor, Claude Code, Codex CLI, and Gemini CLI all send the files their agents open for a given task. Grok Build was sending the workspace, as documented in cereblab's comparative tool analysis. That distinction is confirmed by the 27,800-fold data-volume gap between what the model needed and what left the machine.

What Developers Should Do Now

Security researchers and practitioners advising on the incident have been consistent on the remediation steps.

Rotate credentials immediately. Any API key, database password, or other secret stored in a tracked .env file or anywhere in Git history — including secrets committed and later deleted — should be treated as potentially transmitted and rotated. The Git bundle carries the full commit history. A file removed from the working tree can still be present in a commit that rode along in the bundle.

Audit network traffic independently. The interception tool cereblab used, mitmproxy, is freely available and requires no elevated access. Any organization running AI coding agents on sensitive codebases should conduct wire-level audits before deployment. The Grok Build incident demonstrates that a vendor's settings-page controls and its actual data transmission behavior can diverge substantially.

Run the /privacy command if you used Grok Build. For individual subscribers, running /privacy in the CLI changes the ZDR status and triggers retroactive deletion of previously synced data per xAI's stated policy. This does not substitute for credential rotation, because any secret that was transmitted is already outside the machine regardless of what happens to the stored copy.

Review scope before deploying any AI coding agent. The incident underscores that "local-first" marketing language for AI developer tools requires independent wire-level verification. For organizations operating under NDAs, enterprise data-handling agreements, GDPR obligations, or regulatory frameworks, what actually crosses the network matters more than what a privacy toggle promises.

No Advisory, No Explanation, One Server Flag

The absence of a formal security advisory, a public incident timeline, or a disclosed retention and deletion policy — addressed instead through executive posts on a social media platform — represents a disclosure approach that is likely to face increasing regulatory and enterprise scrutiny.

xAI gave no public explanation of the upload's original purpose. The most plausible benign interpretation, noted in Hacker News discussion and in Explainx.ai's technical analysis, is that uploading the full codebase allows the model to inspect it during "thinking" without making repeated round-trip tool calls back to the client — a performance optimization that would reduce latency. Whether that was the intent or not, the implementation chose performance optimization over disclosure, and gave users no control over the tradeoff.

As of July 14, the upload code remains in the binary. The server-side flag is the only barrier between developer codebases and a Google Cloud bucket. The number of repositories already stored in grok-code-session-traces — and their fate — remains officially undisclosed.

Frequently Asked Questions

Does turning off "Improve the model" in Grok Build stop my code from being uploaded to xAI?

No — and this is the most important distinction to understand. The "Improve the model" toggle controls training consent: whether xAI uses data to train future model versions. It does not control data transmission. The cereblab wire analysis showed that after disabling the setting, Grok Build's /v1/settings endpoint continued returning trace_upload_enabled: true and the repository upload to the grok-code-session-traces bucket continued without interruption. Stopping the upload requires a separate mechanism. xAI currently offers the /privacy CLI command for individual subscribers as the only self-service control for the storage upload — but that fix came after the disclosure, not before.

What data did Grok Build actually send, and what was not sent?

The wire captures confirmed that Grok Build packaged and transmitted the entire tracked Git repository — all tracked files plus full commit history — as a Git bundle to xAI's grok-code-session-traces Google Cloud Storage bucket. Files the agent actually read for a coding task also appeared in the live model-turn channel, unredacted. Gitignored files that were never committed appear to have stayed off the bundle, but this was not separately tested. The captures do not prove that xAI trained on the uploaded code, that employees read it, or that all account configurations behaved identically.

How do I know if credentials from my repository were exposed?

If you ran Grok Build CLI before July 13, 2026 on a repository containing any secrets in tracked files or in Git history — including API keys, database passwords, cloud tokens, SSH keys, or webhook secrets that were committed and later deleted — treat those credentials as potentially transmitted. Rotate them now. Deleting the local file or removing it from the current working tree does not remove it from the Git history that traveled with the bundle. xAI has not published a way for individual users to confirm what specific data was captured and stored.

Is this the first time Grok Build had a security issue?

No. Earlier this month, TechTimes reported that Grok Build was among six AI coding tools affected by a vulnerability called GhostApproval, which used symlink manipulation to make developer approval dialogs display a safe filename while actually writing attacker content to sensitive system paths. You can read the full report on Six AI Coding Tools and GhostApproval. That was a category-wide vulnerability affecting multiple vendors. The codebase upload finding is a separate issue — specific to Grok Build — and involves a data collection practice rather than an attack vector.