ZCode 將 42,411 個檔案打包成只有智譜能開啟的壓縮檔

2026 年 9 月 18 日，一位以筆名ferstar寫作的開發者，發布了對ZCode這款由中國模型開發商Zhipu AI打造的桌面 AI 編碼代理的拆解分析。他是在注意到家目錄中一個隱藏資料夾已增長到超過 700 MB 後才發現此事。他在其中找到一個 313 MB 的加密壓縮檔，內含取自 345 MB 工作區的 42,411 個檔案，其中 86.6% 是 Git 歷史紀錄；該壓縮檔由用戶端打包，並準備上傳至 Alibaba Cloud 物件儲存。壓縮檔以只有 Zhipu 伺服器能解開的金鑰密封，而用戶端沒有提供任何可阻止其建立的開關。Zhipu 當晚致歉。完整紀錄連同該壓縮檔自身的信心評級與危害狀態，收錄於Orca AI Incident Archive，該資料庫會將每起有紀錄的 AI 事件與其引用來源對照記錄。

ZCode 是 Zhipu 的桌面編碼代理：它會讀取專案、執行 shell 指令並撰寫程式碼。該公司在香港以股票代號 2513.HK 交易，並將其國際業務品牌名為 Z.ai，這也是 ferstar 檢查的 ZCode 伺服器上出現的名稱。事後採訪他及其他幾位開發者的上海新聞媒體《The Paper》報導，他的貼文標題大意為「揭開 ZCode 暗中上傳完整 Git 歷史的帷幕」，且文章發布後數小時內便在中國開發者群組中流傳開來。

隱藏資料夾裡面有什麼？

Ferstar 本人提供的數字是本案的骨幹，而 The Next Web、InfoQ 與 China National Radio 財經部均一致複現了這些數字。他的 ZCode checkpoints 目錄中的封存檔為 313 MB。一旁的狀態檔案記錄了約 345 MB、42,411 個檔案的工作區。.git 目錄佔了資料量的 86.6%：196.1 MB 的 Git 大型檔案儲存快取、102.2 MB 承載完整提交歷史的 Git 物件，以及一小部分 reflog。實際的原始碼與文件合計約佔 13.4%。

這種區別很重要，因為 Git 歷史正是那些已從目前樹狀結構中移除的資料往往得以留存的地方。《The Paper》的報導直接指出了這一點：這類封存檔可以承載專案從首次提交以來的編輯歷史、已刪除的內容、未提交的草稿與較舊的設定檔，包括那些早已從程式碼中移除、但仍留在較早提交與大型檔案快取中的憑證。

Ferstar 自己那份 313 MB 的封存檔從未離開他的機器。其狀態日誌顯示有 564 次上傳失敗嘗試，而且它因超過大小限制而停滯在待處理狀態。為了測試這條管線究竟能不能運作，他試了一個包含 538 個檔案的小型公開儲存庫；該快照經壓縮與加密後約為 15 KB，並被伺服器接受。那筆傳輸是紀錄中唯一經確認已端到端完成的傳輸，而這也正是讓該發現從單純閱讀程式碼的練習，轉變為具有已證實接收端的外洩事件的原因。

擷取並未綁定到任何使用者會認作「上傳我的儲存庫」的動作。根據 ferstar 的重建，有一個觸發器會在每次提交給模型的提示詞之前觸發，另一個則以 Repo Wiki 更新任務的形式執行。刪除待處理的封存檔並沒有阻止它：Tencent Cloud 開發者社群上的一篇文章記錄，該套件在 30 分鐘內被重新建置，失敗計數器從 564 增加到 565。那位作者找到唯一可靠的停止方式，是將檢查點目錄設為不可寫，讓擷取在寫入磁碟時失敗，代價是失去檢查點回滾與時間軸介面。

只有廠商才能使用的金鑰

這段加密採用的是教科書式的信封加密，而這正是使用者無法繞過的部分。InfoQ 根據 ferstar 的逆向工程所還原的報導指出，用戶端會從 zcode.z.ai 取得快照 ID、RSA 公鑰與阿里雲 OSS 上傳憑證，在本機將工作區打包並加密，接著把密文直接傳送到 OSS。內容以 AES-256-CTR 加密；對稱金鑰則以伺服器公鑰透過 RSA-OAEP-SHA256 包裹，而該公鑰對應的私鑰始終留在智譜的雲端。

路由和密碼學同樣重要。因為客戶端直接上傳到 Alibaba Cloud，而非經由 Zhipu 自己的應用伺服器，流量沒有經過任何可記錄或過濾它的 Zhipu 服務，所以傳出路徑上沒有任何 Zhipu 服務能記錄或過濾離開的內容。而由於私鑰從未存在於裝置上，ferstar 無法開啟自己的封存檔：The Next Web 報導，他試遍機器上的每一把私鑰都失敗。他在貼文中將這種安排描述為一把只有伺服器能使用的金鑰，而它只有一個用途。

用戶端有兩項設定看似應該能阻止這種情況，但兩者都未能奏效。「optimise experience」切換開關控制資料能否用於模型訓練；「repository snapshot indexing」切換開關則控制伺服器是否要對已經送達的快照建立索引。兩者都作用於擷取之後的環節。Ferstar 發現擷取作業是無條件運行的，而 The Next Web 報導指出，他閱讀隱私政策後發現，政策提到會收集對話文字與檔案，卻完全沒提到自動工作區快照會帶有完整的 Git 歷史紀錄。

Zhipu 給出的解釋，以及在那之後的四天

智譜當天透過 ZCode 官方使用者群組、而非新聞稿作出回應。據《環球時報》報導、並經《安全內參》轉載，該公司將這一行為歸因於一項名為codebase indexing的功能，該功能支援本機索引、工作階段檢查點還原、版本回滾以及 Repo Wiki 生成，並表示正是 Repo Wiki 這一步觸發了程式碼儲存庫上傳至雲端。該功能自上線以來一直預設開啟。智譜表示，上傳的資料僅用於生成 Repo Wiki 頁面，隨後即被立即銷毀，不會被儲存，也不會用於訓練，並向受影響的使用者致歉。該公司承諾將開源 ZCode 程式碼庫，邀請第三方審查並公開結果，同時向所有 ZCode 使用者額外提供一次每週配額重置作為補償。

修正隔天推出。《澎湃新聞》（The Paper）報導，ZCode 3.14.0 於 9 月 19 日發布，更新日誌寫道「修正儲存庫 wiki 的上傳異常問題」，且 ferstar 同日確認上傳鏈及其端點已消失。9 月 20 日，智譜的 MaaS 平台宣布即將推出零留存選項，輸入與輸出不會被靜態儲存；《澎湃新聞》指出，此選項須由應用程式主動申請加入，不包含 Batch API 與 File API，且在法律或濫用調查要求時，仍允許保留 30 天以上。9 月 21 日，客戶端原始碼在 GitHub 以 Apache 2.0 授權公開，涵蓋桌面應用程式、網頁客戶端、後端、代理 CLI 與代理執行環境。

有兩份稽核受委託進行，其結論以摘要形式公布。中國信息通信研究院發現 zcode-prod 的阿里雲 OSS 儲存桶處於智譜所稱的零資料狀態。安全廠商 NSFOCUS 通報，所有資料物件與該儲存桶本身皆已被刪除，且其在 ZCode 3.14.0 中找不到任何仍可觸發本機儲存庫快照或將檔案外送的途徑。完整評估報告尚未出爐，The Next Web 報導指出，智譜並未給出報告的發布日期。

那位先提出更多指控、隨後又撤回的客戶

最嚴重的實際損失主張並非來自 ferstar。據中央人民廣播電台，9 月 19 日，太原辰明科技向 Zhipu 寄出編號為「辰明〔2026〕法律函字第 1 號」的法律函，ChainCatcher 詳細轉載了內容。該公司表示，其六個程式設計工作區在未經同意的情況下被上傳，共 34,500 個檔案、約 425 MB 的明文，並列出完整原始碼、系統架構、版本歷程、資料庫密碼、雲端憑證及員工個人資料。它還表示，第七個工作區的 1,947 個檔案、約 144 MB 已打包並加密，但 32 次上傳重試均失敗。它亦指出，其客戶端已於 9 月 16 日更新至 3.12.3 版，但 18 日凌晨 00:28、即 Zhipu 道歉當天上午，仍偵測到上傳行為。

這封信提出了一個稽核報告並未回答的問題：資料是否出境。Chengming 表示，ZCode 的網路請求指向一家新加坡實體，但其服務協議卻是與 Beijing Zhipu Huazhang 簽署；信中要求智譜說明哪一方應負責，以及是否曾在中國大陸境外進行任何傳輸或儲存。信中列出十二項要求，包括刪除所有已上傳資料及其衍生資料、快取與備份並提供書面證明；說明資料流向何處、是否與第三方共享或用於訓練；說明私鑰的保管方式並提供存取紀錄；界定「銷毀」說法的確切範圍；以及書面承諾永不再上傳。信中要求智譜在 10 月 10 日前書面回覆，並保留請求損害賠償及向監管機關申訴的權利。Caixin Global 報導，智譜稱這些指控不實。

兩天後，承明撤回了這些內容。中央人民廣播電台財經部報導，該公司於9月21日發布撤回聲明，稱其先前的聲明基於錯誤證據、不精確的描述與誇大的措辭，已損害智譜的聲譽，並表示將停止對媒體發言。據 The Next Web 報導，路透社也報導了這次撤回。此事件的檔案條目日期為9月18日，即發現當天；信函、其10月10日截止期限以及撤回聲明都在該日期之後出現。截至10月下旬的公開紀錄，沒有任何具名公司為其機密遭曝光的說法背書。

一個歷史遭抹除的開源發佈版本

將客戶端開源是智譜最倚重的補救措施，卻也留下一個缺口。《The Paper》報導指出，公開的儲存庫包含兩次提交：一次空的初始提交，以及一次新增約 6,973 個檔案與 103 萬行的提交；拉取請求被鎖定，問題也被關閉。它發布時的上傳管線究竟是什麼模樣，以及哪些版本包含了它，都不在任何人現在能讀取的歷史紀錄中。

Ferstar 本人的後續說明把這項限制講得很明白。他確認上傳管道已經不存在，且剩下的檢查點機制僅執行本機 Git 作業，接著指出對儲存桶進行稽核所能與不能顯示的內容：清空並刪除儲存桶是正確的停損措施，但在 9 月 20 日之後進行的第三方檢查只能證明該儲存桶在當時是空的。它無法重建 9 月 18 日之前流經的內容、是否有任何內容被解密、複製或備份，或該管道已運作多久。刪除的主張在很大程度上仍取決於刪除方的一面之詞。

InfoQ 的分析以相同措辭列出仍懸而未決的問題：成功上傳了多少個儲存庫快照、由多少名使用者上傳、物件被保留多久、哪些伺服器端系統或人員可以解密這些物件、是否存在完整的存取記錄，以及刪除是否涵蓋備份和其他副本。它也指出 ZCode 在修復後仍是什麼。專案自身的 NOTICE 警告，共用的代理執行環境預設不提供作業系統層級的沙箱，而用戶端仍保留 shell、終端機、Git、MCP、外掛與內嵌瀏覽器等介面，這些介面可在使用者帳戶權限內讀取檔案、啟動程序並存取網路。

哪些已確立，以及哪些沒有任何來源能回答

機制本身並無爭議。Zhipu 自己的聲明承認，儲存庫資料曾被上傳、該功能預設為開啟，且資料進入了公司控制的雲端儲存桶。Ferstar 的測量、供應商的道歉、兩份受託稽核以及開源發布，全都描述了同一條鏈路。記錄中沒有任何內容質疑：工作區是在沒有可用退出機制的情況下離開機器的。記錄所記載的損害已經實際發生，而非假設：傳輸確實發生了，而程式碼在其中的人既無法阻止，也無法檢查這些傳輸。

有爭議或根本未知的，是規模與後果。沒有任何來源說明有多少使用者使用了受影響的預設設定、該管線在 9 月 18 日前運作了多久，或是否有任何已上傳的物件曾被解密。Zhipu 保證資料在 wiki 生成後即被銷毀且從未用於訓練，但這是該公司自己的說法；CAICT 與 NSFOCUS 的調查結果描述的是修復後儲存桶的狀態，而非曾經流經其中的內容。該檔案庫在文件記錄方面將此紀錄評為 A，而文件在機制方面很紮實，在範圍方面則很薄弱。

哪些改變了，哪些沒有

商業代價隨即顯現。中央人民廣播電台報導，智譜港股股價於9月21日下跌1.79%、9月22日下跌6.55%、9月23日下跌12.4%，三個交易日累計跌幅超過16%，並稱智譜未說明有多少用戶受到影響，也未說明歷史數據是否已被解密或備份。

一位 ZCode 使用者在發現後的這四天內實際收到了什麼：

• 9月18日：公開道歉，指明程式碼庫索引是原因，承諾將客戶端開源並委託第三方審查，以及每位使用者每週額外一次配額重置。

• 9月19日：ZCode 3.14.0，移除了 Repo Wiki，並切斷了本機快照產生與上傳路徑。Ferstar 於隔日確認上傳鏈已不存在。

• 9月20日：Zhipu 的 MaaS 平台宣布提供零保留選項，採選擇加入制，不包括 Batch API 與 File API，且仍須遵守 30 天或以上的法定保留要求。

• 9月21日：ZCode 依 Apache 2.0 授權發布，但未包含其事件前的提交歷史；CAICT 與 NSFOCUS 的摘要報告指出儲存桶為空，且出口路徑不存在。

這些都無法回溯。Chengming 提出的具體問題——資料去了哪裡、誰能解密、是否出境，以及「銷毀」涵蓋了什麼——曾以書面形式提出並設定 10 月 10 日截止期限，後來又隨著提出這些問題的公司一起被撤回。智譜承諾提供完整的第三方評估報告，但未給出日期。在報告出現之前，關於這條管線如何處理其接收到的資料，唯一公開的說明來自建造它的公司；而唯一可獨立量測的產物，是一個 313 MB 的檔案，它曾 564 次未能離開某位開發者的筆記型電腦。