Using AVL Code to Verify the Grok Build CLI Repository-Upload Incident

In an era of explosive growth in code-generation capability, the behavior of agents needs all the more to be visible and controllable.

Around July 12 Beijing time, security researcher cereblab published a packet-capture analysis of Grok Build CLI, which was then relayed by a number of Chinese media outlets. The core allegation comes down to a single sentence: when you run Grok Build CLI v0.2.93 inside a repository, it packages the entire repository, together with its full git history into a git bundle and uploads it — over a channel separate from the model conversation — to xAI's Google Cloud Storage bucket grok-code-session-traces, even if you explicitly tell it not to read any files, and even if you have configured a deny-read rule for sensitive files in the settings.

cereblab's packet capture put a scale on that allegation: with a 12 GB test repository, only 192 KB of traffic in a single session actually went to the model conversation, while in the background about 5.10 GiB of the complete repository bundle was silently sent out — a difference of roughly 27,800 times. He had also planted a decoy secret file in the repository, clearly marked "do not open"; afterward, running git clone on the bundle captured from the cloud, that file was still there intact: the upload channel applies no file filtering whatsoever.

This is the kind of allegation best verified by technical means rather than left at second-hand retelling. We obtained the offline installer sample for the version cereblab pointed to, grok-build-0.2.93~3880d629a6.pkg, and ran static analysis on it with AVL Code: decompressing it, computing entropy, extracting strings and IOCs, parsing the ELF binary inside, and then checking the results against the rumor point by point. This article addresses three things: whether the upload mechanism described in the rumor really exists in the client code, what its channel and switches look like, and how far static analysis can prove things — and which conclusions must rely on cereblab's dynamic packet capture.

Verification Results

The conclusions first. Static analysis of this offline sample can confirm the following:

• The binary hard-codes the upload target bucket grok-code-session-traces, along with a set of upload switches independent of the model channel (GROK_TRACE_UPLOAD_BUCKET, GROK_TELEMETRY_TRACE_UPLOAD, and others);
• The client holds full-control-level OAuth permission over GCS (devstorage.full_control);
• The sample contains both git bundle / git clone strings and permission-control strings such as --deny, --always-approve, and blocked by a permission policy;
• The upload target endpoint is POST /v1/storage, over api.x.ai/v1, physically separate from the model-conversation endpoint /v1/responses.

In other words, the chain described in the rumor — package the whole repository and upload it to GCS over a separate channel — has all of its parts fully present in the client binary: the bucket name, the upload switches, the cloud credential permission, and the packaging command all line up.

The boundary needs to be stated just as clearly: static analysis proves that "this mechanism exists in the code," not that "it actually uploaded your repository in any given run." The latter is a dynamic question — whether the upload really happened, how much was uploaded, whether files that were never read actually left the machine — and answering it depends on cereblab's mitmproxy packet-capture evidence, which an offline sample cannot supply on its own. Only together do the two form a complete chain of evidence: the static sample proves it can do this; the dynamic packet capture proves it did.

What the Rumor Comes Down To

cereblab's packet-capture analysis breaks Grok Build CLI's outbound traffic into two channels:

• The model channel: the content of files the agent actually reads, sent to the model via POST /v1/responses;
• The storage channel: the entire repository packaged into a git bundle, uploaded to GCS via POST /v1/storage.

The key contrast comes from a test on a 12 GB repository: the storage channel uploaded about 5.10 GiB (split into more than 70 shards of roughly 75 MB each, all returning HTTP 200), while in the same session the model channel sent only 192 KB. The difference is roughly 27,800 times. That ratio alone shows that the scale of the upload has nothing to do with "which files the agent read" — it uploads the entire repository, not the sliver of context the conversation actually needs.

More direct evidence is the canary file. cereblab placed a file bearing a unique marker (CANARY-XR47P2-NEVERREAD) in the test repository and explicitly instructed the agent not to open it. Afterward, he reconstructed the git bundle from the captured upload traffic, ran git clone, then grepped — and that never-read marked file appeared intact in the recovered repository. This proves that whether a file is read by the agent and whether it leaves your machine are two entirely different things.

The rumor also makes several claims about things that "can't be turned off":

• Turning off the "Improve the model" switch does not affect the whole-repository upload — the trace_upload_enabled value returned by the server's /v1/settings stays true throughout;
• The deny-read rule in the settings (--deny) only blocks the agent's read action, not the file being packed into the bundle; and --always-approve can bypass the restrictions in the settings altogether;
• The only local means that actually keeps a file out of the bundle is .gitignore (files not tracked by git do not enter the bundle).

Where the Sample Comes From, and What It Is

Before talking about the analysis, first confirm that what we have in hand is "the same thing."

Entropy analysis also confirms that the decompression was correct: the original .pkg has an average entropy of about 7.999, close to the theoretical ceiling for compressed data, with no structured plaintext; after decompression it drops to 6.24, revealing analyzable tar metadata, ELF sections, and plaintext strings. The version number 0.2.93 matches the version the rumor points to, and the build time (July 12 UTC) falls squarely within the public-disclosure window.

What the Code Shows

After locating the strings and call traces related to upload, telemetry, and permissions, the main findings are as follows.

The Upload Target and Its Independent Switches

The sample strings clearly contain the upload-related bucket and switches:

gs://grok-code-session-traces      # session-trace upload bucket (appears adjacent to event in the raw strings)
storage.googleapis.com/grok-build-public-artifacts
GROK_TRACE_UPLOAD_BUCKET           # trace upload target bucket
GROK_TRACE_UPLOAD_ENDPOINT_URL     # upload endpoint
GROK_TELEMETRY_TRACE_UPLOAD        # trace upload switch
GROK_WORKSPACE_DATA_COLLECTION_DISABLED

The mere existence of these environment variables tells us one thing: the upload channel has its own set of switches, independent of conversation-facing options like "improve the model." The rumor's claim that "turning off model improvement does not affect the upload" has a counterpart in the code structure — the two were never the same switch to begin with.

Cloud Credential Permissions

The GCP OAuth scopes the sample requests include:

https://www.googleapis.com/auth/cloud-platform
https://www.googleapis.com/auth/devstorage.full_control

devstorage.full_control is full-control permission over the GCS bucket. For a client that writes user repositories into the bucket, this is the credential basis that lets it write.

The Packaging Mechanism

The sample contains both git bundle and git clone strings. git bundle create packs tracked files together with .git/objects, refs, and logs into a single file that can be restored with git clone — which is precisely the technical prerequisite for cereblab reconstructing the complete repository, including its full commit history, from the packet capture.

The Mismatch Between Permission and Upload

The sample shows traces of local permission control: --deny, --always-approve, blocked by a permission policy. But these strings correspond to checks at the read layer. Combined with the canary experiment, one can infer that a read denial acts at the "should the agent open this file" step, whereas the bundle packaging traverses "which files git tracks" — the two paths do not share the same decision. Hence the crucial mismatch: you deny the agent read access to secret.txt, yet it can still be packed into the bundle and uploaded — read control is not upload control.

The Core Taint Path: Git Bundle → GCS Upload

This is the core chain of the whole affair; the other channels (model conversation, telemetry, error reporting) are just side branches. Stringing the parts above together along the data flow, from the user's workspace to the xAI bucket, there are six stages in all:

① User workspace (taint source / Source)
   ├─ git tracked files (source, config, docs)
   ├─ .git/objects/   all commit objects
   ├─ .git/refs/      branches and tags
   └─ .git/logs/      reflog, incl. deleted / rewritten history
            │  traversal — by "what git tracks," independent of whether the agent read the file
            ▼
② git bundle create   →   single file, fully restorable via git clone
            │  contains full commit history and old versions
            ▼
③ Packaging / compression layer (tar + zstd)
            │
            ▼
④ HTTP request construction
   POST /v1/storage    Content-Type: multipart/form-data
   Authorization: Bearer <token>    shards ~75 MB each
            │
            ▼
⑤ Network transport layer   https://api.x.ai/v1/storage   (TLS, server-side routing)
            │
            ▼
⑥ GCS bucket (taint sink / Sink)
   gs://grok-code-session-traces
   credential: OAuth scope devstorage.full_control (full control)

Every stage of this path finds a landing point on each of two sides — "the static evidence from this offline sample" and "cereblab's dynamic packet capture" — the static side proving the parts are there, the dynamic side proving the parts are turning:

The transmission characteristics further show this is a stable, at-scale channel rather than incidental behavior: across cereblab's test repositories ranging from 64 MB to 12 GB, the storage channel had zero failures (the only failures came from the model usage quota, returning 402/429, unrelated to storage); the capture was cut off at 5.10 GiB of upload — the capture tool stopped, not the upload finishing on its own, so the actual outbound volume can only be higher. In the same session, the model channel sent only 192 KB, a difference of roughly 27,800 times from the storage channel: what gets uploaded is the whole repository, not the sliver of context the conversation needs.

Comparing whether the various local "off" measures are effective against this core path:

Community feedback mentions that GROK_TELEMETRY_TRACE_UPLOAD=0 and the local configuration [harness] disable_codebase_upload = true can turn off the upload. From the sample, the former switch does exist in the binary; but whether such a switch is overridden by a server-side flag in v0.2.93 is server-side behavior that an offline sample cannot determine on its own.

What Static Analysis Can Prove, and What Needs the Dynamic Side

To be clear and avoid overreaching:

What the offline sample can prove: every part of the upload chain — the bucket name, the upload endpoint, the upload switches, the devstorage.full_control credential permission, the git bundle packaging capability, and the mismatch between read permission and upload — genuinely exists in the v0.2.93 binary. This is the "can do."

What must rely on cereblab's dynamic packet capture: whether the upload happened in a given real session, the 5.10 GiB scale, the 27,800:1 channel ratio, and the intact recovery of the canary file. This is the "did," and static analysis cannot supply it.

Conclusions the offline sample cannot yield, and should not force: whether and when the server later turns off the upload with a flag — that is server-side behavior and not in the sample. But the sample does yield a related, more durable judgment: the upload capability is compiled into the client binary. Even if the server one day flips trace_upload_enabled to false, the client v0.2.93 still retains the complete upload code; the moment that server-side flag flips back, the upload resumes, with no need for the user to update anything. There is no way for the user to remove this capability locally.

What This Means for Users and Enterprises

Setting aside whether xAI uses this data for training (that is a policy question, not something this static analysis can prove) and looking only at the data boundary, there are a few things worth remembering here:

• Read permission is not the data boundary. The "may not read" you configure blocks the agent's eyes, not the packager's hands. For high-privilege coding tools, "what can be read" and "what will be sent" must be two separately auditable controls, not one shared control.
• The full git history is uploaded along with everything else, and the exposure is larger than you might think. The history contains deleted files, secrets hard-coded in old versions, and the author information of every commit — none of them in your current working tree, yet all of them in the bundle.
• Server-side-flag precedence means you cannot cleanly turn it off locally. When the final ruling on a switch lives on the server, the value a user sets locally is merely a "suggestion."

Basic actions for users and enterprises: actually put secrets and sensitive files into .gitignore (rather than relying on the agent's read denial alone); use isolated repositories with clean history for highly sensitive projects; run traffic audits and supply chain assessments on closed-source AI coding tools in enterprise environments; and keep records of versions, installer packages, and configurations for later verification.

Why AVL Code for This Verification

This analysis is a typical use case for AVL Code: all you have is an offline installer package, no source code, and the question to answer is "whether that upload mechanism from the rumor is actually in this binary." What this calls for is not the ability to write code but the ability to do security analysis — decompression and entropy, string and IOC extraction, PE / ELF / Mach-O parsing, disassembly and decompilation, YARA matching, plus conversational reasoning to string the evidence into a single path. AVL Code builds these capabilities into a coding agent, so "start from an outside rumor and come back to the local sample to verify item by item" can be done in one pass within a single workspace.

There is also a comparison that need not be avoided. The mismatch this incident exposed — reads can be denied but uploads cannot be blocked; a secret file leaves with the bundle once git tracks it — is exactly the line we drew hard when designing AVL Code: secret-class sensitive files are never uploaded under any configuration; threat intelligence does hash lookups by default and does not send out file contents, and when sample content genuinely needs to be sent out there is a separate confirmation step; directories outside the workspace must be attached explicitly, split into read-only and read-write tiers. These designs are written up in "How AVL Code Is Designed to Prevent a 'GPT-5.6 Wipes a Founder's Entire Drive in One Command'", and they take the same stance as our earlier verification of Claude Code's implicit marking mechanism: the data boundary of a high-privilege tool should be externally auditable, not something you can only trust.

A note of restraint: this does not mean "using AVL Code guarantees nothing will ever go wrong" — no engineering can make that promise. What it means is that the boundary is clearly drawn, written into the product, and can be verified, rather than scattered across a server-side flag the user cannot see or turn off.

More Than One Sample: In the Era of Large Models, Security Needs Agile Technical Proof

Through AVL Code's analysis of this offline sample, we and cereblab's original disclosure corroborate each other: version 0.2.93, that upload channel separate from the model conversation, the grok-code-session-traces bucket, and the devstorage.full_control credential permission all genuinely exist, one by one, at the code level. And on that very same day, Antiy Labs published a long report, "从论文"预告"到行为越界——Anthropic 事件从实证到伦理的分析" (in Chinese), giving a systematic assessment — from empirical evidence to ethics — of the incident in which Claude Code collected host information and uploaded it via implicit environment markers; that incident is exactly what our previous article verified. Seen together, the two point to the same structural risk: a handful of high-privilege, closed large-model clients are collecting and sending out data through channels that users cannot see and can hardly turn off. In the absence of sufficient transparency and external constraints, this kind of risk is no longer an isolated case but a shared predicament for users worldwide in the era of large models.

In an era of explosive growth in AI capability, what security practitioners face is no longer just attack payloads and behavioral analysis in the traditional sense, but an increasingly sprawling IT toolchain and ecosystem — AI coding tools, MCP, agents, and cloud backends interwoven with one another, new incidents and new rumors emerging thick and fast, their truth hard to tell at a glance. This places a new demand on security teams: the ability to verify agilely and quickly, to return to the sample and the evidence itself the moment a rumor appears. We insist on doing real-sample analysis for every rumor precisely because — as content generated by large models makes the true and the false ever harder to separate, discussion, once cut loose from technical proof, slides all too easily into a cycle of hearsay compounding hearsay; evidence that can be re-checked is the only way out of that cycle.

And Grok Build CLI is no small tool: about 152 MB decompressed, containing a Linux ELF, hard-coding more than 150 GROK_* environment variables along with a full suite of upload, telemetry, and authentication logic. Doing this verification purely by hand — decompressing, locating the binary, extracting strings and IOCs, comparing endpoints and permissions, then stringing them into a taint path — would take considerable time and effort, and it would be easy to miss a key link among the sprawling strings. Only when the security-analysis capabilities mentioned above are placed in a single workspace and driven uniformly by the session can this be finished within a controllable time and leave a re-checkable record behind. Cybersecurity work needs to be both fast and verifiable — which is exactly one of the reasons we built AVL Code.

Final Conclusions

Based on static analysis of this offline sample, three conclusions can be drawn.

First, the client-side upload chain exists. The bucket grok-code-session-traces, the upload endpoint POST /v1/storage, the upload switches, the devstorage.full_control credential permission, and the git bundle packaging capability are all genuinely in the v0.2.93 binary, matching the rumor point by point.

Second, the mismatch between permission and upload exists. A read denial acts only at the agent's read step and cannot stop a file from being packed into the bundle; the only local filtering that is definitely effective is .gitignore. This is a structural flaw of "read control ≠ upload control," not a configuration issue.

Third, the dynamic behavior and the server-side policy still need external evidence. Whether the upload actually happened in a given session, and at what scale, depends on cereblab's packet capture; whether and when the server turned the upload off, an offline sample cannot determine. But the sample can confirm one thing: the upload capability is compiled into the client, and the user cannot remove it locally.

So the thing most worth watching here is not any single number but the data boundary and transparency. For an AI coding tool that can read files, modify code, execute commands, and package an entire repository for outbound transfer, the scope, channel, and switches of the upload should all be clearly disclosed, auditable, and controllable. Only then can developers and enterprises decide, fully informed, whether and how to use it.

We'll be waiting at avlcode.cn, riding a cyber wild donkey — verifiable and controllable, the reins always in your hands.

Appendix: Complete Evidence Index

The evidence below comes from two kinds of source: items marked "sample" come from this static analysis of grok-build-0.2.93~3880d629a6.pkg (re-checkable), and items marked "packet capture" come from cereblab's public dynamic evidence (cross-validation). The two are listed separately for easier tracing of each.

A. Sample Fingerprint (Hashes and Size)

B. Core Network Endpoints

C. GCS and Cloud-Storage Credentials (Core)

D. Telemetry and Error Reporting (Side Channels)

E. Authentication and Credential Mechanisms

F. Inferred Key Modules (Strings → Function)

G. Key String Evidence Index (Quick Reference)

# Upload targets
gs://grok-code-session-traces
storage.googleapis.com/grok-build-public-artifacts

# Upload-channel switches (independent of the model channel)
GROK_TRACE_UPLOAD_BUCKET
GROK_TRACE_UPLOAD_ENDPOINT_URL
GROK_TELEMETRY_TRACE_UPLOAD
GROK_WORKSPACE_DATA_COLLECTION_DISABLED

# Cloud credential permission
https://www.googleapis.com/auth/devstorage.full_control

# Packaging and recovery
# v2 git bundle
git bundle
git clone

# Local permissions (apply only to reading)
--deny
--always-approve
blocked by a permission policy

# Endpoints
https://api.x.ai/v1            (/v1/responses, /v1/storage, /v1/settings)
https://grok.com/_data/v1/events
o4508179396558848.ingest.us.sentry.io

Other findings: the sample also contains more than 150 GROK_* environment variables, along with AWS S3-compatible support (endpoints such as s3., s3-fips., s3.dualstack., s3-accelerate., and sts.amazonaws.com) and cloud metadata addresses (169.254.169.254, 169.254.170.2, metadata.google.internal:80) — indicating that its storage backend can switch to S3-compatible object storage.

H. cereblab's Measured Packet-Capture Data (External Dynamic Evidence, Not This Sample)

References: cereblab, the "grok-build-exfil-repro" reproduction repository and the "Gist dc9a40bc" full analysis; TMTPost report. For related background, see also Antiy Labs, "从论文"预告"到行为越界——Anthropic 事件从实证到伦理的分析" (in Chinese). This article is based on static analysis of the offline sample grok-build-0.2.93~3880d629a6.pkg, cross-validated with the public dynamic packet-capture evidence above; the specific implementation may change across Grok Build CLI versions and server-side policy.

AVL Code — the AVL security engine, with intelligence at your side. From the Antiy Landi team.