Grok Build Uploaded Your Repository: What to Do Now

If you used Grok Build before xAI disabled its codebase-upload path on July 14, 2026, treat the affected repository as a potential secret-exposure incident. Stop the old client, identify which repository and account were involved, rotate credentials that may have been present, scan both the current tree and Git history, update Grok Build, configure its separate privacy and telemetry controls, and resume only in a restricted test repository.

This is a version-specific response, not a claim that the current Grok Build release still uploads whole repositories. The independent wire analysis tested version 0.2.93 and later reported that xAI had disabled codebase upload server-side. The same researcher found that /privacy opt-out changed data-retention settings but was not, by itself, a network-transmission control. xAI subsequently published the client source, so current behavior can be checked against the official Grok Build repository.

What the Research Found

The original wire-level analysis used a controlled repository and an intercepting proxy. It reported that Grok Build 0.2.93 sent a Git bundle containing the tracked repository and its history, independent of files the agent explicitly read. The test also showed the contents of a deliberately read .env file in session traffic. The researcher did not claim that xAI trained on the data.

On July 14, the researcher updated the report to say that xAI had set disable_codebase_upload: true server-side and had committed to deleting previously uploaded repositories. Treat deletion as unconfirmed for your own incident until you receive account-specific confirmation. The reproduction repository makes the tested conditions reviewable.

The practical distinction is important:

• Repository upload is the version-specific codebase-sync behavior reported in the test.

• Coding-data retention is controlled through Grok Build's /privacy setting.

• Telemetry and trace upload have separate settings in ~/.grok/config.toml.

• Sandboxing limits local filesystem and child-process access, but it is not a complete network boundary.

One switch does not cover all four.

Step 1: Preserve the Facts Before Changing Anything

Stop the affected Grok Build process. In the repository where it ran, capture only the minimum non-secret context needed for your incident record:

grok --version
git branch --show-current
git log -1 --format='%H %cI'
git status --short

Record the Grok account, approximate session time, repository name, client version, operating system, and whether the repository was private. Do not paste source files, environment variables, remote URLs, or raw agent traces into a public ticket. A Git remote can contain a credential, and a trace can contain prompt or tool data.

Expected result: you have enough information to identify the affected session and repository without making another copy of sensitive material.

Step 2: Rotate Secrets Before Cleaning Files

Deleting a secret from the working tree does not invalidate it. Rotate or revoke any credential that was tracked in Git, present in a file the agent read, pasted into the session, or stored in an agent-accessible path.

Start with the credentials that offer the largest blast radius:

1. cloud, deployment, database, and source-control credentials;

2. production API keys and OAuth refresh tokens;

3. package-registry, signing, and CI credentials;

4. webhook secrets and service-account keys; and

5. lower-privilege development keys.

Check provider audit logs for use after the affected session. Invalidate active sessions when the provider supports it. Document the old credential identifier, rotation time, and owner, but never the credential value.

Expected result: possession of any old exposed value no longer grants access.

Step 3: Scan the Current Tree and Git History

Use a secret scanner that inspects Git history, not only the files currently checked out. Gitleaks supports repository-history scans through gitleaks git.

From the repository root:

mkdir -p ../grok-build-audit
gitleaks git --redact --report-format json \
  --report-path ../grok-build-audit/gitleaks.json

Keep the report outside the repository and do not commit it. --redact reduces secret material in the report, but the report is still sensitive. Review each finding, rotate real credentials first, and then follow GitHub's sensitive-data removal procedure when history must be rewritten.

History rewriting changes commit identifiers and requires coordination with every clone and open pull request. It is cleanup, not revocation. A scanner also cannot prove that no secret exists because custom formats and transformed values can evade detection.

Expected result: findings have owners and dispositions, live credentials are rotated, and any necessary history rewrite has a coordinated plan.

Step 4: Update Grok Build and Separate the Controls

Install or update Grok Build using the current instructions in the official repository, then check the version again. Review release notes and source changes instead of assuming that an old package or cached installer is current.

The official configuration guide documents separate controls for product telemetry and trace upload:

# ~/.grok/config.toml
[features]
telemetry = false

[telemetry]
trace_upload = false
mixpanel_enabled = false

Use /privacy inside Grok Build to review or change coding-data retention. The official slash-command documentation explicitly says that /privacy does not change telemetry or trace-upload settings. Configure both surfaces according to your policy.

Expected result: the current client is installed, retention is set deliberately, and telemetry and trace upload are separately configured.

Step 5: Restrict Filesystem Access Before Resuming

Resume in a disposable test repository first. Grok Build's sandbox documentation describes a strict profile:

grok --sandbox strict

Add explicit deny patterns for files that the agent should never read. The documented custom-profile format supports an extension such as:

# ~/.grok/sandbox.toml
[profiles.agent-audit]
extends = "strict"
deny = ["**/.env", "**/.env.*", "**/*.pem", "**/*.key"]

Start the client with the custom profile only after confirming the current CLI syntax in the same version's documentation. Test the deny rules with fake canary files, not real credentials.

Know the boundary: Grok Build documents that child-process network blocking applies on Linux, is a no-op on macOS, and does not block the client's built-in HTTP tools. The official permissions and safety guide recommends combining permissions with sandboxing. If your policy requires an enforceable outbound-network boundary, add an operating-system, container, or network-level control outside the agent.

Expected result: a canary file matching each deny rule cannot be read, and the agent runs only in a repository with the files it needs.

Step 6: Verify Before Returning to a Real Repository

Use a test repository containing unique, non-secret markers. Exercise the same actions you normally use: repository search, file reads, shell commands, and an external tool call. Check:

• the configured privacy, telemetry, and trace-upload settings;

• local process and network logs available in your environment;

• the files the agent actually read;

• provider account logs or exported session data; and

• whether denied canary files remained inaccessible.

Do not treat a successful /privacy opt-out response as proof that no data crossed the network. Do not treat a clean secret scan as proof that every credential is safe. Verification should combine client configuration, a restricted test, and independent logs.

Use Aident Loadout to Keep Integration Access Reviewable

This incident is also a reminder to separate agent instructions from provider credentials. Aident Loadout lets an agent discover connected actions, inspect their schemas, and execute them through Aident Vault without placing provider tokens in the repository or prompt.

Install it by giving your agent this instruction:

Follow https://aident.ai/SETUP.md

Then verify the account, connected vaults, and recent Aident action calls:

aident account auth status
aident vault vault --action status
aident audit audit --action recent --limit 100

The audit summary covers Aident action names, status, latency, and credit use. It does not inspect another CLI's filesystem access or network traffic, so keep the Grok Build verification steps above. For related access design, read MCP API Keys vs OAuth and Local vs Remote MCP Servers.

Incident Checklist

• Stop the affected client and record the version, repository, account, and time.

• Rotate credentials before deleting files or rewriting history.

• Scan the current tree and complete Git history with redacted output.

• Request account-specific confirmation for any promised server-side deletion.

• Update Grok Build from its official source.

• Configure retention, telemetry, and trace upload separately.

• Add filesystem deny rules and an external network boundary when required.

• Verify the controls in a disposable repository with fake canary data.

• Resume real work only after the incident owner accepts the remaining risk.

The useful response is not panic or a blanket claim that every coding agent behaves the same way. It is a reproducible incident process: establish the affected version, revoke access, find the exposure surface, configure each data path, constrain the agent, and verify the result.

Audit one agent integration with Aident Loadout, then inspect its current schema and recent calls before granting write access.

Sources

• cereblab: What xAI's Grok Build CLI sends to xAI

• cereblab: Grok Build exfiltration reproduction repository

• xAI: Grok Build source repository

• xAI: Grok Build configuration

• xAI: Grok Build slash commands

• xAI: Grok Build sandboxing

• xAI: Grok Build permissions and safety

• Gitleaks

• GitHub: Removing sensitive data from a repository

Refresh this guide if Grok Build changes its repository-sync, privacy, telemetry, trace-upload, or sandbox controls; if xAI confirms deletion for previously uploaded repositories; or if new independent network tests establish different current behavior.