xAI appears to have shut off the mechanism that let its Grok Build CLI upload complete developer repositories to company-controlled cloud storage, according to follow-up testing by the security researcher who exposed the behavior. The fix arrived as a hidden server-side flag, with no advisory, no statement, and no answer on what happens to code already collected.
The findings come from a researcher publishing under the handle cereblab, who routed Grok Build CLI version 0.2.93 through the interception proxy mitmproxy on macOS and released the captures as a public gist. The analysis：https://www.landian.news/archives/113901.html?utm_source=x.com&utm_medium=social&utm_campaign=share&utm_content=landiantech&utm_term=%E5%9C%A8%E8%A2%AB%E6%9B%9D%E5%85%89%E6%94%B6%E9%9B%86%E5%BC%80%E5%8F%91%E8%80%85%E4%BB%93%E5%BA%93%E5%90%8E+Grok+Build%E9%80%9A%E8%BF%87%E4%BA%91%E7%AB%AF%E6%9B%B4%E6%96%B0%E6%82%84%E6%82%84%E5%85%B3%E9%97%AD%E6%95%B0%E6%8D%AE%E4%B8%8A%E4%BC%A0%E4%BD%86%E6%9C%AA%E5%8F%91%E5%B8%83%E4%BB%BB%E4%BD%95%E5%9B%9E%E5%BA%94 showed the client bundling the entire tracked repository, full Git history included, and uploading it to a Google Cloud Storage bucket named grok-code-session-traces.
The upload ran independently of the files the agent actually opened for its coding task. The numbers make that distinction concrete. On a 12 GB test repository, the model request channel moved about 192 KB of task-relevant traffic. The storage upload moved roughly 5.1 gigabytes. The tool was not sending what it needed to answer the developer. It was sending the codebase.
A canary credential the researcher planted in a .env file appeared verbatim and unredacted in the captured traffic. And because the CLI uploaded whatever repository it ran in, any team that pointed it at a private or proprietary codebase handed xAI an undisclosed copy of its source history, credentials, and secrets along with it.
Grok Build ships with an "Improve the model" toggle that most developers would read as a data-collection control. Disabling it did not stop the uploads. Server responses still returned trace_upload_enabled: true, and the repository transfer proceeded as normal. The setting governs training consent, not whether code leaves the machine.
Neither the storage bucket nor the upload behavior appears in Grok Build's setup documentation, according to coverage of the analysis, which also notes xAI had marketed the tool as local-first.
A day after the report went public, the researcher retested the same 0.2.93 client and found the server now returning disable_codebase_upload: true alongside trace_upload_enabled: false. Across six retests, no repository uploads were observed. That points to a deliberate server-side mitigation rolled out after the exposure, flipped remotely and invisibly.
The caveats cut both ways. The mitigation has been verified on one machine and one account, so there is no confirmation it is global, staged, or permanent. At the same time, the researcher is explicit that the captures do not prove xAI trained on the uploaded code, that employees viewed it, or that every account received the same configuration. This is a finding about undisclosed collection, not confirmed misuse.
What is entirely missing is xAI's side of the story. No security advisory. No explanation of the upload's purpose, scope, or retention. No word on whether repositories already sitting in grok-code-session-traces will be deleted. The official changelog listed version 0.2.98 as the latest release on July 12, 2026 without mentioning repository-upload behavior at all.
扫码直达文章详情