9月18日發表的一份逆向工程報告發現，中國模型公司Z.ai推出的桌面編碼應用ZCode，會把開發者的整個工作區——連同完整的Git物件儲存庫——打包後送往阿里雲的物件儲存，而且外層加密只有Z.ai自家伺服器解得開。
真正不尋常的不是上傳，而是金鑰由誰保管。壓縮檔以開發者無法開啟的密文形式落在阿里雲OSS上，而產生這份密文的流程，從未出現在應用的設定畫面中。
重點摘要
- 其中一份被擷取的快照包含42,411個檔案、體積313MB，光是.git目錄就占了整包內容的86.6%。
- ZCode把每份壓縮檔的AES-256-CTR金鑰，用伺服器臨時簽發的RSA公鑰包起來，對應的私鑰只留在Z.ai的雲端。
- Z.ai已致歉並修補用戶端，替ZCode使用者一次性重置每週用量上限，並表示將開放程式碼庫、邀請外部稽核。
為什麼交出Git目錄是最糟的事
撰寫報告的研究者以ferstar之名發表。他拆開用戶端的Electron套件，逐步還原了整條傳輸路徑。在一個345MB的商業專案上，產生的壓縮檔達313MB、共42,411個檔案，而其中絕大部分來自儲存庫本身的物件儲存。
這個比例才是重點。工作目錄呈現的是專案今天的樣子；物件儲存保留的則是它曾經歷過的每一種狀態。某次提交後又在下一次提交中移除的憑證，仍然留在歷史裡。被放棄的分支名稱同樣如此，那些名稱往往洩漏尚未發布的功能，還有儲存庫設定中記錄的內部主機名與遠端路徑。
Z.ai公開的隱私條款寫的是蒐集文字與程式碼，並沒有寫到蒐集一個儲存庫的完整血緣。
那兩個看起來像關閉鍵的開關
看完報告的人都會去翻偏好設定，而尷尬之處正在這裡。ferstar把介面與程式碼交叉比對後指出，「Optimize Experience」只決定擷取到的資料能否用於模型訓練，「Repo Snapshot Indexing」只決定伺服器是否為收到的內容建立索引，兩者都沒有碰到打包與傳輸。
報告指出，負責擷取的元件由主程序在啟動時建立，完全不依賴使用者偏好設定，唯一前提是一個有效的工作階段權杖。單一次作業過程就記錄到62次擷取事件，每次送出提示前觸發一次，任務完成時再觸發一次。
第二項證物強化了這個判斷。一份在公開的harness提示集中流傳的131KB ZCode系統提示副本，列出代理可用的31項工具，其中沒有任何一項負責上傳、快照或傳輸，而整份文件從頭到尾未提及阿里巴巴、OSS或上傳。外傳路徑完全落在代理迴圈之外，這也是為什麼從未跳出任何授權提示。
開放權重不等於開放的執行外殼
這件事之所以延燒，部分原因是討論串中可見的分類錯誤：不少開發者以為ZCode是開源的，因為GLM是開源的。Z.ai公開的是可下載的權重，而驅動這些權重的桌面用戶端是專有軟體，負責打包的正是這個用戶端。
兩種語言圈的傳播量都很可觀，ferstar的文章瀏覽數超過27.6萬，一則中文警示討論串再添6.38萬。被引用最多的反應來自開發者Petri Kuittinen，他直言不該信任任何閉源的AI執行外殼。
Z.ai的回應來得很快。公司道歉並表示擷取到的資料在處理後隨即銷毀、未予保留，接著推出修補、以重置用量上限補償使用者，並承諾公開ZCode程式碼庫、引入第三方檢視。
這件事對開發者的意義
對於正在權衡本地部署模型與廠商桌面用戶端的團隊來說，兩者的分界現在比先前清楚得多。開放權重說明的是模型是什麼，卻完全沒說包在外面��層對檔案系統做了什麼。任何具備檢查點或回復功能的AI編碼助手，在結構上都必然在對某些東西做快照——真正該問的是這些快照最後落在哪裡。今年其他代理外殼也受到類似檢視，包括在四款主流CLI代理上揭露的零點擊漏洞。
常見問題
ZCode是開源的嗎？
不是。Z.ai公開了GLM的模型權重，但ZCode桌面用戶端是閉源的，這也是這項快照行為在有人反編譯之前一直沒被發現的原因。該公司事後表示打算開放程式碼庫。
使用者能自行解密上傳的壓縮檔嗎？
不能。內容金鑰是用Z.ai伺服器提供的RSA公鑰包起來的，研究者用機器上的任何私鑰都無法解開。對應的私鑰只存在於Z.ai的基礎設施中。
關掉隱私設定能阻止上傳嗎？
報告指出不能。那兩個相關開關控制的是後續用途與伺服器端索引，而負責打包並傳輸工作區的元件，是在主程序層級執行，與這些偏好設定無關。
