Grok Build 0.2.93 Uploaded Whole Git Repositories Before Server-Side Shutdown

2026-07-14 Agent & Supply Chain Security by al-ice.ai Editorial

Independent wire-level testing of xAI's Grok Build coding CLI found that version 0.2.93 uploaded a Git bundle containing an entire tracked repository and its commit history, even when the agent was told not to open any files. The researcher recovered a never-read canary file by cloning the request body captured from an accepted POST /v1/storage upload.

The finding is narrower—and more useful—than saying every local file was indiscriminately exfiltrated. The demonstrated repository bundle contained Git-tracked files; the published reproduction says Git-ignored files stay out of that bundle. A separate model-context channel sent files that the agent actually read, including a tracked test .env with fake secrets, without redacting the canary values. The testing proves transmission and storage in the tested configuration, not model training or malicious intent.

Read permission and repository upload were separate controls

Researcher cereblab tested the official Grok Build CLI on macOS with mitmproxy, a throwaway account, and repositories containing unique canary strings. The published evidence identifies grok 0.2.93, build f00f96316d4b, and documents two distinct outbound paths.

The first path, /v1/responses, carried the content needed for a model turn. When Grok read a tracked secrets file, the fake API_KEY and DB_PASSWORD values appeared verbatim in the captured request and in a staged session-state archive. A control file that the model did not read was absent from this model-turn channel.

The second path, /v1/storage, was not limited by the model's read decisions. With the prompt “Reply with exactly: OK. Do not read or open any files,” the CLI uploaded a Git bundle that returned HTTP 200. Cloning that captured body recovered the never-read file and four commits. A second unrelated repository reproduced the behavior. The public harness also reports that an explicit Read(secret.txt) deny prevented the model from reading the file into chat but did not remove the tracked file from the uploaded bundle.

This control-plane split matters. A file-read policy can constrain what enters a conversation while a background collection pipeline independently packages the workspace. Security reviews that test only tool permissions or inspect the visible model context can therefore miss a parallel telemetry, synchronization, or trace-upload path.

The volume test tied storage traffic to the codebase

In a separate scale test, the researcher created a 12 GB repository of random files that the agent did not read. The preserved capture recorded 5.10 GiB sent through storage requests before the run was stopped, with the transfer still in progress. The model-turn endpoint carried about 192 KB in the same session. All 83 captured /v1/storage* requests returned HTTP 200, while model quota failures did not stop subsequent storage uploads.

The analysis associates the destination with the Google Cloud Storage bucket grok-code-session-traces, based on strings in the first-party binary, a staged metadata file containing gs://grok-code-session-traces/… identifiers, and observed storage traffic. It explicitly does not claim that the captured code was used for training.

xAI has stopped the codebase upload, but history still matters

As of July 14, the researcher's maintained update says xAI has disabled codebase upload server-side with disable_codebase_upload: true. The update also says a new /privacy opt-out controls retention rather than preventing all transmission, based on follow-up wire testing. xAI's public SpaceXAI account states that Zero Data Retention teams do not have trace and code data retained and that API-key use respects ZDR.

Elon Musk has publicly committed to deleting data uploaded before the change. At publication time, completion of that deletion had not been independently verified. Teams should distinguish three questions in their incident review: whether code left the workstation, whether the provider retained it, and whether previously retained objects have been deleted. A server-side stop addresses the first question going forward but does not by itself answer the other two for historical sessions.

Defensive engineering guidance

Treat cloud coding agents as data processors. Before use, document every channel that can send repository snapshots, traces, terminal output, prompts, attachments, and model context—not only files visibly opened by the agent.
Assume Git history expands the disclosure set. Removing a secret from the working tree does not remove it from earlier commits. Scan current files and reachable history, and rotate credentials rather than relying on deletion from the latest revision.
Keep secrets outside tracked repositories. Git-ignore local environment files, use short-lived credentials and secret managers, and add pre-commit and server-side secret scanning. This reduced the demonstrated bundle exposure, although any file an agent intentionally reads may still enter model context.
Do not equate read-deny with no-egress. Validate controls with packet capture, egress proxy logs, or provider-side audit records. Test background activity after the model is denied access, told not to read files, or blocked by quota.
Constrain outbound destinations. Run coding agents in isolated workspaces with allowlisted egress where practical. Alert on large or sustained uploads to model, telemetry, trace, and object-storage endpoints.
Review prior Grok Build sessions. Inventory repositories used with the CLI, especially on version 0.2.93, identify tracked secrets and sensitive history, preserve relevant proxy or endpoint telemetry, and rotate exposed credentials according to risk.
Verify current behavior rather than trusting a version label. The mitigation was reported as a server-side flag, so package version alone does not prove whether upload was enabled at a particular time. Record test date, authentication mode, privacy/ZDR setting, and observed network behavior.

The durable lesson is architectural: agent authorization and data collection are separate trust boundaries. A coding assistant can correctly refuse to read a file for the model while another subsystem still serializes the repository. Enterprise approval therefore needs evidence about the whole client—including trace collectors, update controls, retention semantics, and historical deletion—not just the agent's prompt-facing permission dialog.

Sources: