ZCode によるワークスペースの全暗号化アーカイブ：事実と対策

ディスク容量管理中に

~/.zcode

驚愕の事実：データはアップロードされ「開く鍵」はサーバーにある

アップロードと暗号化の仕組み

• 静かなアーカイブ: ユーザーログイン中は、ワークスペース全体（完全な

  .git

  履歴、LFS アセット、設定など）をアーカイブします。
• クラウドへの直接送信: アーカイブを暗号化し、アリババクラウド OSS (Aliyun OSS) に直接アップロードします。

「鍵」の所在が致命的な弱点

• 秘密鍵の不在: 暗号化に用いる RSA 公開鍵はサーバーから動的配信されますが、対応する秘密鍵はローカルには存在しません。
• 復元不能: ローカルディスク上の数百メガバイトのデータは、あなた自身でも ZCode クライアントでも復号化できません。このデータを解凍するのは ZCode のバックエンドサーバーのみです。

調査の詳細：何がどこまで行われているか

1. 滞留した 313MB のアーカイブ

~/.zcode/v2/checkpoints/

.enc

• 内容: コーディング中の商業プロジェクト（約 345MB）を圧縮した結果。
• 状態メタデータ: アップロード失敗が 564 回記録され、再試行待ちの状態でした。
• リスク: このアーカイブには依存パッケージを除いた**核心となる知的財産（コア IP）**が含まれていました。

2. データの内容：90% は

.git

データ

暗号化されたスナップショットに含まれるデータの内訳です。

.git/lfs/

.git/objects/

.git/logs/

src/

• 合計:

  .git

  ディレクトリだけでペイロードの 86.6% を占める。
• 暴露される情報:
  • 運用開始からの全系譜（過去の実験的な API キーや機密設定）
  • プッシュされていないローカルブランチ名（未公開機能計画）
  • 内部 GitLab ホスト名とリポジトリパス

3. アップロードパイプラインの構造

クライアントは

https://zcode.z.ai

sequenceDiagram
    participant C as ZCode クライアント
    participant S as zcode.z.ai サーバー
    participant O as Aliyun OSS

    C->>S: POST /api/v1/snapshot/upload-credential
    S-->>C: snapshot_id + RSA 公開鍵 + max_size + OSS フォーム認証情報
    C->>C: tar.gz 圧縮 → AES-256-CTR 暗号化 → RSA-OAEP でキーをラップ
    C->>O: tar.gz.enc ファイルを直接 HTTP POST フォームで OSS にアップロード
    O->>S: カallback で受信確認を行う

• 永続接続: ZCode プロセスは、ZCode サーバーおよび Aliyun OSS に対して永続的な HTTPS 接続を維持しています。

4. UI トグルは無効化できない

設定画面のオプションは意図通りに動作しません。

optimizeAgentExperienceEnabled

repoSnapshotIndexingEnabled

• 根本原因: アップロードサイドカーは起動時に条件なしでインスタンス化されるため、UI トグルでは停止できません。
• トリガー: プロンプト前 (

  captureBeforePrompt

  ) またはタスク完了時 (

  repo-wiki-update

  ) に発生します（1 セッション最大 62 回）。

5. プライバシーポリシーとの矛盾

• 明記されている: 「対話中に提出されたテキスト、ファイル、コード」の収集。
• 明記されていない: 「ワークスペース全体と完全な Git 履歴を静かにパッケージ化してアップロードする」行為。
• 結論: ポリシー上の一般的な文言と実装内容に乖離が存在します。

対策：ファイル削除だけでは不十分です

単純な削除は「モグラ叩き」になります（アップローダーが即座に再パッケージ化するため）。ファイルシステムレベルで書き込みをブロックする必要があります。

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

影響とロールバック

• 結果: アップロードパイプラインはディスク I/O を試みますが、カーネルレベルでブロックされアーティファクトを生成しなくなります。
• トレードオフ: 「チェックポイントのロールバック/タイムライン」UI 機能は利用できなくなります（本来コードアップロードを前提とした機能）。通常の利用（チャット、補完など）には影響ありません。
• 復旧方法:

  # macOS
  chflags nouchg ~/.zcode/v2/checkpoints
  
  # Linux
  sudo chattr -i ~/.zcode/v2/checkpoints
  

結論：これは「バックアップ」ではなく「収集」です

この挙動は以下の点でユーザーの境界線を超えています。

1. データスコープ: 推論に必要なコンテキストではなく、リポジトリ全体および数年分の Git 履歴を暴露します。
2. アーキテクチャ姿勢:
   • 復号鍵がサーバー側にあるため、ローカルに保持されたデータは開くことができません。
   • プライバシーポリシーで開示がないのに、止む術のないバックグラウンドアップロードが発生します。

ツールとしてではなく、「収集（コレクション）」システムとしての挙動です。UI 設定でオフにできない場合、OS カーネルレベルの制限をかけるのが唯一の効果的な防衛策です。