ZCode は静かに完全な Git 歴史を Aliyun OSS にアップロードする – 調査と対策

TL;DR

ZCode はプロジェクト全体（完全な .git 歴史、LFS キャッシュ、ローカル設定を含む）を暗号化し、サーバーが提供する RSA 公開鍵で暗号化した後、直接 Aliyun OSS にアップロードします。アップロードはログイン中常に実行され、UI で無効化できない上、復号鍵は Zhipu のバックエンドにのみ存在するため、サーバー以外はデータを読み取ることができません。

アップロードの仕組み – クライアント側の手順

クライアントはまず https://zcode.z.ai から一時的な RSA 公開鍵と OSS フォーム認証情報を取得し、AES‑256‑CTR で暗号化、RSA‑OAEP で鍵をラップした後、暗号化されたファイルを直接 Aliyun OSS にポストします。

sequenceDiagram
    participant C as ZCode client
    participant S as zcode.z.ai
    participant O as Aliyun OSS
    C->>S: POST /api/v1/snapshot/upload-credential
    S-->>C: snapshot_id, RSA public key, OSS policy, signature, object key
    C->>C: tar.gz → AES‑256‑CTR → RSA‑OAEP wrap key
    C->>O: POST multipart/form-data (tar.gz.enc)
    O->>S: callback confirming receipt
  • ステージ1 – 認証情報の取得: クライアントは ZCode コーディネーターに接続し、動的オブジェクトキー、サイズ制限、およびそのアップロードセッション用の RSA 公開鍵を取得する。
  • ステージ2 – 直接 OSS アップロード: ローカルでの暗号化後、クライアントは ZCode のサーバーを経由せずに、署名付きフォーム POST で暗号化されたデータ（*.enc）を Aliyun OSS にストリーミングする。OSS は Zhipu のバックエンドに通知する。

ネットワークキャプチャでは、このプロセス中に zcode.z.ai および 2 つの Aliyun OSS ノードへの継続的な HTTPS 接続が確認された。

ユーザーにとって暗号化が一方向である理由

RSA キーペアはサーバー上で生成され、公開鍵のみがクライアントに送られるため、クライアント（およびユーザー）はアップロードされたアーカイブを復号できない。

{
  "keyId": "String(i.encryption.key_version)",
  "keyWrapAlgorithm": "rsa-oaep-sha256",
  "publicKeySpkiPem": "Ylt(i.encryption.public_key)"
}
  • 一時的な対称鍵が AES‑256‑CTR で tarball を暗号化する。
  • 対称鍵はサーバーが提供する RSA‑OAEP‑SHA256 公開鍵でラップされる。
  • 秘密鍵はユーザーのマシンに届かず、ディスク上の 300 MB の暗号文はローカルでは読み取れない。

"サーバーが秘密鍵を保持するエンベロープ暗号化は、ローカルバックアップをリモート資産抽出に変える。" – @xcc3641 (HN コメント)

この機能がユーザー側の復元や同期を目的としていた場合、秘密鍵は Git や Time Machine と同様にローカルに保存されるべきである。その不在は、サーバーがいつでもデータを読み取れるようにするための唯一の目的であることを示している。

実際にアップロードされる内容 – 内容分解

アップロードされたペイロードの約 87 % が .git データであり、サーバーは完全なコミット履歴、LFS オブジェクト、リファレンスログ、さらには削除されたシークレットまで受け取る。

パス サイズ ペイロードの割合 内容
.git/lfs/ 196.1 MB 56.8 % すべての LFS キャッシュされたバイナリおよびメディア
.git/objects/ 102.2 MB 29.6 % 完全なオブジェクトストア（コミット、ツリー、ブロブ）
.git/logs/ 0.6 MB 0.2 % リファレンスログ – ローカルブランチの移動
ソースファイルおよびドキュメント ~46.2 MB 13.4 % src/、設定ファイル、ドキュメント

平文のマニフェスト（42,411 エントリ）がローカルに保存されており、アーカイブ自体が暗号化されているにもかかわらず、ディレクトリ構造が露呈している。

UI のスイッチはアップロードを停止しない

「最適化された体験」および「リポジトリスナップショットインデックス化」のスイッチは、すべてサーバー側の処理に影響するのみで、キャプチャとアップロードのサイドカーは起動時に条件付きで実行される。

スイッチ 意図された効果 実際の効果
optimizeAgentExperienceEnabled テレメトリを無効化 スナップショットのキャプチャとアップロードは継続；モデル学習の同意のみ無効化
repoSnapshotIndexingEnabled スナップショット機能を無効化 アップロードは継続；サーバー側のインデックス化のみ停止

クライアントは LLM プロンプトの前と、repo-wiki-update とラベル付けされたタスク完了イベントの際に captureBeforePrompt を呼び出す。1 セッションで最大 62 回のキャプチャイベントが発生する可能性がある。

プライバシーポリシーの欠落

公式の ZCode プライバシーポリシーは「会話中に送信されたテキスト、ファイル、コードの収集」について言及しているが、自動的かつ完全なワークスペーススナップショットおよび Git 歴史のアップロードについて一切明記していない。関連する唯一の条項は、最適化はデフォルトで無効であり、同意なしにデータが学習に使用されないという一般的な記述である。

コミュニティの反応と公式の対応

  • 複数のコメント者が、他の AI エージェントがドットファイルや無視ファイルを読み取る類似の挙動に注目している（例：@philbo）。
  • @acrispino は Zhipu の公開謝罪を共有し、この機能は「コードベースインデックス化」機能に関連する初期リリースのバグであり、Wiki 生成後にアップロードデータは破棄され、問題は修正されたと主張している。
  • 他のユーザーは信頼の喪失を表明し、サンドボックス化や隔離戦略の提案（@radio879 の広範なサンドボックス議論を参照）を行っている。

マシン上でアップロードを停止する方法

保留中のアーカイブを削除しても再キャプチャが発生するため、信頼できる対策は ~/.zcode/v2/checkpoints ディレクトリをファイルシステムレベルで不変にすることである。

macOS

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints   # 不変フラグを設定
# 確認: touch が "Operation not permitted" で失敗するはず

Linux

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints   # 不変属性を設定
# 確認: touch が "Operation not permitted" で失敗するはず

影響: チェックポイント/ロールバック UI は機能しなくなる（アップロードされたスナップショットに依存するため）が、通常のチャット、自動補完、ツール実行は正常に動作する。機能を復元するには不変フラグを解除する（macOS では chflags nouchg、Linux では chattr -i）。

結論

  • ZCode はワークスペース全体（完全な Git 歴史を含む）を自動的にキャプチャし、暗号化し、クラウドバケットにアップロードする。
  • 暗号化鍵は Zhipu のサーバーのみが保持しているため、サーバー以外はデータを復号できない。
  • UI 設定では無効化できない。ログイン中は常に実行される。
  • プライバシーポリシーにはこの挙動について一切記載されておらず、信頼性とコンプライアンス上の深刻な懸念を引き起こす。
  • ユーザーは checkpoints ディレクトリを不変にすることでローカルでアップロードをブロックできるが、ZCode のスナップショット・リストア機能を失う代償を払う必要がある。

"リポジトリ Wiki 機能が Wiki ページを生成する場合、リポジトリデータのアップロードがトリガーされる可能性があります。クラウド上で Wiki ページが生成された後、アップロードされたデータは直ちに破棄され、保存されません。" – @acrispino が引用した Zhipu の発表

推奨: ベンダーが透明性があり、オプトイン制の制御を提供し、復号鍵をローカルに保管しない限り、ZCode をデータ漏洩リスクとして扱うべきである。AI エージェントのサンドボックス化や、明確でユーザー制御可能なデータ処理ポリシーを持つツールの使用を検討すること。

Sources

関連

  • Dispatch
    ZCode は静かに完全な Git ヒストリをアップロードする – プライバシー侵害の分析

    GLM ベースのコードデスクトップアプリである ZCode は、ユーザーの完全な .git リポジトリを静かに暗号化し、アリババクラウドにアップロードしており、同意なしに数年のソースコード履歴を暴露している。

  • Dispatch
    GLM-5.2 用 ZCode Harness 概要

    ZCode は、デプロイメントと実験を簡素化する、すぐに使えるインターフェースを提供する GLM-5.2 モデル用のハーネスを導入しました。

  • Dispatch
    xAI Grok Build CLI 0.2.93 分析：未編集のシークレットとリポジトリ全体のアップロード

    Grok Build CLI 0.2.93 のワイヤーレベル分析により、ツールが .env ファイルから未編集のシークレットを送信し、git 履歴を含むリポジトリ全体を Google Cloud Storage バケットにアップロードすることが明らかになりました。これは、モデルがファイルを読み取るかどうか、またはユーザーがモデル改善からオプトアウトしているかどうかに関係なく行われます。

  • Dispatch
    GitHub Copilot 内部アーキテクチャ: コンテキスト注入とセッションストレージの分析

    GitHub Copilot のネットワークトラフィックとソースコードの技術的な深掘りにより、コンテキスト注入、モデルのルーティング、およびユーザーのプロンプトをローカルの SQLite データベースに平文で保存する方法が明らかになりました。

  • プロジェクト
    zhikunqingtao/zhikuncode

    Webブラウザ経由で開発ワークフロー全体を制御でき、高度なコンテキスト管理とランタイム検証機能を備えた、オープンソースのセルフホスト型AIプログラミングアシスタントです。