智谱 ZCode、Git履歴の全量をサイレントアップロードか：何が起きたのか

2026年9月18日、開発者 ferstar がリバースエンジニアリングの記録を公開し、智谱公式の AI コーディングデスクトップアプリ ZCode が、ユーザーのログイン中にバックグラウンドでワークスペース全体を梱包・暗号化し、阿里云 OSS へ直送する準備をすると指摘した。対象は今開いているソースだけではない。完全な .git 履歴、LFS キャッシュ、reflog、ワークスペースをまたぐグローバル設定まで含まれる。

開発者を刺したのは、「クラウドの coding agent が今のタスクに必要なコードをモデルへ送る」こと自体ではない。それはこの種のツールの前提だ。争点は別層にある。ユーザーに十分説明されず、UI では止められないバックグラウンドスナップショットが、リポジトリ作成以来の履歴ごと持っていく可能性があることだ。

本稿執筆時点で、智谱がこの仕組みについて正式説明を出した形跡は確認できていない。以下は ferstar の公開調査、中英の報道、Reddit の議論に限り、検証できる範囲だけを整理する。

まず二つを分ける：開放ウェイトなのは GLM、クローズドなのは ZCode

議論が始まると、「智谱の開放ウェイト」と「ZCode がリポジトリを上げた」が一つの話に見えやすい。それは別の主張である。

智谱は近年、GLM シリーズの開放ウェイトを出し続けている。たとえば GLM-5.3 は Hugging Face 上で MIT ライセンスのモデルカードとウェイトを提供する。開放ウェイトとは、自分で推論を立て、モデルファイルを監査し、選んだ harness に載せられるという意味だ。

ZCode はモデルではない。智谱公式のプロプライエタリ製品である。 GLM 向けの公式 harness / デスクトップアプリであり、インストーラはオープンソースではなく、クライアント全体をユーザーが監査できない。公式サイト zcode.z.ai は、これを GLM Coding Plan の公式環境と位置づけ、Goal による長時間タスク、リモート操作、GLM-5.3 との深い統合を前面に出している。

したがって今回の争点は製品層であり、ウェイト層ではない。

• 開放ウェイトの GLM と、オープンソースまたは自前の harness を使うことと、今回のスナップショット機構は直接関係しない。
• 公式 ZCode を入れてログインすることは、監査できないクローズドクライアントにリポジトリを渡すことと同じである。

この境界は、Reddit でもいちばん早く反応された。r/LocalLLaMA の投稿 ZCode was allegedly caught uploading workspace/.git records to the cloud は「Look like next grok build moment.」で始まっている。トーンを決めたコメントはさらに直接的で、オープンソースでない harness は使わない、というものだった。

ferstar が見たもの：pending に残った 313MB のスナップショット

中国語原文 と 英語版 によれば、始まりは劇的ではない。ディスク整理中に ~/.zcode が 700MB 超を占めており、うち v2/checkpoints/ が約 303MB だった。中には約 313MB の .enc ファイルと、状態メタデータがあった。

メタデータは具体的だった。

• ワークスペースはローカルの商用プロジェクトを指していた。
• 種別は baseline、つまり全量スナップショットだった。
• node_modules などを除いた後のワークスペースは約 345MB、暗号化後は約 313MB。
• failureCount は 564 で、この包はローカルの pending/ に残り、繰り返し再試行していた。

ここで境界をはっきりさせる必要がある。ferstar が自分のマシンで捉えたのは、まず「梱包済みでアップロード待ち」の成果物であり、クラウドに着地して誰でもダウンロードできるリポジトリ複製ではない。 同時にクライアントの app.asar を開き、ログと実行時接続を突き合わせてアップロード経路を復元した。パケットキャプチャでは、プロセスが zcode.z.ai と阿里云 OSS のノード二つへ常駐 HTTPS 接続を持っていた。

つまり、かなり高い確度で言えるのは、クライアントが梱包し、暗号化し、OSS の認証情報を取り、失敗後も再試行し続けることだ。各ユーザーのマシンでスナップショットが実際にクラウドへ入庫した件数は、公開資料に全球計はない。

アップロード経路：認証情報は智谱、ファイルは OSS へ直送

ferstar が復元した流れは二段階である。

1. クライアントが https://zcode.z.ai に /api/v1/snapshot/upload-credential を求める。サーバーは snapshot_id、RSA 公開鍵、サイズ上限、OSS フォーム署名、callback を返す。
2. ローカルでワークスペースを tar.gz にし、AES-256-CTR で暗号化し、対称鍵を RSA-OAEP で包む。その後 tar.gz.enc を PostObject フォームで 阿里云 OSS へ直接送る。OSS が callback して智谱バックエンドに登録する。

暗号そのものは一般的なエンベロープ暗号だ。争点はアルゴリズムではなく、鍵の帰属である。公開鍵はサーバーが動的に渡し、秘密鍵は最初から最後までクラウド側にしかない。ferstar は手元の秘密鍵すべてで envelope を解こうとして、予想どおりすべて失敗した。ディスク上の数百メガの暗号文は、ユーザーも ZCode クライアントも開けない。解けるのは智谱バックエンドだけだ。

これがユーザー向けのチェックポイント巻き戻しや端末間同期なら、鍵は通常ユーザー側に置くか、少なくともユーザーが持てる復旧鍵を用意する。サーバーだけが使える鍵は、ユーザーが復元できる保証というより、クラウドが一方的に読める保証に近い。

スナップショットの中身：八割超が Git 履歴

暗号文は開けないが、梱包時に残る Manifest は平文だ。ferstar が集計した一覧は 42,411 ファイルを含む。

.git だけで 86.6% を占める。

この包がクラウドに届いたとき、サーバーが得るのは「今開いているファイル」だけではない。リポジトリが作成以来残してきた痕跡まで届きうる。後から消した秘密鍵、未プッシュのブランチ名、.git/config にある社内 GitLab のホスト名とパス。コードには repo_snapshot_extra_manifest もあり、settings.behavior.json のような ZCode グローバル設定もまとめて入れる。

商用リポジトリでは、「今のファイルを補完のためにモデルへ送る」より一回り広い。Git 履歴には、かつてコミットして後から消した .env、内部 URL、一時鍵が残りやすい。作業ツリーからは見えない。オブジェクト庫には残っている。

設定では止まらず、プライバシーポリシーもこの層まで書いていない

ferstar は画面のスイッチとクライアントロジックを突き合わせた。

キャプチャ / アップロード用 sidecar は起動時に無条件で実体化される。ユーザー設定で止める if はコードになく、条件はログイン後の JWT だけだ。トリガーは、プロンプト送信前の captureBeforePrompt と、タスク終了時の repo-wiki-update。ログでは、一つの活発なセッションで最大 62 回のキャプチャが出ていた。

プライバシーポリシーについて、ferstar ははっきり書いている。対話中に提出した「テキスト、ファイル、コード」を集めるとは書いてあり、これは各社のクラウド coding agent が推論に使う範囲と一致する。しかしポリシー、FAQ、更新履歴を通して、ワークスペース全体と完全な Git 履歴を黙って梱包・アップロードする説明は見つからなかった。いちばん近いのは、「最適化プランは既定オフで、参加しなければ入力は学習に使わない」という定型文だ。

「学習に使わない」と「マシンから出ない」は別の制御である。この区別は、二か月前の Grok Build でもすでに一度出ている。

初めてではない：Grok Build は 7 月にほぼ同じ道を歩いた

2026年7月、cereblab 名義の研究者が xAI の Grok Build CLI 0.2.93 を回線レベルで解析した。The Hacker News は続いて報じた。このツールは agent が読んだファイルをモデル要求に乗せるだけでなく、Git リポジトリ全体を bundle にし、別のストレージ経路で xAI 利用の Google Cloud Storage バケット grok-code-session-traces へ上げていた。

対照は今も効く。

• モデルに「ファイルを一切読むな」と明示したテストでも、捕捉した git bundle から未オープンの canary ファイルが復元でき、完全なコミット履歴も付いていた。
• モデルが読んでいない約 12GB のリポジトリでは、モデル経路は約 192KB、ストレージ経路は約 5.10GiB だった。
• 画面の “Improve the model” を切っても、リポジトリ全体のアップロードは続いた。そのスイッチは学習許諾であり、コードがマシンを出るか否かではない。

7月13日、同じ 0.2.93 クライアントは /v1/storage への要求を止め、サーバーは disable_codebase_upload: true を返し始めた。ユーザーが新しいバイナリを入れたのではなく、サーバー側のスイッチだった。Elon Musk はその後 X で、予防措置として SpaceXAI に以前アップロードされたユーザーデータを completely and utterly deleted すると述べた。The Register は続きも記録している。企業向けゼロデータ保持（ZDR）、/privacy コマンド、数日後の Grok Build harness のオープンソース化である。

ZCode との重なりは明確だ。クローズドな harness、リポジトリ全体 / 全履歴、学習スイッチではアップロードが止まらない。差も同じくらい明確である。

• Grok Build で捕捉されたのは HTTP 200 で成功したストレージアップロードだった。ZCode の公開文では、著者自身のサンプルは 564 回の失敗再試行で止まっていた。
• 公開後、xAI はすぐにサーバー側スイッチを変え、Musk が削除を公言した。2026年9月18日時点で、智谱から同等の公開応答は出ていない。
• Grok Build はその後 harness をオープンソースにした。ZCode はいまもプロプライエタリなデスクトップアプリである。

コミュニティが二つを並べるのは、実装のバイトが一行ずつ同じだからではない。開発者がすでに同じ教訓を持っているからだ。高い権限を持つ coding agent の既定動作は、「体験最適化」のような学習スイッチだけでは判断できない。

Reddit が争っているもの：モデルか、harness か、既定の収集か

r/LocalLLaMA のこのスレッドの空気は、見出しより読む価値がある。議論はおおむね三層に分かれた。

第一は信頼の境界だ。/u/Voxandr の反応は、だからオープンソースでない harness は使わない、というものだった。/u/mikael110 は「悪意あるモデル」と「悪意ある harness」を分けた。harness がオープンで監査されていればセッションログは信じられる。クローズドな harness 自体が別種のリスクだ。

第二は検知の仕方だ。ローカルモデルまで「黙ってアップロードするよう学習されているのでは」と問う人がいた。後続コメントは、モデルがアップロードを要求しているのではなく、harness が起動時に自分で送り、セッションログにも書かないなら、普通のユーザーが session log を見ても足りない、と指摘した。ネットワークを見るか、harness を無通信環境で動かす必要がある。

第三は「みんなやっている」という反論だ。/u/Minute_Attempt3063 は、Cursor も Claude もコードベースを索引し、検索と文脈に使っている、と述べた。この比喩は半分しか当たらない。クラウド agent が今のタスクのために一部ファイルを読み、索引することと、バックグラウンドで .git/objects、LFS キャッシュ、reflog をサーバーだけが解ける全量包にすることは、データの範囲が違う。cereblab の Grok Build 比較でも、Claude Code と Codex のテストではリポジトリ全体の bundle は見られなかった、と書かれている。

割引と誘因を結びつける人もいた。公式 harness を GLM と組み合わせると割引があり、ユーザーは自前のオープンなワークフローではなくクローズドクライアントへ誘導される。これは「アップロードの目的が学習だ」という証拠にはならない。公式デスクトップが特に疑われる理由の説明にはなる。

ユーザーが今できること

公式が本当に止められる製品スイッチを出すまでは、ferstar の暫定策はディレクトリをロックすることであり、pending 包を手で消すことではない。消してみると、三十分以内にクライアントが新しい 313MB の圧縮包を作り、失敗回数は 564 から 565 になった。

macOS

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

# 確認：Operation not permitted が出るはず
touch ~/.zcode/v2/checkpoints/test

Linux

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

# 確認：Operation not permitted が出るはず
touch ~/.zcode/v2/checkpoints/test

ferstar の説明では、カーネルが書き込みを止めたあとローカル成果物がなくなり、OSS 直送も送るものを失う。代償はチェックポイント巻き戻し / タイムラインが使えないことだ。会話、補完、ツール実行は続く。戻すときは chflags nouchg または chattr -i を実行する。

より安定した製品選択は、なお次のとおりだ。

• 秘密鍵、顧客コード、未公開の業務を含むリポジトリを、監査できないクローズドクライアントに渡さない。
• GLM の能力が欲しいなら、公式デスクトップを既定で入れるのではなく、開放ウェイトと自分で制御できる harness を優先する。
• すでに ZCode で商用リポジトリを開いた人は、Git 履歴が梱包キューに入った可能性を仮定し、古いコミットに出たことのある認証情報を必要に応じてローテーションする。

これは OpenClawは安全か？公式情報に基づくリスク整理と実践的な対策 を書いたときの判断と同じだ。リポジトリを読み、ターミナルを動かし、Git に触れる agent は、普通のエディタプラグインとしては扱えない。

いまはまだ書けない結論

公開資料では、次の点はまだ支えられない。

• 智谱がスナップショットを学習、人手確認、チェックポイント索引のどれに使うか。ferstar にも、こちらにもサーバー側の証拠はない。
• 世界で何人分のスナップショットが OSS へ成功したか。公式数字はない。
• 機能設計なのか、文書の遅れなのか、意図的な隠蔽なのか。「止められない + 鍵はクラウドだけ + ポリシーに書いていない」はリスク判断には足りるが、確認済みの悪意あるバックドアとしては書けない。
• 智谱が xAI のようにサーバー側スイッチを変え、プライバシー説明を足し、ワンクリックで止められるようにするか。公式応答を待つ必要がある。

未確認の動機を事実として書くことは、読者の助けにならない。復元できたクライアントの振る舞いをはっきり書くことが役に立つ。

こうした争いは最近、孤立していない。Claude Code は今年すでに、隠れたマーキングとソース露出で「agent がローカルで何を余分にしているか」を表に出した。Claude Codeのバックドア騒動を整理する と Claude Codeの「ソース流出」で、コミュニティは何を議論しているのか を参照できる。中国モデルの開放ウェイト公開のテンポと公式製品の結びつきも並行する話題で、2026年の中国LLM情勢 に書いた。

よくある質問

ZCode が Git 履歴を上げたと報じられたのは、GLM モデルがデータを盗んでいるということか

層が違う。GLM シリーズの開放ウェイトはローカルで走らせられる。今回解析されたのは、クローズドクライアント ZCode のスナップショットアップロードロジックだ。公式デスクトップを使わず、開放ウェイトモデルと自分のツールチェーンだけを使うなら、この梱包フローは自動では継承されない。

これは「コードがすでに智谱のサーバーにある」ことの証明か

ferstar が公開したサンプルについて、正確な言い方はこうだ。クライアントは全量梱包と暗号化を終え、564 回の失敗再試行を記録した。アップロード経路と OSS 接続は復元されたが、そのサンプル自体は pending のままである。「仕組みがある」を「全ユーザーのリポジトリがすでに入庫した」と同じ文にしてはいけない。

「体験最適化」を切れば止まるか

ferstar がコードと照合した結果では、止まらない。そのスイッチは学習許諾であり、スナップショットのキャプチャとアップロードはログイン後も動く。

Grok Build と比べて、どちらが深刻か

似ているのはリポジトリ全体 / 全履歴、学習スイッチが効かないこと、クローズドな harness だ。Grok Build には回線レベルで成功したアップロードの証拠があり、その後サーバー側停止と削除の約束があった。ZCode はいま公式説明を欠く。深刻さは見出しの大きさではなく、今後の応答で決まる。

それでも ZCode を使いたい場合は

少なくとも ~/.zcode/v2/checkpoints をロックし、秘密を含むリポジトリでは使わず、公式が検証可能なオフ手段を出すかを待つ。「チェックポイント / タイムライン」を、コードをクラウドへ送る代わりに得る機能だとみなしてから、その便利さが値するかを決める。

まとめ

2026年9月18日のこの騒動の核心は、智谱が開放ウェイトモデルを出しているかどうかではない。公式コーディングクライアントが「リポジトリ全体のスナップショットをクラウドへ送る」ことを説明し、止められるようにしているかどうかだ。

ferstar の証拠連鎖は、使う側が警戒を上げるにはすでに足りる。ログイン後のバックグラウンド梱包、サーバーだけが解ける暗号、スナップショットの八割超を占める Git 履歴、画面のスイッチでは止まらないこと。それは「確認済みの国家レベルの窃取」としては書けない。同時に、「Cursor もコードを索引する」で軽く流すべきでもない。

Grok Build は二か月前に、こうした仕組みが表に出れば、ベンダーは既定値を変え、スイッチを足し、harness をオープンソースにさえできると示した。ZCode はいま同じ問いの前にいる。開発者が欲しいのは感情ではない。止められ、監査でき、プライバシーポリシーと一致する振る舞いである。

関連リンク

• Inside ZCode: Silently Uploading Your Entire Git History to the Cloud（ferstar、英語）
• 中国語原文
• ferstar の X 投稿
• Reddit / r/LocalLLaMA スレッド
• 藍点網の転載
• The Hacker News：Grok Build が Git リポジトリ全体をアップロード
• ZCode 公式サイト