Every Agent Will Have a Grok Build Moment. This Is How You Handle One.

Grok Build, SpaceXAI's coding agent, was uploading more repository data to SpaceXAI's storage than needed for any coding task. We reversed the official binary, and then published it. What happened next is the part that matters most, so that's what we’ll uncover below.

What was Grok Build uploading?

We tested Grok Build in a locked-down session with all agent tools turned off. The model did not read anything, run any shell commands, or make any calls. Still, the repository was uploaded from the machine.

This was because a background collector was running alongside the agent. Every time Grok Build ran in a repository, it packaged and uploaded every tracked file at the current Git HEAD, every Git object reachable from HEAD, and even files that had been deleted from the checkout but still existed in the repository's history.

Removing a key from a file does not erase it from Git history, so secrets that developers had already removed from their working trees were still uploaded.

We found no evidence the collected repos were used to train models.

What did SpaceXAI do about it?

The collection was already disabled before our discovery went out. A server-side flag called disable_codebase_upload was switched on for all users at once. Developer Peter Dedene noticed the new flag in his settings and asked about it publicly, which is how the wider community first found out something had changed.

After it drew mass attention, SpaceXAI's announcement explained the change. Retention was turned off on July 12, and SpaceXAI said deletion of the collected archives had already started. SpaceXAI told us users on zero-retention or opt-out plans were not included in the collection, consistent with what we observed. About two hours after the announcement, some uploaded paths were still recognized by the storage API; we could not retrieve source bytes and did not prove permanent deletion failed.

On July 15, SpaceXAI open-sourced Grok Build, including the collector. The full code is now public. Any developer can see what the tool does and check the claims.

SpaceXAI also launched a bug bounty program.

The bounty pays researchers to look for the same kind of discovery we reported, so external eyes stay on Grok Build. SpaceXAI made external review a standing, funded part of its development.

Cantina's CEO response:

Building AI products today is challenging for many reasons. Every team is under intense pressure to ship great product quickly because of how competitive the market is, and this leads to security issues slipping. However, how SpaceXAI handled this is quite commendable. They made the entire software more transparent by making it open source, so new users can be assured that the behavior is no longer there. Really commendable way to handle the incident. - Hari Mulackal, Cantina CEO & Co-Founder.

Defaults do the deciding

Zero-retention and opt-out controls were in place before any of this happened, and they worked. What we are now stressing is the context around these controls.

Most users never look at the settings page, so whatever an agent does by default is effectively its policy. In this case, the default collected more than most developers expected, and only users who already knew to protect themselves were safe. The response above shows that defaults can be resolved quickly when a company decides that transparency is better than leaving room for doubt.

Check your own machine

If you used Grok Build and want to know what happened on your machine, we've published a read-only audit. Paste the prompt into Claude Code, Codex, OpenCode, or any agent you use, and it will show you which, if any, repositories were collected, which archives were queued, and which archive IDs SpaceXAI's storage still recognizes.

The script never uploads or downloads source code, and it never prints credentials or archive IDs. Be sure to check the repository paths before sharing any output, since even the paths can be sensitive.

COPY/PASTE PROMPT ↓
────────────────────

Perform a read-only audit of Grok Build codebase collection and retention on this machine. Do the investigation with shell/Python; do not just give me instructions.

Do not launch Grok, send it a prompt, upload/download archives, invoke /privacy, delete anything, or change configuration/account state. Never print tokens, session IDs, or storage object IDs. Do not create or delete even temporary files; process everything in memory or through stdin/stdout.

Inspect ~/.grok/logs/unified*.jsonl plus rotated logs beside it. Find `repo_state.upload.start` and `repo_state.upload.enqueued`. Correlate events by `sid`, `ctx.turn_number`, and phase. Derive an enqueued event's phase from its `gcs_path` basename (`before_codebase.tar.gz` or `after_codebase.tar.gz`). Map each archive to the start event's `ctx.repo_path`.

For every repository, count collection attempts and queued archives and show first/last timestamps. Then perform a metadata-only existence check: read the newest cached `key` from ~/.grok/auth.json without displaying it and POST the exact queued paths as `{"paths":[...]}` batches to:

https://cli-chat-proxy.grok.com/v1/storage/batch_exists

Use `Authorization: Bearer <token>`. Never call download or follow signed URLs.

Print the UTC check time and this table:

STATUS | PRESENT/ABSENT/UNKNOWN | ATTEMPTS | FIRST/LAST | REPOSITORY

Classify COLLECTED-ONLY when collection started without a matching queue event; QUEUED when an archive was enqueued; REMOTE-PRESENT when any exact ID is in `exists`; NOT-LISTED only when all its IDs are in `missing`; otherwise UNKNOWN.

Finish with totals and caveats: queueing alone does not prove server retention; REMOTE-PRESENT proves only that this API still recognizes the object; NOT-LISTED does not prove deletion from backups, replicas, derived data, or other stores; missing logs can cause false negatives.

Warn that repository paths are sensitive before I share the output.

What to take from this

Moving quickly brings risks, and agents have wide access. Every company working in the agentic era might eventually face an event like SpaceXAI's.

When that happens, how your company recovers is what matters most. Stop the behavior quickly, honor the promises your product's settings already made, and then go beyond what the situation requires. Making code public settles debates that statements can't, and a standing bounty shows the security community you'd rather pay for the next discovery than be caught off guard.

Closing

Our appreciation to the SpaceXAI team for the speed of their response and for choosing transparency over everything else. Agentic tools will produce more cases like this across the industry, and how the first ones are handled will set expectations for the future.

If you're building or running AI agents and want another set of eyes on what they actually do, contact us.