Grok Build Uploaded Your Entire Git Repo to xAI, Secrets Included

TL;DR: Wire-level analysis of Grok Build v0.2.93 caught the CLI silently uploading entire git repositories to a Google Cloud Storage bucket called grok-code-session-traces. Unredacted .env secrets, full git history, and files the agent was explicitly told not to read were all present in captured traffic. The "Improve the model" opt-out had no effect on what left the machine. xAI open-sourced the repo on July 14, 2026 -- after the researcher published findings, not before.

On a 12 GB test repository, with a prompt explicitly telling the agent "Reply with exactly: OK. Do not read or open any files," Grok Build's model received 192 KB of data. Its upload channel sent 5.10 GiB. That ratio -- roughly 27,800 to 1 -- is not a measurement artifact. The codebase upload runs independently of what the model reads or is asked to do.

That is the central finding from a wire-level analysis published by @cereblab, an independent AI safety researcher. The full teardown, published as a GitHub Gist before xAI's open-source announcement, is reproducible at github.com/cereblab/grok-build-exfil-repro. The binary under test was grok 0.2.93 (build f00f96316d4b, SHA-256: 2a97ba675bd992aa9b981e2e83776460d94f469b510c0b8efe28b50d236d767c), installed via curl -fsSL https://x.ai/cli/install.sh | bash on macOS Apple Silicon. The researcher used mitmproxy to capture their own traffic on their own machine with known canary credentials -- no real secrets were exposed during the test.

IBTimes UK covered the findings on July 13, 2026 ("Grok Build Uploaded Entire Repositories When It Only Needed Parts of the Code, Researchers Say") -- the day before xAI open-sourced the repository.

What the wire capture found

Finding 1: .env secrets transmitted unredacted via two channels

When the researcher added a .env file to a test project containing canary credentials (API_KEY=CANARY7F3A9-SECRET-should-not-leave and DB_PASSWORD=CANARY7F3A9-DBPASS), both values appeared verbatim in captured traffic across two separate channels.

Channel one was the model turn. POST cli-chat-proxy.grok.com/v1/responses carried the .env contents as part of the context sent to the model. This is expected behavior for an agent that reads files -- when the agent opens .env, the model sees the contents.

Channel two was the session archive. A session_state bundle uploaded via POST /v1/storage also contained the canary values. This upload was not contingent on the model needing the file. There was no redaction of .env contents at the upload layer. The secrets file was treated identically to any other file in the workspace.

Two separate transmission paths for the same credential values means two separate points where those values are persisted in xAI infrastructure -- even if the model's use of them is expected and understood by the developer.

Finding 2: Whole-repo git bundle upload, including files the model was told not to open

The more consequential finding is the independent git bundle upload.

The researcher ran a targeted test: a prompt that explicitly instructed the agent not to open any files ("Reply with exactly: OK. Do not read or open any files") on a repository containing src/_probe/never_read_canary.txt with a unique marker string. The agent complied with the prompt. The model output was "OK." But POST /v1/storage still received an HTTP 200 response, and the captured payload was a 152 KB git bundle representing the entire repository -- 4 commits, 47 files.

Running git clone on the captured bundle recovered never_read_canary.txt with its unique marker verbatim. Compliance with the "do not open" instruction had no effect on whether the file left the machine.

The researcher replicated this on a second unrelated codebase (cereblab_auth) and got the same result.

The scale test proves the upload channel is not a partial sync or a diff-based update. On a 12 GB repository of random files (never read or referenced by the model at any point):

• Channel A (model context via POST /v1/responses): 192 KB total
• Channel B (storage via POST /v1/storage): 5.10 GiB across 73 chunks of approximately 75 MB each, all returning HTTP 200

The 192 KB figure represents model context and responses. It cannot carry 5.10 GiB. The upload pipeline is a separate system running alongside the model interaction, not derived from it.

The upload destination is named verbatim in the binary and in a staged metadata.json found during analysis: GCS bucket grok-code-session-traces, with per-file paths formatted as gs://grok-code-session-traces/repo_changes_dedup/v2/....

Third-party telemetry was also captured: POST api.mixpanel.com/track and /engage both returned HTTP 200 during sessions.

Finding 3: The "Improve the model" opt-out does not stop uploads

The researcher turned off the "Improve the model" setting in Grok Build's settings panel and re-ran the upload test.

After opting out, /v1/settings still returned:

• "trace_upload_enabled": true
• "upload_enabled": true
• "session_registry_enabled": true
• "max_upload_file_bytes": 1073741824 (1 GiB per-file cap)

The git bundle upload proceeded and the HTTP response was 200. The never-read canary file was recovered from the captured bundle exactly as before.

The toggle controls training data use, not data transmission. Turning it off opts you out of xAI using your sessions to improve the model. It does not prevent your repository from reaching grok-code-session-traces.

What the researcher did NOT prove

The analysis is careful about its scope, and any coverage of it should be too.

Upload does not equal training. The researcher documented repository contents reaching xAI's GCS infrastructure. Whether xAI uses that data for model training, fine-tuning, or any other purpose is governed by xAI's policies and user tier agreements -- not proven by the wire capture alone. The researcher made no attempt to verify downstream use of uploaded data.

The "not documented" claim is scope-limited. The assertion that these behaviors were not described in install materials is not an exhaustive audit of xAI's full documentation. The researcher evaluated what was presented during the install flow. xAI may have disclosed relevant behaviors in other parts of their terms of service or user documentation.

Canary secrets only. The researcher used fabricated credentials with known marker strings specifically to confirm transmission while avoiding real exposure. The test proves the mechanism; it does not demonstrate that any real credentials were accessed, exfiltrated for malicious purposes, or made available beyond xAI's infrastructure.

The researcher was methodologically careful. The findings deserve to be reported with the same care.

xAI's response -- reactive, not proactive

The sequence of events is important for evaluating how xAI handled the disclosure.

1. @cereblab publishes wire-level findings as a GitHub Gist.
2. IBTimes UK covers the story on July 13, 2026.
3. xAI disables uploads server-side. The flag in subsequent server responses reads disable_codebase_upload: true.
4. xAI adds a /privacy opt-out. The researcher wire-tests it and finds it operates as a data retention setting: uploads continue, but xAI commits not to retain the data. The upload itself is not blocked.
5. Elon Musk publicly commits to deleting all previously uploaded user data. As of this writing, that deletion has not been independently confirmed.
6. xAI open-sources the Grok Build repository on July 14, 2026.

The open-source release is often described as a transparency move. In one sense it is: the community can now audit what the binary does going forward, without relying on wire analysis. That is a genuine improvement.

But the timeline is what it is. The Gist was published and covered in the press before the open-source announcement. xAI has not stated publicly whether the open-source decision was caused by the disclosure. The sequence does not establish intent, but it does establish that external scrutiny preceded the offer of public auditability rather than following from it.

For teams making tool approval decisions, this distinction matters. A company that proactively opens its tools for audit before issues surface has different transparency characteristics than one that does so after researchers publish findings. Both the current (post-fix) binary behavior and the response pattern are inputs to that assessment.

What this means if Grok Build was installed before July 14

If anyone on your team installed Grok Build on v0.2.93 before xAI's server-side fix, repository contents reached grok-code-session-traces.

What was uploaded: The entire workspace as a git bundle, independent of what the model read. This includes every tracked file in the repository, the full commit history, and -- confirmed by the never-read canary test -- files the agent was explicitly instructed not to open.

What was not uploaded: Files outside the git working directory. The upload mechanism appears to be git bundle-based and scoped to tracked repository contents, not arbitrary filesystem access.

Secrets exposure: If a .env file was in the working directory during any Grok Build session on v0.2.93 and the agent opened it for any reason, the file's contents were transmitted via at least two channels: model context and session archive. If the agent did not open it, the git bundle still captured it as part of the repository upload.

What to do now:

• Rotate any secrets present in repositories where Grok Build was run -- API_KEY, DB_PASSWORD, database connection strings, cloud provider credentials, any .env file contents.
• The /privacy opt-out does not retroactively retrieve or delete data already sent. It affects retention of future sessions only.
• Elon Musk committed to deleting previously uploaded data. Treat secrets as potentially compromised until rotated regardless of whether that deletion has occurred.

4 actions for teams right now

1. Find out who installed Grok Build and when. Audit install logs or ask directly. The affected binary is version 0.2.93. If you cannot confirm the version, assume the worst-case timeline.

2. Rotate secrets in every repo where Grok was run. If you cannot determine which specific repositories were used with Grok Build, rotate credentials across all repositories to which affected developers had access. That is the safe scope.

3. Confirm Grok Build's status on your approved tool list. If it was not explicitly approved by your AI governance process before team members installed it, this incident is the trigger to clarify that AI coding agents require approval before installation. The AI acceptable use policy template covers this workflow. An unapproved tool with this data collection behavior is a vendor risk incident regardless of whether credentials were misused.

4. Review the enterprise documentation question before allowing reinstallation. The earlier Grok Build governance article (5 Questions Before Your Devs Install It) noted that the free tier operates under a consumer privacy policy that permits xAI to use interactions for model improvement, while an enterprise DPA exists but has not been documented for CLI-specific data handling. That gap remains open after this incident. Wait for official enterprise data handling documentation specific to the CLI before approving reinstallation for teams with regulated codebases.

The open-source question

The GitHub repository being public now means researchers can inspect source and verify binary behavior directly rather than inferring it from traffic analysis. That changes the security evaluation posture going forward in a useful way.

What open-sourcing does not do: retroactively address data collected under v0.2.93. It also does not substitute for enterprise data handling documentation. A visible source repository tells you what the code says; it does not tell you what happens to your repository contents once they reach grok-code-session-traces. Those are policy and contractual questions that require documentation, not code.

For teams using the AI vendor due diligence checklist framework, the Grok Build incident is worth adding to the checklist as a worked example: wire-level analysis revealed data collection behaviors not surfaced during standard vendor review. The lesson is that AI coding agents -- particularly those with local binary components -- require active traffic inspection as part of vendor evaluation, not just documentation review.

The post-fix version of Grok Build is what you evaluate for current use. But the decision to use it should wait for documentation that closes the enterprise data handling question the researcher's findings made concrete.

Related Reading

• Grok Build Enterprise Governance: 5 Questions Before Your Devs Install It
• AI Vendor Due Diligence Checklist 2026
• Vetting AI Tools for Malware and Supply Chain Risk
• MCP Server Security Governance Checklist 2026
• TypeScript AI Agent Security Incident Response Playbook 2026

Sources: cereblab, GitHub Gist -- Grok Build v0.2.93 Wire Analysis, IBTimes UK, "Grok Build Uploaded Entire Repositories When It Only Needed Parts of the Code, Researchers Say" (July 13, 2026).