Grok's Coding Assistant Was Quietly Shipping Whole Git Repos to xAI

Key points

• A researcher publishing as cereblab found that xAI's Grok Build coding assistant, version 0.2.93, was uploading whole Git repositories to a Google Cloud Storage bucket owned by xAI.
• The uploads included the full commit history of the code, not just the files the assistant needed to read for a task.
• The researcher intercepted one upload and was able to pull back a file the assistant had been told, in plain language, not to touch.
• The behaviour was spotted in Grok Build's command-line tool, the piece developers install on their own machines.
• xAI has not, at time of writing, published a security advisory about the finding.

Here is the short version. When a developer used xAI's Grok Build coding tool, the tool was not just reading the files it needed. It was quietly packaging up the entire code project, including every past change ever made to it, and sending that package to a storage bucket, a kind of online filing cabinet, run by xAI.

That is a much bigger scoop of data than the job required.

The finding comes from a researcher who publishes as cereblab and was first reported by The Hacker News. They tested Grok Build's command-line tool, known as a CLI, which is the version developers install and run in a terminal window on their own computer. The version under the microscope was 0.2.93.

What actually got uploaded?

The whole repository. In developer terms, a Git repository is the folder that holds your code plus a hidden record of every edit anyone has ever made to it. That hidden record is called the commit history, and it often contains things people forgot were there: old passwords, private keys, half-finished features, internal notes, files that were deleted months ago but still exist in the archive.

Grok Build was bundling all of that up and sending it to a Google Cloud Storage bucket controlled by xAI. Not the two files the assistant needed to look at. The lot.

How do we know it was really happening?

Because cereblab caught one of the uploads mid-flight. They intercepted the network request the tool was making, extracted the Git bundle, which is essentially a zipped-up copy of the repository, and unpacked it.

Inside, they found a file the assistant had been explicitly instructed to leave alone. The instruction, written in plain English in the project, made no difference. The file went to xAI's bucket anyway.

That is the part that should sting. Telling an AI coding assistant "do not read this file" is not a security control. It is a suggestion. If the tool's upload logic runs before or around those instructions, the file gets shipped regardless.

Should developers be worried?

Yes, if they used Grok Build 0.2.93 on any codebase they consider sensitive. That includes work repositories, client projects, and any personal project with credentials baked into old commits.

A few practical steps. Check whether Grok Build is installed on your machine and which version it is. Assume any repository you pointed it at has been copied to xAI infrastructure, history and all. Rotate any secrets, meaning passwords, API keys, or tokens, that ever lived in those repositories, even in deleted files.

This is not a novel AI attack. It is a classic data-exfiltration pattern with an AI wrapper: a client tool sending far more than the user thinks it is sending. We have seen the same shape in browser extensions, in developer plugins, and in mobile SDKs for years. The lesson developers learned the hard way about "free" IDE plugins in the 2010s now applies to AI coding agents.

Read the network traffic. Trust nothing that phones home by default.