Grok Build Repository Upload: What to Do After Version 0.2.93

Grok Build 0.2.93 was observed sending a Git bundle containing a repository’s tracked files and full commit history to xAI-controlled storage, even when the agent was told not to open files. A separate request path sent files the agent did read, including a tracked test .env. The researcher later observed that xAI disabled the whole-codebase upload server-side. Developers who used the affected build with private repositories should still scope what may have left the machine, revoke exposed credentials, review provider logs, and seek account-specific deletion confirmation.

This is not evidence that every Grok Build account behaved identically, that xAI trained on the uploaded data, or that anyone abused a credential. It is evidence of transmission and server acceptance in a reproducible consumer-account test. That distinction matters: the appropriate response is a focused source-code and secret-exposure review, not panic or a malware cleanup.

What the Grok Build repository upload evidence proves

The wire analysis separates two paths that are easy to conflate. Files used in a model turn and the background repository snapshot were not the same mechanism.

The strongest defensible scope is therefore tracked repository content plus Git history in the tested Grok Build 0.2.93 consumer configuration. The report did not separately prove that every untracked or .gitignore-excluded file entered the Git bundle. However, a file read by the agent could still travel through the model-request path, whether or not it belonged in the bundle.

Turning off Improve the model did not stop the reproduced upload. That setting concerned data use or retention; it was not a reliable local egress control for the tested build. The researcher later observed disable_codebase_upload: true from the server and no further whole-codebase upload. A public commitment to delete earlier uploads does not, by itself, tell a specific developer which sessions were covered or provide independent proof that deletion is complete.

What to do if you used Grok Build 0.2.93

1. Record the scope before changing anything. Note the Grok Build version, account or team, approximate session times, working directory, repository remote, branch, and commit. If the tool was launched above the intended project directory, record that too. Keep local logs and screenshots, but do not publish them if they expose paths, code, tokens, or customer names.
2. Inventory every repository used in that window. Include private forks, monorepos, submodules, release branches, old tags, and local working copies. A clean current branch is not enough because the observed Git bundle carried history.
3. Review the current tree and full history for secrets. Look for API keys, cloud credentials, database passwords, SSH or deploy keys, package-registry tokens, OAuth secrets, signing material, webhook secrets, service-account files, and session tokens. Use an organization-approved local or repository-host secret scanner across all refs. Do not paste findings into another cloud assistant.
4. Revoke first, then replace. Disable or revoke a credential at its issuer before committing a replacement. Merely deleting a secret from the current branch does not invalidate it, and rewriting Git history does not invalidate copies that already left the repository.
5. Review provider logs. Check Git hosting, cloud IAM, CI/CD, package registries, container registries, databases, OAuth applications, VPN, SSO, and production dashboards for use of the affected credentials. Search a window that begins before the first Grok session and continues through revocation.
6. Assess non-secret data. Proprietary source, customer identifiers, internal endpoints, unreleased product plans, infrastructure layouts, signing workflows, and regulated data may require a privacy, legal, customer-notification, or contractual review even when no reusable key was present.
7. Request account-specific confirmation. Give xAI support the account or team identifier, session dates, Grok Build version, and repository names or sanitized identifiers. Ask which uploads were associated with those sessions, their retention state, and whether deletion can be confirmed for the specific account.
8. Preserve an incident record. Keep the timeline, affected repositories, credentials revoked, logs reviewed, support case, and final decisions. This makes later evidence easier to reconcile and prevents teams from rotating only the obvious key while missing an old deploy token or fork.

If the repository contained a suspicious binary as well as confidential code, keep the privacy decision separate from the malware decision. Our guide to checking private files without casually uploading them explains when to use a hash lookup or an approved private workflow. For developer workstations that may have executed untrusted project code, follow the separate developer-tool malware recovery process.

How to review Git history without creating another leak

Run the review on an approved local workstation or internal security environment. Start with repository metadata and path names, then inspect suspected objects locally. Useful read-only inventory commands include:

grok --version
git remote -v
git log --all --format='%H %cI %an'
git log --all --name-only --pretty=format: | sort -u

The last command can reveal deleted configuration files, old deployment manifests, and renamed secret files without sending the repository anywhere. Then run the secret-detection method your organization already trusts across all branches and tags. Treat matches as exposure candidates until the credential issuer confirms they were never valid or they have been revoked.

Do not make a public GitHub issue containing a key, attach the repository to a support ticket, or paste raw scanner output into chat. Use sanitized identifiers such as repository name, commit hash, credential type, and last four characters. The same boundary applies to other AI development systems: local inference does not automatically guarantee safe deployment, as the Ollama prompt and API-key exposure case illustrates.

Which logs matter after a repository disclosure

A credential rotation is incomplete if nobody checks whether the old credential was used. Prioritize logs by what the repository contained:

• Git hosts: clone, archive download, token use, deploy-key activity, OAuth grants, webhook changes, and unusual IP addresses.
• Cloud and infrastructure: IAM authentication, role assumptions, secret-manager reads, new access keys, firewall changes, and unexpected compute or storage activity.
• CI/CD and package registries: workflow edits, artifact downloads, package publication, signing events, runner registration, and release-token use.
• Databases and SaaS: new sessions, large exports, permission changes, API calls, and access from locations or user agents the team does not recognize.
• Identity systems: SSO sessions, OAuth consents, recovery changes, MFA resets, and service-account activity.

No suspicious event does not prove that no copy exists, but it changes the response from active compromise containment to controlled disclosure management. Conversely, a matching event should move the case into the organization’s normal incident-response process.

Set safer boundaries for cloud coding agents

Cloud coding agents need code context to work, so the safe question is not whether they send anything. It is which files, history, tools, networks, accounts, and retention controls they can reach.

• Use a minimal clean clone or worktree that contains only the code required for the task.
• Keep live secrets out of tracked files and out of prompts; use short-lived credentials and secret managers.
• Run unfamiliar repositories in a disposable VM, sandbox, or isolated developer environment. The Cursor repository execution flaw shows why opening code can itself cross a trust boundary.
• Restrict agent egress and file access with controls that are enforceable outside the chat prompt.
• For managed deployments, pin configuration at the system level, disable bypass modes, use narrow tool permissions, and verify team-level Zero Data Retention where the contract requires it.
• Re-test controls after client updates. A privacy label, model-training opt-out, and network block are different controls and should not be treated as interchangeable.

Official xAI enterprise documentation now describes managed configuration, sandbox profiles, network requirements, permission policies, and team-level Zero Data Retention. Those controls are useful for future deployment design, but they do not replace the retrospective review for a consumer session already completed with version 0.2.93.

FAQ

References

1. Cereblab. “What xAI Grok Build CLI Actually Sends to xAI: A Wire-Level Analysis (grok 0.2.93).” GitHub Gist, updated July 17, 2026, accessed July 17, 2026. https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
2. SpaceXAI. “Enterprise Deployments.” SpaceXAI Docs, updated June 16, 2026, accessed July 17, 2026. https://docs.x.ai/build/enterprise
3. Heath, Alex. “SpaceXAI’s Grok Programming Tool Was Uploading Its Users’ Entire Codebase to Cloud Storage.” The Verge, July 14, 2026, accessed July 17, 2026. https://www.theverge.com/ai-artificial-intelligence/965600/spacexai-grok-build-repository-upload