Giving a coding agent access to your repository is already routine. The problem is that developers often do not really know how far that access is used. Wire-level traffic analysis showed that version 0.2.93 of xAI's coding agent CLI "Grok Build" sent entire local repositories, commit history, and secrets such as .env files to an xAI-owned Google Cloud bucket (grok-code-session-traces) without permission. This was confirmed through CyberSecurityNews's report and The Hacker News's follow-up reporting.
A Response That Needed 192KB, and 5.1GiB Leaked Out
This is not a false alarm or an exaggeration. In one case confirmed by The Hacker News, data that would have taken just 192KB for the model to generate a normal response actually sent 5.1GiB. It means that behind a request handling a few lines of text, the entire repository was flowing to the cloud. A transfer of this scale is hard to explain as an accidental bug, and reads as a sign of behavior designed to collect the codebase broadly.
More serious is that what was sent was not limited to source code. Secrets such as API keys, database credentials, and service tokens in .env files, along with the entire commit history, went up too. According to TechTimes, the CLI had a privacy toggle said to let users block this upload, but in reality it did not stop the transfer even when turned on.
Cursor Built Trust Over 3 Years; xAI Blamed the Toggle
The incident spread especially widely in the developer community thanks to a post on X by Gergely Orosz (@GergelyOrosz), who runs The Pragmatic Engineer newsletter. In the post, which drew 200,000 views and 2,300 likes, he criticized bluntly: "After seeing this awful incident, I don't see how any serious company can use the Grok CLI. If you're an amateur (you don't make much money from code) and you don't care about security (you don't care about .env leaks), then go ahead."
Orosz did not stop there and took issue with how xAI responded. He pointed out that "Cursor is a trusted brand that developers built up over 3 years, while xAI/Grok quietly uploaded .env files to the cloud and then blamed users for not flipping the secret switch that blocks it." The details are laid out in the relevant issue of his The Pulse newsletter. His point is that an attitude of shifting responsibility to user settings instead of admitting the defect does more damage to trust than the problem itself. In fact, after the incident became public, xAI disabled the upload feature server-side and added a new setting called disable_codebase_upload to the CLI, which amounts to admitting the old toggle effectively did not work.
| Category | Before the incident | After (xAI's response) |
|---|---|---|
| Upload scope | Entire repository + commit history + secrets such as .env | Upload feature disabled server-side |
| User control | An existing privacy toggle did not work | New disable_codebase_upload option added |
| Disclosure | Discovered late through wire-level analysis | Action taken after reports, with no advance notice |
Rotate and Lock Down Starting With `.env`
For teams that have used Grok Build locally or in CI, the priorities are clear. First, immediately rotate every secret the CLI could access while running, including .env. It is safest to treat values already uploaded to the cloud as leaked, regardless of any deletion request. Second, check the CLI version, update to the latest, and verify at the network traffic level that the disable_codebase_upload option is actually on. Not trusting what the settings screen shows is the core lesson of this incident.
Third, at the organization level, it is worth adding to your criteria for adopting coding agent CLIs the question "can users directly verify outbound network traffic?" The standard should be whether it can be confirmed with real packet captures or proxy logs, not the vendor's privacy settings documentation. Fourth, if you have repositories already committed through Grok Build, scan separately whether secrets remain in the history, and consider rewriting history (BFG, git-filter-repo, and so on) if needed. Simply deleting .env in the latest commit is not enough.
Explained, but Deletion Unconfirmed
There are also parts of this incident that have clearly not been officially confirmed. It is not clear from current reports whether xAI has issued a public apology or an official statement on this matter. The actions of disabling the upload server-side and adding the disable_codebase_upload option are confirmed, but from public information it cannot be confirmed whether xAI deleted the existing data already piled up in the grok-code-session-traces bucket, or if it did, by what process and by when. A technical explanation from xAI of whether this upload was an intended telemetry design or a pure implementation defect has also not yet come out.
It is also unclear whether the measures to prevent recurrence are limited to this CLI or apply across xAI's other agent products. As long as these gaps remain, it is safer for each team to judge whether to trust Grok Build again by verifying traffic itself, rather than waiting for the vendor's announcement.