Grok Build and ZCode Went Open Source After Silent Uploads: What a Million-Line Code Drop Actually Proves

Twice in two months, an AI coding tool was caught quietly packing up a user’s entire workspace and shipping it to the cloud. Both times the maker followed the same playbook: apologize, patch, then open-source the client. SpaceXAI (formerly xAI) did it with Grok Build in July. Zhipu (Z.ai) did it with ZCode in September. Open-sourcing has become the standard move for a coding tool caught with its hand in your .git directory. What that move actually proves deserves a harder look.

The two incidents, side by side

Date	What happened
2026-07-12	SpaceXAI disables default data retention server-side; Elon Musk promises all previously uploaded user data will be deleted 12
2026-07-13	Security researcher Cereblab uses mitmproxy to show the Grok Build CLI silently uploaded 5.1 GiB to a Google Cloud Storage bucket, while the model context actually needed about 192 KB 1
2026-07-15	SpaceXAI open-sources Grok Build under Apache 2.0 3
2026-09-18	Developer ferstar publishes a forensic analysis: the ZCode desktop client packs the entire workspace, encrypts it, and uploads it to Alibaba Cloud OSS 45
2026-09-18	Zhipu apologizes, blaming a “code repository indexing” feature tied to session checkpoints and Repo Wiki 6
2026-09-19	ZCode 3.14.0 ships with a changelog entry reading “fixed abnormal Repo Wiki upload” 7
2026-09-21	ZCode is open-sourced under Apache 2.0 and picks up nearly 5,000 GitHub stars within a day 89

The parallels run deep. In both cases the upload was far larger than any feature could justify. Grok Build sent the full git repo, commit history, and .env credential files untouched, and neither the in-app privacy switch nor an explicit disable_codebase_upload flag stopped it ¹. One user who ran it in their home directory reported it uploaded “my SSH keys, my password manager database, my documents, photos, videos, everything” ². ZCode’s package was a 313MB encrypted blob covering a 345MB workspace, of which 86.6% was .git history; the manifest listed 2,411 files, and one full upload failed 564 consecutive times ⁷¹⁰.

When the code is closed, doubt has nowhere to go

The ugliest part of both stories is how little standing a user had before anyone reverse-engineered anything.

ZCode’s privacy policy, updated June 15, 2026, says it collects “text, files, and code you submit in conversation.” It never mentions workspace snapshots or git history upload anywhere ¹⁰. The desktop UI offered two switches, one for “use for model training” and one for “index snapshots,” and on version 3.12.3 both switched off still triggered packing and upload ⁷. Even the encryption worked against the user. The client wrapped its AES key with a server-held RSA key and posted the blob straight to OSS, so the machine kept only an encryptedDataKey and the owner of the data had no way to decrypt and inspect their own backup ¹⁰. As one Hacker News commenter put it, “Envelope encryption + a server-held private key turns a local backup into remote asset extraction” ¹⁰.

In a closed-source state, suspicion cannot become a case. You cannot read the binary’s intent, you cannot decrypt your own data, and the privacy policy describes a product that does not match the one on your disk. What you have instead is a dependence on lone reverse engineers: Cereblab running mitmproxy on Grok Build ¹, ferstar doing packet-level forensics on ZCode ⁴. Two individuals, two months apart, doing the work the closed model made impossible for anyone else. Every upload behavior described here comes from published third-party forensics and the vendors’ own public statements and apologies; no claim about intent goes beyond what those sources establish.

Open source does not mean audited

Both companies reached for the same remedy, in similar words. SpaceXAI’s announcement argued that “publishing the code is the most direct way to build toward a robust and reliable harness” ³. Zhipu told 封面新闻 that “open-sourcing is an important first step to respond to user concerns and improve product transparency” ⁷.

Publishing code creates the possibility of an audit. It does not create an audit.

Look at the scale. The Grok Build repo is roughly 1.32 million lines of Rust across 77 crates, according to AgentScout ¹¹. ZCode’s open-source drop is 6,973 files and about 1.03 million lines in a single commit ⁸. No security researcher reads two million lines for free. What actually happened in both cases was spot checking. NxCode audited Grok Build’s data plane and confirmed the trace upload path is stubbed to return session_state_upload_unavailable, while flagging that one data-collection predicate is documented fail-open and another is fail-closed, so which one guards each path remains an open audit obligation ¹². ferstar re-reviewed the open-sourced ZCode and confirmed the upload chain is fully removed, with checkpointing now done as pure local git incremental diffing ⁷⁸.

The institutional audits are their own black box. Testing by the China Academy of Information and Communications Technology reportedly confirmed the production OSS bucket holds zero data and that 3.14.0 removed Repo Wiki and the upload chain, and antivirus firm NSFOCUS reportedly confirmed the bucket and its objects were deleted. As of the 封面新闻 report, neither organization had published its audit report or conclusions ⁷⁶. “Audited” ends up meaning someone credible says they checked. The check itself stays closed.

The open edition is not the product you were running

Even a serious audit of these repos would answer a narrower question than users are asking. Users want to know what the tool did in the past. The repos can only speak about the present, and even that is shaky.

ZCode’s repository has exactly two commits: an empty initial commit and one giant “feat: open source” commit. The internal history is flattened, so there is no way to trace when the upload feature was written or how it was removed ⁸. The irony is hard to miss. A product that crashed for packaging users’ full .git history open-sourced with zero git history of its own. Issues and pull requests are disabled ¹³. The Computer Use feature in the open edition is a placeholder stub, and much of the closed edition’s core logic sits in a native addon, build/Release/ax_native.node, that never shipped with the source ⁸. A comment still sitting in CodingPlanStatusActions.tsx reads “开源版不享受额度活动权益” (“the open-source edition does not enjoy quota campaign benefits”), which indicates the open build and the official download are treated differently server-side ⁸.

Grok Build’s repo has the same shape. The source is periodically synced from an internal monorepo, with a root SOURCE_REV file recording the internal commit SHA. CONTRIBUTING.md explicitly rejects external pull requests, GitHub issues are disabled, and security reports go to HackerOne while general feedback goes to Discord ¹⁴. The public snapshot is a single squashed commit with no tag-to-binary provenance chain, so nobody can verify that the binary you downloaded corresponds to the source you read ¹². To its credit, the repo does disclose its foundations: 12 tool implementations ported from openai/codex and sst/opencode, alongside 12 first-party ones, per its third-party notices ¹⁴.

Community discussion after the ZCode incident settled on three requirements for auditability: complete commit history, reproducible builds, and a public issue tracker ⁸. Scored against that list:

Requirement	Grok Build	ZCode
Complete commit history	One squashed monorepo snapshot 12	Two commits, history flattened 8
Reproducible build	No tag-to-binary provenance 12	No releases or tags; native addon withheld 89
Public issue tracker	Issues disabled, feedback to Discord 14	Issues and PRs disabled 13
Open edition equals shipped product	Upload stack still in tree, stubbed 12	Computer Use is a placeholder only; editions treated differently server-side 8

Zero for three, on both sides.

Why open source was still the only move

After all of that, it remains true that open-sourcing was the only step that moved anything. Closed, a user could not even gather evidence for an accusation. Open, ferstar could at least prove the narrow claim that the current version no longer uploads ⁷⁸. That proof has limits. It says nothing about what past versions uploaded, or since when. And ferstar’s finding that checkpointing works fine as local git diffing directly contradicts the original explanation that checkpoint rollback required upload ⁷⁸.

The fix itself deserves the same scrutiny. Independent reproduction recorded by UpXuu found that on the post-apology 3.12.3, the behavior stopped but not one line of the upload pipeline was deleted: the credential endpoint, the capture hook, the Repo Wiki generator, and the envelope crypto all remained in the binary. The fix landed at the defaults and config layer, plus taking Repo Wiki offline server-side, which means a server-side config change could theoretically switch it back on ¹⁰. Only in the open-sourced code is the capability actually gone ⁷⁸.

What to watch next

Both companies have made further promises. Zhipu says the code data the community flagged was never retained and never used for model training, announced a standing vulnerability-response program with rewards by severity, and added a “no data content retention” feature to its MaaS platform ⁶. One enterprise customer, Taiyuan Chengming, sent a letter demanding 12 answers and reserving the right to sue, then retracted it, citing evidentiary errors and overly aggressive wording; its engineers said the issue no longer reproduces on the updated version ⁷. Grok Build’s repo sits at 26,332 stars and 4,948 forks ¹⁵, and the story hit the Hacker News front page at 287 points and 97 comments, as reported by UpXuu ¹⁰. Attention is cheap. Verification is the scarce resource.

The tests that would actually settle this are boring and specific: a public issue tracker, real commit history going forward, reproducible builds that match the binaries on the download page, and published third-party audit reports. Neither project has delivered any of them yet.

References

Conclusion

Two AI coding tools got caught doing the same thing, apologized the same way, and reached for the same remedy within two months of each other. Open-sourcing the client was the right call in both cases, and the only call that gave outsiders any footing at all. But a code drop with flattened history, disabled issues, withheld native components, and no reproducible build answers the easiest question, what the code says today, while leaving the hard ones, what it did before and who actually checked, exactly where they were. Trust in these tools will be rebuilt the slow way: through published audits, verifiable builds, and issue trackers that stay on. Stars and a single giant commit are only a starting point.

Footnotes

1. 智柴网 (Zhichai) — Cereblab’s mitmproxy analysis of Grok Build CLI uploading 5.1 GiB to the grok-code-session-traces GCS bucket https://zhichai.net/topic/178395179 ↩ ↩² ↩³ ↩⁴

2. Simon Willison’s Weblog — “Grok Build” coverage including the home-directory upload report and SpaceXAI’s data retention reversal https://simonwillison.net/2026/Jul/15/grok-build/ ↩ ↩²

3. x.ai Official Announcement — Grok Build open-sourced under Apache 2.0, “the most direct way to build toward a robust and reliable harness” https://x.ai/news/grok-build-open-source ↩ ↩²

4. 界面新闻 (Jiemian) — Report on ferstar’s forensic analysis of the ZCode desktop client’s encrypted workspace upload https://www.jiemian.com/article/15121635.html ↩ ↩²

5. Hacker News — Original thread on ferstar’s ZCode forensic analysis https://news.ycombinator.com/item?id=49750694 ↩

6. 每日经济新闻 (NBD) — Zhipu’s apology, Repo Wiki explanation, MaaS no-retention feature, and vulnerability-response commitments https://www.nbd.com.cn/articles/2026-09-21/4587856.html ↩ ↩² ↩³

7. 封面新闻 (Cover News) via 网易 — ZCode upload forensics, the 3.14.0 fix, the Taiyuan Chengming letter, and CAICT/NSFOCUS audit status https://www.163.com/dy/article/L7GIH3FN0514D3UH.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

8. 技术栈 (Jishuzhan) — Analysis of the open-sourced ZCode repo: two flattened commits, placeholder-only Computer Use, open vs closed edition differences https://jishuzhan.net/article/2102320027056394242 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³

9. 七牛云 (Qiniu News) — ZCode open-sourced at github.com/zai-org/ZCode, nearly 5,000 stars within a day https://news.qiniu.com/archives/1789970579947 ↩ ↩²

10. UpXuu — Technical breakdown of ZCode’s silent git upload: encryption chain, privacy policy gaps, and post-apology reproduction https://upxuu.com/posts/zcode-silent-git-upload-forensics/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

11. AgentScout — Report on the Grok Build open-source release and privacy scandal; repo scale estimate of 1.32M lines of Rust across 77 crates https://agentscout.live/zh/tech/dev-tools/news/20260723-xai-grok-build-open-source-privacy-scandal/ ↩

12. NxCode — Independent data-plane audit of the open-sourced Grok Build snapshot https://www.nxcode.io/zh/resources/news/grok-build-open-source-data-plane-audit-2026 ↩ ↩² ↩³ ↩⁴ ↩⁵

13. 蚁工厂 via 新浪 — Notes that ZCode’s GitHub repo has issues and PR creation disabled with no original commit history https://www.sina.cn/news/detail/5345520728147920.html ↩ ↩²

14. Slow Signals (vocus) — Grok Build governance analysis: monorepo sync, no external PRs, issues disabled, third-party tool foundations https://vocus.cc/article/6a6571e5fd89780001880eb3 ↩ ↩² ↩³

15. GitHub — xai-org/grok-build — Grok Build repository (26,332 stars, 4,948 forks) https://github.com/xai-org/grok-build ↩