# Grok Build CLI shipped entire repos to xAI
> The upload ran as a background job outside the agent's permission system, so it fired even in sessions where file access had been denied.
- **Publisher:** Optimus Labs · Civilizations
- **Published:** 2026-07-16
- **Severity:** critical
- **Types:** Coding agent, Rogue AI, Supply chain
- **Categories:** AI — AI Asset Supply Chain Security; AL — Agentware Lifecycle Security; AP — Agent Permissions; OL — Outside the Agentic Loop
- **Vendors / products affected:** xAI, Grok Build CLI
- **Blast radius:** Every repository opened with Grok Build, plus anything reachable from its git history: customer code, vendor code you vendored, and credentials for third and nth-party systems.
- **Canonical URL:** https://www.optimuslabs.io/research/briefings/grok-build-repo-exfiltration
## Summary

Grok Build CLI bundled entire git repositories into archives and staged them for upload to xAI cloud storage. The bundle included every object reachable from HEAD, so .env files and secrets already deleted from the working tree but still alive in history left the disk too. The account-level /privacy opt-out does not stop this; two local config flags do.

## What happened

- The Grok Build CLI collected entire git repositories, not the files the agent was asked to read. Every object reachable from HEAD was bundled into an archive and staged for upload to xAI cloud storage. That includes .env files and secrets that were deleted from the working tree long ago but are still alive in git history.
- The upload ran as a background job outside the agent's permission system. It fired even in sessions where file access had been denied, so the in-session permission prompts were not a boundary for it.
- The account-level /privacy opt-out stops training-data retention, not the repo upload. Stopping the upload requires two local flags in ~/.grok/config.toml: [harness] disable_codebase_upload and [telemetry] trace_upload. Both are off by default.

## Why it matters

- We were all watching the agent. Nobody was watching the door. Reviewing agent turns, diffs and tool calls tells you nothing about a background job that packages the repository and hands it to a vendor endpoint.
- Network monitors only helped during live exfiltration. Once the session is over, the disk is the only witness: the staged archives, the collection paths and the git object IDs are what let you answer which repos went and which secrets to rotate.
- A secret that is in history is a live secret. Deleting a .env from the working tree does not remove the blob, so the exposure set is larger than the current checkout for almost every repository.

## What to do

- If you or anyone on your team ever ran Grok Build — even once, even in a session where file access was denied — run grokpatrol to see which repositories were collected, staged and sent, and which secrets to rotate.
- Rotate every credential grokpatrol reports as reachable from history, not just the ones currently in the working tree.
- Set both local flags in ~/.grok/config.toml: [harness] disable_codebase_upload and [telemetry] trace_upload. The account-level /privacy opt-out is not sufficient.
- Enterprises handling sensitive data should uninstall the CLI entirely rather than rely on local flags staying set on every developer machine.

## Indicators of compromise

- ~/.grok/config.toml — check for [harness] disable_codebase_upload and [telemetry] trace_upload
- Staged codebase archives written by the CLI under the local grok state directory
- Local trace/telemetry upload records referencing repository archive object IDs
- git rev-list --objects HEAD minus git ls-tree -r HEAD — objects present only in history (deleted secrets)

## Sample output

```
$ grokpatrol
grokpatrol 0.4.1   offline · read-only · never runs grok

  scanning local grok state ............ done
  reconstructing collection set ........ done
  diffing history vs working tree ...... done

VERDICT: EXPOSED

  repositories collected  3
  archives staged         3
  uploads recorded        2

  ~/work/payments-api            collected  staged  sent
    .env                         b7f1c9a24d3e8a01f5c6d9b2e4a7c018d3f5b9ac  history-only
    infra/terraform/prod.tfvars  4e2a8d15c7b3f9016a2d5e8c1b4f7a90d6c3e2b8  history-only
  ~/work/internal-dashboard      collected  staged  sent
    .env.local                   9c4d7e2b18a5f36042e9b1d7c5a8f2306b4e9d1a  working-tree
  ~/scratch/agent-playground     collected  staged  not-sent

  rotate 3 credentials. paths and git object IDs only; no secret values are read or printed.
```

## Sources

- [Optimus Labs — discovery write-up (LinkedIn)](https://www.linkedin.com/posts/guptanipun_my-spare-laptop-ran-completely-out-of-disk-share-7482518573358264320-gt)
- The Hacker News — coverage (URL pending)
- The Register — coverage (URL pending)
- The Stack — coverage (URL pending)
- cereblab — wire-level analysis (URL pending)

## Related tool

- [grokpatrol](/grokpatrol/) — Offline, read-only scanner. It never runs grok. It reports which repositories were collected, staged and sent, and prints paths and git object IDs only, never secret values.

---

Published by Optimus Labs · Civilizations, the threat research team at Optimus Labs. Optimus Labs secures the enterprise agentic AI attack surface: discovery and governance of every AI agent, MCP server, and skill, posture management against the OWASP Top 10 for Agentic Applications, and runtime behavior anomaly detection. More briefings: https://www.optimuslabs.io/research/briefings