8月19日、Pragmatic Engineerが「The Pulse: Grok's CLI caught uploading all your local files to the cloud」と題した記事を公開した。この記事では、xAIが提供するコーディングCLIツール「Grok Build」がユーザーのローカルファイルを無断でクラウドにアップロードしていた問題と、その後の経緯を詳しく取り上げている。本記事はThe Pulse形式（週次まとめ）として公開されており、7月中旬に発生した一連の出来事を時系列で整理した内容となっている。
.envファイルからgit履歴まで、すべて送信されていた
独立したAI安全研究者「Cerblab」が今回の問題を詳細にドキュメント化した。その内容は衝撃的だ。
Grok Build CLIは通常のユーザーログイン状態で、以下の3つを行っていた。
- 読み込んだファイルの内容（
.envの秘密鍵を含む）を、暗号化なしで平文のままxAIのサーバーに送信する - エージェントが実際に読んでいないファイルも含め、リポジトリ全体をgit履歴ごとクラウドにアップロードする
- アップロード先は
grok-code-session-tracesというGoogle Cloud Storageバケット
Cerblabは「reply OK, do not read any files」というプロンプトを与えた状態でも、Grokがリポジトリ全体をgitバンドルとしてPOST /v1/storageに送信したことを実証している。12GBのリポジトリに対して5.10GiBがアップロードされた一方、モデルへの送信は192KBに過ぎなかった——その比率は約27,800倍だ。
.envファイルにはデータベースのアクセストークンや外部サービスの認証情報が含まれる。それが暗号化なしでGCPのストレージバケットに保存されるとなれば、セキュリティ上の問題は明白だ。さらに「Improve the model」設定を無効にしても、trace_upload_enabled: trueのままであることも確認されている。
なぜこれが問題なのか。Cursorがコードベースのインデックスをローカルで処理してembeddingのみをサーバーに送信しているのとは対照的に、Grok CLIはソースコードそのものをクラウドに転送している。記事ではCursorのアーキテクチャを比較対象として挙げているが、CursorとxAI/Grokの関係についての記述は元記事の文脈に沿って読んでいただきたい。
xAI/Grokチームの対応と開発者コミュニティの反発
発覚後、xAI/Grokチームはリモートのフィーチャーフラグを切ることでアップロードを停止させた。AWSエンジニアのWes EklundがCLIのネットワーク挙動を追跡するツールを公開し、アップロードが突然止まったことを確認している。ただし、ローカルファイルをストリーミングする機能自体はその後のアップデートでもCLIのコードに残り続けた。
xAI側の公式声明は「ゼロデータリテンション（ZDR）を有効にしたエンタープライズ顧客は影響を受けていない」という内容だった。裏を返せば、一般ユーザーは保護されていなかったということだ。
Elon Muskもポストした。
「デバッグの役に立つため、ある程度のデータを保持できるようにすることは有用だ。プライバシー設定は常に尊重される。」
これに対しWes Eklundは反論した。
「Elon、あなたが取り組んでいるすべてのことを応援している。トレースデータの必要性は理解できる。ただ、私の調査では、単なるデバッグデータをはるかに超えている。機密情報を含むコードリポジトリ全体が収集されている。あなたのGoogle Cloudストレージにはペタバイト級のコードリポジトリが積み上がっているはずだ。」
Sam AltmanのひとことでGrok CLIがオープンソース化
OpenAIのSam AltmanはMuskが好んで使う「concerning（懸念される）」という言葉を逆手に取り、オープンソースのCodexハーネスと比較する形でポストした。オープンソースであれば、隠れたファイルアップロード機能はソースコードで確認できる、という示唆だ。
MuskはAltmanのポストを読んだ数時間後、Grok CLIをオープンソース化すると表明。翌7月15日、実際にGitHubでGrok CLIのソースが公開された。なお、元記事はThe Pulse形式で7月中旬の出来事をまとめており、8月19日の公開時点で振り返りとして記述されている。
ただし、公開されたリポジトリは急造だった。カーネルエンジニアのElliot Arledgeが検証した結果を報告している。
「
cargo test --workspaceがそのままではコンパイルできない。190以上のエラーがあり、すべて同一のバグクラスだ。テストスイートを動かすと24,663件がパス、28件が失敗——いずれもビルドが壊れていたせいで隠れていた既存のバグだ。このリポジトリ、公開前に誰かダウンロードして動かしてみたのか？」
xAIはあわせて、7月12日以降すべてのユーザーに対してデフォルトのデータ保持を無効化し、過去に収集したコーディングデータをすべて削除すると発表した。
記事の総括
記事の著者Gergelyは今回の件をこう総括している。「信頼は一滴ずつ積み上げられ、バケツ単位で失われる」——。暗号化なしで.envを送信し、git履歴まで抜き取っていたGrok CLIは、コーディングエージェントとして大きな信頼の毀損を招いた。Claude Code、Codex、Gemini CLIといった主要な競合は、こうした形でユーザーの信頼を裏切っていない、と記事は指摘している。
エンタープライズ向け契約を取り戻すには、オープンソース化後も長期にわたってセキュリティインシデントを起こさないことが求められる。今回の騒動は、セキュリティレビューのプロセスを省いて出荷速度を優先することのコストを、改めて示した事例として記事では位置づけられている。
詳細はThe Pulse: Grok's CLI caught uploading all your local files to the cloudを参照していただきたい。
