開発者の ferstar 氏が 2026 年 9 月 18 日に公開したリバースエンジニアリング解析によると、智譜旗下の AI コーディングデスクトップクライアント ZCode は、ログイン状態においてユーザーのワークスペース全体を密かにパッケージ化して送信していた。内容には完全な .git 履歴、LFS キャッシュ、reflog、グローバル設定まで含まれ、サーバー側から配布された RSA 公開鍵で暗号化したうえ、Alibaba Cloud OSS へ直接アップロードされる。1 回あたりの出力は 313MB・42,411 ファイルの暗号化パッケージで、秘密鍵を保有するのは Z.ai のみ、UI 上の設定スイッチはすべて機能しない。Z.ai は同日に謝罪と修正・オープンソース化を約束したが、すでに送信済みのコード資産を技術的に完全に削除できるかどうかは明らかにされていない。
313MB の暗号化パッケージ、所有者本人にも開封不能
クライアントはバックグラウンドでワークスペース全体を圧縮・送信し、それを解読できる鍵はユーザーの手元にはない。
2026 年 9 月 18 日、研究者の ferstar 氏が ZCode のリバースエンジニアリング解析を公開した。ZCode は Z.ai が提供する AI コーディングデスクトップクライアントであり、Z.ai はまさに GLM 系列のオープンソースモデルの運営元である。
ユーザーがログインすると、クライアントはバックグラウンドでワークスペース全体——完全な .git 履歴、LFS 大容量ファイルキャッシュ、reflog、グローバルアプリケーション設定——を tar.gz に圧縮し、AES-256-CTR で暗号化したうえ、Alibaba Cloud OSS へ POST 送信していた。
ferstar 氏はパケットキャプチャにより、313MB の暗号化アーカイブを取得した。元データは 345MB・42,411 ファイルから成る商用ワークスペースで、その過程で 564 回のアップロード失敗を記録している。同一の解析内で彼は payload の内訳表も示している。.git/lfs が 196.1MB、.git/objects が 102.2MB、.git/logs が 0.6MB、ソースコードとドキュメントが 46.2MBで、.git ディレクトリ全体だけで 86.6% を占めていた。
暗号化はエンベロープ方式で行われている。ペイロードは対称鍵で暗号化し、その対称鍵をさらにサーバー側から配布された公開鍵で包む方式だ。この公開鍵は RSA-OAEP（非対称暗号化アルゴリズムの一つで、鍵のカプセル化によく使われる）である。ferstar 氏はローカルにあるすべての秘密鍵で復号を試みたが、すべて失敗した。秘密鍵は Z.ai の側だけが保有している。彼の言葉は明快だ。「サーバーが独占する鍵の役割はただ一つ——あなたのコードを読みたくなったとき、いつでも読めるようにすることだ。」
UI に設定がないわけではない。設定画面には「Optimize Experience」と「Repo Snapshot Indexing」という 2 つのオプションが存在する。しかし ferstar 氏がコードを比較したところ、前者はデータをモデルの学習に利用するかどうかを決めるだけで、後者はアップロード後にサーバー側でインデックス化を行うかどうかを決めるだけだった。キャプチャとアップロード自体はこの 2 つのスイッチでは制御できない。ホスト側の sidecar（メインプログラムと同時に動作する補助プロセス）は起動時に無条件にインスタンス化され、唯一の条件は有効な JWT（ログイン状態トークン）を取得できるかどうかだ。
Z.ai は同日夜、公式コミュニティでデータ送信を認め、「コードベースインデックス」機能によるものとした上で、wiki ページ生成後に削除する処理であること、当初デフォルトで有効化されていた件は修正済みであることを説明。さらに ZCode リポジトリの近日中のオープンソース化と第三者監査の受け入れを発表し、無料週間プランのリセットという補償も提示した。
スイッチはあるが、押しているのは全部「別の場所」
事件後、まず設定画面を開く人は多い。だがそこをいくら触っても無意味だ——ZCode のキャプチャ機能は設定ではなく、もっと下層のホストプロセスに組み込まれている。
「Optimize Experience」という名称は「あなたのデータでモデルを学習させるか」を管理しているように見えるし、実際その用途にしか使われない。キャプチャは通常通り走る。「Repo Snapshot Indexing」はもっとそれらしい——仓库快照索引、アップロードを制御するスイッチに見える？ それも違う。
このスイッチが制御しているのは、クラウド側がアップロード済みスナップショットにインデックスを作成して検索可能にするかどうかだけだ。クライアント侧の打包・上传は一切変わらない。両スイッチとも「コードを送信するかどうか」には関与していない。
セッションメトリクスの数字もはっきり示している。アクティブ 1 セッションあたり 62 回のキャプチャが発生し、各プロンプト送信前に 1 回、タスク終了時にさらに 1 回という頻度だ。キャプチャモジュールはホストプロセスに紐づいており、起動時に無条件でインスタンス化される——「ユーザーに同意を求める」ステップは存在せず、唯一の前置条件はトークンプロバイダが有効な JWT（ログイン後にサーバーから発行される使い捨て身份トークンで、临时通行证に相当）に署名できること、つまりユーザーがログインしているという事実だけだ。
AI エージェント自体も、こうした送信が起きていることを認識していない。OrcaPromptVault が取得した ZCode の 131KB 分のシステムプロンプトと 31 件のツールマニフェストには、「アップロード」や「テレメトリ」に関連する記述が一切なかった。エージェントは自分の世界での作業に没頭しており、背後で静かに進んでいるパッケージ化に気づいていない。
さらに厄介な点がある。ZCode には ReadSessionContext ツールが組み込まれており、セッション ID を指定してローカルの別セッションの内容を読み取れる。スナップショットによりセッション情報がクラウドに送られると、このツールはセッション横断的な読み取りも可能になる——ローカルに 1 份、クラウドにも 1 份、双方に保管される仕組みだ。
2 か月前にもまったく同じパターンの事件が起きていた——xAI の Grok Build が「学習スイッチをオフにしても、リポジトリはそのままパッケージ化して GCS（Google Cloud Storage、Google Cloud のオブジェクトストレージサービス）へ送信する」という方式を採っていたケースだ。当時は 5.1GB がアップロードされたが、モデルが実際に利用したのは 192KB のみで、5.1GB ÷ 192KB ≒ 28,000 倍の差があった。両事件の構造はほぼ一致している。UI 表面上はユーザーに制御権を与えているように見えるが、その制御対象はまったく別物だ。この仕組みがどう機能するのか、そして「スイッチをオフにする」だけではなぜ自衛できないのか、ユーザーが取るべき対策は何か——次節で解説する。