Grok Build's CLI uploaded your whole Git repo — including committed secrets

If you ran Grok Build's CLI against a real repo, assume your entire Git history — full commit log, every branch, and any secrets you ever committed — landed in a Google Cloud Storage bucket. xAI has now open-sourced the ~844K-line Rust codebase under Apache 2.0, reset usage limits, disabled the upload feature by default, and says it deleted prior uploads. That's damage control, not proof.

The short version: the fix is real enough to keep using the tool if you sandbox it, but "disabled by default" and "we deleted it" are promises, not receipts. Nobody outside xAI can verify a bucket got wiped.

What actually happened?

A wire-level analysis caught the CLI shipping whole repos to a GCS bucket. Not diffs. Not the files you touched. The whole `.git` directory — which means full history and anything that ever hit a commit, including the `.env` you deleted three commits later. Git doesn't forget; deleting a secret in a later commit leaves it sitting in history forever, and the upload grabbed all of it.

This is the classic footgun. People rotate a leaked key, `git rm` the file, and think they're clean. The old blob is still reachable. An upload of full history exfiltrates every one of those.

The teardown behind this came from cereblab, and you can read the details in the original security disclosure.

Does open-sourcing the code prove anything?

Not the part that matters. Open-sourcing 844K lines of Rust lets you audit what the CLI does *now*. It tells you nothing about what already left your machine and whether it's really gone.

Here's the tell: remnants of the upload code are still in the repo, just disabled. That's honest, at least — they didn't scrub git history to hide it, which would've been its own kind of irony. But disabled-in-source is a runtime flag, not a cryptographic guarantee. Flip a boolean, ship a new build, and it's back. You're trusting a config default and a deletion claim you can't check.

Musk also said X will publish its full codebase after a security review. File that under "later."

What broke, concretely?

The threat model here isn't "AI reads my code." You opted into that. The break is scope: a coding agent that silently uploads the full repo to first-party cloud storage without a per-project prompt, without a diff of what's being sent, and without excluding history.

A sane design uploads only the working tree files in context, honors `.gitignore` plus a secrets denylist, and never touches `.git/`. Grok Build did the opposite of all three.

If you ran it against anything with real credentials in history: rotate those keys now. Don't wait on the deletion pledge. Treat every secret that ever touched that repo's history as compromised, because you can't prove it wasn't.

Should you use it?

Conditionally. The open-source move is the right direction and the retained-but-disabled code is more transparent than a quiet patch would've been. But I wouldn't point it at a repo with production secrets in history until there's an audited build with the upload path removed, not flagged.

My verdict: fine for throwaway or public repos today. For anything real, run it in a container with no cloud creds mounted, scrub your history first, and keep it off your main tree until someone independent verifies the upload code can't come back. "Trust us, it's off" is where I got off.

FAQ

Do I need to rotate secrets even though xAI says it deleted the uploads?

Yes. You can't verify a third party's bucket deletion, and Git history exposure means every secret ever committed is potentially out. Rotate anything that touched that repo's history and move on.

Why does full Git history matter if I already removed the secret?

Because `git rm` and later commits don't erase old blobs — the secret stays reachable in history forever. An upload of the whole `.git` directory captures it regardless of your latest working tree.

Is the open-sourced code safe to run now?

The upload feature is disabled by default and the code is auditable, but "disabled" is a runtime flag, not a removed feature. Sandbox it without cloud credentials until an independent build strips the upload path entirely.