Wave2
Back to Insights

Grok Build's Hidden Repo Upload: What Business Leaders Need to Know

Wire-level research found xAI's Grok Build CLI uploading entire Git repositories — including secrets and unread files — to cloud storage. What happened, what changed, and what your firm should ask.

13 Jul 2026Wave2 Team

ShareLinkedIn

On July 10, 2026, an independent security researcher published wire-level proof that xAI's Grok Build CLI — a coding assistant marketed as "local-first" — was uploading users' entire Git repositories to cloud storage in the background. That included files the AI never opened, full commit history, and secrets in tracked .env files — sent verbatim and unredacted.

The analysis reached the top of Hacker News within days. A second researcher independently confirmed the behavior. As of July 13, follow-up tests suggest xAI may have disabled the upload server-side — but the client still contains the capability, and xAI has not published a clear advisory explaining what changed or what happens to data already uploaded.

For business leaders, this is the same class of problem as Claude Code's hidden fingerprinting: powerful AI software on employee machines, doing more with your data than the product surface suggests.

What happened

Researcher cereblab intercepted network traffic from Grok Build CLI version 0.2.93 using standard proxy tools on a test machine with fake "canary" secrets — no real credentials involved.

The findings were specific and reproducible:

  • Grok runs two data channels. The first sends files the agent reads into the model — expected behavior for any cloud coding tool. The second uploads a complete snapshot of the repository as a Git bundle via a separate storage endpoint, routed to a Google Cloud bucket named grok-code-session-traces.
  • The whole-repo upload happens independently of what the agent reads. With the prompt "Reply OK, do not read any files," the full repository still uploaded. Researchers cloned the captured bundle and recovered a file the agent was explicitly told never to open — with its unique marker intact.
  • On a 12 GB test repository of files the agent never touched, roughly 5.1 gigabytes transferred successfully to storage, while the model channel moved only about 192 KB. The upload scales with repository size, not with what the AI actually used.
  • Fake credentials planted in a .env file appeared verbatim and unredacted in captured traffic — both in model requests and in archives destined for cloud storage.
  • The "Improve the model" privacy toggle did not stop uploads. Disabling it still left trace_upload_enabled: true on the server. That setting appears to govern training consent, not whether your code leaves the machine.

The researcher published a detailed wire analysis and a reproduction harness so others can verify the claims on their own machines.

What changed on July 13

On July 13, the same researcher retested the identical client six times and observed zero storage uploads. The server now returns flags that appear to disable the behavior — trace_upload_enabled: false and disable_codebase_upload: true — without a client update.

That is encouraging, but it comes with caveats:

  • The change was observed on one account and one machine. It may be a gradual rollout, not a global fix.
  • xAI has not published a security advisory explaining the original behavior, the mitigation, or what happens to repositories already uploaded.
  • The client binary still contains the upload machinery. Server flags can change. Local configuration hardening remains prudent for anyone using the tool on sensitive codebases.

What the research did — and did not — prove

Proven: transmission, server acceptance (HTTP 200), and persistent storage of full tracked repository contents — including Git history and never-read files.

Not proven: that xAI trains models on the data, that staff access or misuse uploaded repositories, or whether .gitignored files are included (Git bundles carry tracked content; secrets that were ever committed can reappear from old history even after deletion).

The defensible conclusion for leadership is not "xAI is stealing code." It is: a tool marketed with local-first language was moving entire repositories off employee machines without clear disclosure — and the obvious privacy toggle did not stop it.

Why it matters beyond developers

Three points stand out for business owners and partners.

"Local-first" is not a governance policy. When staff install AI coding agents, leadership often assumes the work stays on the laptop. This incident shows that assumption can be wrong — even when the vendor's language suggests otherwise.

Permission rules do not equal data control. Grok's file-read denials blocked the agent from opening a file into the chat. They did not keep that same file out of the uploaded Git bundle if it was tracked in version control. That gap matters for firms that thought tool permissions were enough.

Shadow AI risk is compounding. Developers are among the first to adopt CLI coding tools — often on personal accounts, outside IT review. A single session on a repo containing client code, API keys, or proprietary logic can export far more than anyone pasted into a chat box. As we covered in Protecting Sensitive Business and Customer Data in the AI Era, the failure mode is rarely malice. It is missing a safer default.

A practical question for your firm

Cloud AI is often the right choice for low-risk work — boilerplate code, public libraries, tasks with no sensitive data. For repositories holding client deliverables, financial models, credentials, or proprietary strategy, the bar is higher.

You need to know what leaves the machine, what the opt-out actually controls, and whether you can verify both — not just what the marketing page says.

That is the case we made in Why Businesses Should Choose Private AI Over Cloud API Services. Private deployment does not mean rejecting cloud tools everywhere. It means matching the tool to the data: cloud where the risk is low, governed local systems where it is not.

For sensitive document work, that can look like Wave2 Vault — queries and files stay on hardware you control. For workflows where AI-assisted work needs to be visible and auditable, Wave2 Shadow captures what happened locally so partners can review it. For firms still sorting out which tools are approved at all, The AI Policy Your Team Will Actually Follow is the place to start.

Four questions to ask this week

  1. Are developers using Grok Build, Claude Code, Copilot, or similar CLI agents on client or proprietary repositories? Inventory what is installed — including tools signed up for with personal accounts.
  2. Do we know what each tool uploads beyond the files someone explicitly shares? Ask vendors for wire-level clarity, not just training opt-out language.
  3. Are secrets only in .gitignore, or also in Git history? A whole-repo upload can resurrect credentials deleted from the working tree but still present in past commits.
  4. For our highest-risk work, do we have an alternative we can inspect and govern? Policy without a sanctioned path pushes people toward shadow tools.

If your team uses Grok Build today

Community reverse-engineering identified configuration that can disable uploads locally (precedence: environment variables override config, which overrides server flags):

# ~/.grok/config.toml
[harness]
disable_codebase_upload = true

[telemetry]
trace_upload = false

[features]
telemetry = false

Treat this as a precaution, not a guarantee. Re-verify after every CLI update — Grok enables auto-update by default.

If Grok Build has run against repositories with real credentials, rotate those secrets regardless of whether uploads are currently disabled server-side. The original research captured successful uploads with HTTP 200 responses.

The pattern to watch

This is the second major AI coding-tool transparency incident in two weeks. The details differ — hidden classification markers in one case, whole-repository uploads in another — but the lesson is the same.

Firms adopting AI need governance that covers software behavior, not just what employees type. Contracts and toggles that address model training do not automatically answer whether an entire codebase left the building.

The firms that benefit from AI long term will not react to every headline. They will use moments like this to ask sharper questions — and build systems where the answers sit under their own control.

If your business is weighing cloud convenience against transparency and data governance, start a conversation with us.

Ready to turn AI ideas into working systems?

Talk to Wave2 about the practical path from experiments to AI-enabled websites, workflows, and automations that ship.

Start a conversation