独占: xAIは未発表のGrokリモートワークスペース製品向けの基盤を出荷した

RUNTIMEWIRE INVESTIGATION — Exclusive

Original reporting by RuntimeWire.

Why it matters

Coding agents operate beside proprietary source code and credentials. An undocumented remote-workspace path leaves developers unable to assess the full trust boundary before installing Grok Build.

xAIのGrok Build 1.0は、未発表のリモートワークスペース製品とOpenAI Remoteの潜在的な競合相手の基盤を出荷しました。コーディングエージェント内部に隠されたComputer Hubコマンドは、開発者のローカルワークスペースをリモートからアクセス可能なツールサーバーに変えることができ、xAIが制御するアカウントフラグがその機能を誰が使えるかを決定します。

そのコマンドはヘルプ、ドキュメント、リリースノートには存在せず、RuntimeWireのテストではxAIのアカウント設定がその機能を無効として返しました。組み込みの環境オーバーライドによりRuntimeWireはエージェントのローカル制御チャネルへの経路を実行できましたが、RuntimeWireはリモートセッションを完了せず、通常の使用でワークスペースが黙って公開される証拠は見つかりませんでした。

バイナリにはxAIの本番用Computer HubのWebSocketアドレスが含まれていました。xAIが公開したソースにも同じアドレスが含まれ、それをpublic Computer Hub URLとラベル付けし、ワークスペースサーバーのデフォルトエンドポイントとして設定しています。RuntimeWireはそのサービスに接続したり、エンドポイントをプローブしたりはしていません。

ローカルコーディングエージェント内の隠れたコントロールプレーン

Grok Buildはファイルの読み書き、シェルコマンドの実行、開発ツールの操作、ローカルコードベースに対するセッション維持ができるターミナル型コーディングエージェントです。だからこそ、リモートワークスペースアクセスは重大な製品機能になります：ローカルプロセスはソースコード、資格情報、設定ファイル、そしてエージェントが使用するコマンド実行の表面に隣接して動作します。

この発見は、Grok Buildが通常の使用中にワークスペースを黙って公開していることを立証するものではなく、この機能をバックドアと表現するのは行き過ぎです。起動には明示的なコマンドとRuntimeWireのテストで用いたローカル環境オーバーライドが必要であり、xAIのアカウント設定はその機能を無効として返しました。バイナリは通常のヘルプ出力にそのコマンドを表示せず、xAIの公開製品ドキュメントでも説明していませんでした。

その開示の空白は重要です。なぜなら、xAIはGrok Build 1.0.0を8月7日にリリースしました——それはRuntimeWireのテストと同じ日です。1.0の変更履歴にはインターフェースの変更、信頼性の修正、セッション復元の挙動、権限プロンプトの改善が記載されています。Computer Hub、リモートワークスペースアクセス、あるいは実行ファイル内で見つかったコマンドについては言及がありません。

xAIの公開の立場はユーザーのコンピュータにもたらされるコーディングエージェントを強調しています。製品ページではローカルでのコード編集、ターミナル実行、Git統合、プラグイン、フック、Model Context Protocolサーバー、サンドボックス実行を説明しています。隠されたComputer Hubの経路はその文書化されたローカルエージェントモデルを超えた場所を指しています：一度明示的に起動されれば、ワークスペースプロセスはリモートハブへのアウトバウンド接続を確立し、認証された別の参加者にツールとファイルシステム操作を提供できます。

オープンソース公開がアーキテクチャを裏付ける

この機能はxAI自身が公開したコードで見えるインフラと一致します。7月15日、xAIはGrok Buildをオープンソース化しました と述べ、リポジトリをコンテキスト組み立て、ツールディスパッチ、拡張の決定的な参照と説明しました。GitHubリポジトリにはComputer Hubルーティング、ソフトウェア開発キット、ツールプロトコル処理、ワークスペースクライアント、ローカルワークスペースホストのパッケージが含まれます。

公開ソースはアーキテクチャを明示しています。コマンドを#[command(hide = true)]でマークし、完全な環境変数ゲートとリモートのworkspace_command_enabledフラグを含み、WorkspaceStartを呼び出し、public Computer Hubアドレスをワークスペースサーバーのデフォルトエンドポイントとして設定しています。RuntimeWireの発見は単にオープンソースにコマンドが存在したというだけではありません：xAIはその経路を公式のGrok Build 1.0 Windows実行ファイルで出荷しており、そのコマンドは実行時に動作します。

Grok Buildはすでに複数のクライアントがセッションを表示・制御できることを可能にする文書化されたleader modeをサポートしています。xAIの変更履歴は6月以降、leaderプロセス、接続されたクライアント、ライブダッシュボードに言及してきました。Computer Hubは同じ基本モデルをネットワーク境界を超えて拡張し、xAIがドキュメントやリリースノートで発表していないリモートワークスペース製品の基盤を供給します。

アカウントフラグは別の実行ファイルを必要とせずにxAIがサーバー側でロールアウトを制御する手段を与えます。xAIはその制御を使って機能を段階的に展開したり、社内でテストしたり、選ばれたアカウント向けに有効化したりできます。環境オーバーライドはサーバー側のフラグがオフのときでもローカルバイナリがアカウント適格性チェックを通過し、leader制御経路に到達できるようにします。RuntimeWireのテストでは、オーバーライドが認証を回避したり、それ自体でComputer Hub接続を引き起こしたりすることは示されませんでした。

Grok Buildの現在のセーフガードにより、RuntimeWireは通常のアカウントでリモート接続を完了できませんでした。ニュースは、xAIが未発表のOpenAI Remote競合製品に対するクライアント側の基盤をすでに出荷しており、誰がそれを使えるかについてはサーバー側で制御を保持しているということです。コーディングエージェントをインストールした開発者は、Grok Buildの文書化された機能セットだけからそのリモートワークスペース機能を評価することはできません。