開源作為危機公關：ZCode 靜默上傳 Git 歷史醜聞三日後，Z.ai 公開全部程式碼

2026 年 9 月 21 日，Z.ai 把 ZCode 的完整程式碼以 Apache-2.0 授權推上 GitHub。這次發布涵蓋 Electron 桌面應用、瀏覽器介面、終端代理、後端服務、共享 UI 元件與 agent 執行環境，官方定位是「完成補救承諾」。三天前，一位化名 ferstar 的開發者發布逆向工程報告，揭露這款 GLM 模型家族背後的北京公司推出的官方編碼客戶端，正在把使用者的整個工作區——包括完整的 Git 歷史——默默打包成加密檔案，上傳到阿里雲。

反轉的速度不尋常。而開源發布能證明什麼、不能證明什麼之間的落差，同樣不尋常。

ferstar 發現了什麼

這份 9 月 18 日發布的報告，先是透過拆解 Electron 安裝包，再輔以即時流量側錄，還原出 ZCode 的行為。浮現的圖像，遠非一般「遙測」二字可以帶過。

只要使用者處於登入狀態，客戶端就會向 Z.ai 後端請求阿里雲 OSS（物件儲存服務）的預簽名上傳憑證，以及一把單輪有效的 RSA 公鑰。接著，背景工作程序把整個作用中的工作區打包成 tar.gz，以 AES-256-CTR 加密，再用伺服器下發的 RSA 公鑰加密對稱金鑰，然後直接 POST 到阿里雲儲存端點。上傳完成後，webhook 回呼通知 Z.ai 後端快照已落地。

其中一個受檢安裝的數字很直白：一個 345 MB、含 42,411 個檔案的商業工作區，變成 313 MB 的加密檔案排隊上傳。而內容組成比檔案大小更關鍵——.git 目錄佔了 payload 的 86.6%：196.1 MB 的 Git LFS 資料、102.2 MB 的核心物件庫，加上 reflog。真正的工作樹，也就是開發者看得到、也刻意選擇打開的那些檔案，只佔 46.2 MB，約 13.4%。

這個比例正是整起事件的核心。Git 物件庫不是工作樹的快照，它是儲存庫的完整血脈。幾個月前誤 commit、之後又在新 commit 中刪除的金鑰；從未推送的本地分支；丟棄的原型；reflog 裡的殘骸——這些全都要等到有人對所有分支執行破壞性清除之前，都留在 .git 裡隨時可復原。一個把整個資料庫掃走的工具，撈走的是這個專案有史以來的每一把歷史憑證——包括開發者以為已經刪掉的那些。更糟的是，ferstar 的分析指出 RSA 私鑰只有 Z.ai 持有，這意味使用者連自己機器上那個加密檔案都解不開。本機 metadata 記錄了單一快照的多達 564 次上傳失敗重試——一個不成功不下班的重試狀態機。

關不掉的開關

ZCode 的設定裡有兩個看起來相關的開關。「Optimize Experience」管理的是內容能否用於訓練；「Repo Snapshot Indexing」控制快照上傳後伺服器端是否建立索引。ferstar 發現，兩個都關掉，客戶端照樣打包工作區、照樣嘗試上傳——這些開關管的是下游用途，不是擷取管線本身。Z.ai 公開回饋倉庫中另有多份報告，描述 ZCode 3.12.3 也有一樣的行為，包括在 repository indexing 設為 false 時仍產生快照。

Z.ai 在 9 月 18 日的聲明中，把問題歸因於「codebase indexing」功能——該功能在產品早期預設開啟，用於支援 session checkpoint 還原、版本回滾與 Repo Wiki。公司表示 Wiki 頁面生成時可能觸發儲存庫資料上傳，雲端生成完成後資料「立即銷燬、不予保存」。公司道歉，承諾開源程式碼、邀請第三方評鑑機構審查系統運作，並且——這一條在 Hacker News 上引來不少黑色幽默——給所有 ZCode 使用者加發一次每週額度重置。

「立即銷燬」這個說法的信任問題是結構性的，The Next Web 的報導講得最白：因為 Z.ai 用只有自己持有的金鑰加密上傳資料，所以只有 Z.ai 能證明資料已刪除。使用者無從驗證。

開源證明了什麼——又證明不了什麼

今天的發布比公關樣板實在得多。倉庫包含桌面主程式、網頁伺服器、供應商整合、遠端工作區元件與終端代理，三種發布形式都附上本地建置說明——不是圍著閉源二進位檔包一層薄薄的 UI 殼。README 對信任邊界的坦白程度也罕見：共享執行介面卡預設沒有作業系統層級沙箱、啟用的外掛可以掛入 hook 與外部程序、遠端環境可能收到提示詞、檔案、工具結果與憑證；日誌可能包含提示詞、程式碼、上下文與工具參數。部分憑證存在本地加密檔而非 OS 鑰匙圈。

開發者現在可以稽核客戶端是否仍請求上傳憑證、工作區擷取是否還存在於任何執行路徑、以及發布的二進位檔是否與公開原始碼一致。但這次發布做不到的，是證明伺服器端的任何事。客戶端程式碼能顯示送出了什麼；它無法顯示保留了什麼、誰存取過、Z.ai 的刪除聲明是否成立。ZCode 自己的公告也承認，閘道器之後的內部處理超出倉庫可驗證的範圍。值得注意的是，倉庫上線時只有兩個 commit——一次性的整合程式碼投放，而非開發歷史——而且沒有 SECURITY.md、沒有已發布的安全通告，使得 GitHub 安全分頁在上線當天沒有標準的私密回報管道，儘管「接受社群檢視」正是這次開源的官方理由。

不只一家的事

這不是第一起類似事件。Hacker News 上有人翻出：大約兩個月前，xAI 在一場幾乎相同的「整包上傳使用者儲存庫」爭議後開源了 Grok Build——不過 ZCode 的情況更糟，因為它根本沒有可用的退出選項。這起事件對 Z.ai 而言時機尤其難堪：這家以開放權重立牌子的公司——GLM 系列才在八月因史無前例的安全審查而延後發布——九月八日又被 NSA/CISA/FBI 聯合公告點名，指控參與對美國前沿模型的協同蒸餾。一家訴求「模型可以自己跑」的公司，被抓到客戶端的資料實務無法讓使用者檢視。

更深的教訓適用於所有廠商。每一款代理式編碼工具——Claude Code、Codex、Copilot、Gemini CLI、ZCode——都因其設計而擁有全面的檔案系統存取權，而光是過去一週，就有影響四款主流代理外掛系統的零點擊 RCE 漏洞 Plugin4Shell 亮相。信任的基本單位不再是模型的權重，而是包在模型外面的 harness：它讀什麼、記什麼、送什麼，以及它給你看的開關是否真的擋得住管線。Z.ai 已經讓自家客戶端的這一層變得可檢視。第三方稽核與可重現建置比對能否證實補救屬實——其他廠商是會主動跟進，還是等到被抓才跟進——將決定這起事件成為產業標準的起點，還是又一個附贈額度重置的警示故事。