Since July 13, 2026, xAI has server-side disabled the upload. But if your team used Grok Build before that date, your full repository history, including secrets in commit history, may have already left the machine.

What actually happened

Grok Build, xAI’s coding CLI, was sending entire tracked Git repositories to a Google Cloud Storage bucket (grok-code-session-traces) operated by xAI – not just the files the agent opened during a coding session.

A researcher publishing as cereblab intercepted the traffic on version 0.2.93 and cloned the uploaded git bundle. The recovered archive contained files the agent had been explicitly told not to open and the full commit history.

The numbers

ChannelTraffic volume
Model API (/v1/responses)192 KB
Storage upload (/v1/storage)5.10 GiB
Ratio~27,800× more data than the model needed

The upload ran as 73 chunks of ~75 MB, all returning HTTP 200. Volume tracked total repository size. The destination bucket name is hardcoded in the binary.

What was included in the upload

  • All tracked files, including ones the agent never opened
  • Full Git commit history
  • .env files read during the session, with secrets unredacted – including API_KEY and DB_PASSWORD values (planted fakes in the test, but the mechanism is real)

A file that was gitignored and never committed stayed out of the bundle. A secret you committed and later deleted from the working tree did not it rode along in history.

The detail that matters most: the opt-out didn’t cover this

Turning off „Improve the model” in settings did nothing. With that toggle disabled, Grok still uploaded the full repository. The server kept returning trace_upload_enabled: true.

That setting controls whether your data is used for training. It does not control whether your code leaves the machine. Those are two separate controls and only one was visible to users.

What xAI did

On July 13, without a client update, xAI flipped a server-side switch. Version 0.2.93 stopped making storage requests. The server now returns disable_codebase_upload: true and trace_upload_enabled: false.

Elon Musk stated on X that all previously uploaded data would be „completely and utterly deleted.” Enterprise teams on zero data retention (ZDR) and API key users were reportedly never affected. Individual subscribers can run /privacy in the CLI to disable retention and request deletion of previously synced data.

A separate analysis of build 0.2.99 found the upload code still present in the binary held off by the server flag. xAI can re-enable it without shipping an update.

How Grok Build compared to other tools

ToolRepository bundle uploaded?
Grok BuildYes — full repo + history
Claude CodeNo
OpenAI CodexNo
GeminiNo (idle test; realistic-task run was quota-blocked)

All cloud coding agents send the files they open to a remote model that’s expected. Sending the full tracked repository and its history is a different boundary entirely.

What you should do if you ran Grok Build before July 13

Rotate any credential that Grok could have accessed:

  • Any secret in a file the agent read during a session
  • Any tracked .env file in the repository
  • Any credential that appears anywhere in commit history, including commits where the secret was „already deleted”

Don’t wait on xAI’s deletion confirmation. Rotate first.

If your team uses AI coding agents as part of a broader development workflow, it’s worth reviewing how we approach development security and best practices – including tooling decisions that affect what leaves your environment.

Source: Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read – The Hacker News, Jul 14, 2026; cereblab’s original research; cross-tool comparison