それは何ですか (概念)
次の 3 つの部分があります。- ブラウザ制御サービス (ゲートウェイまたはノード): エージェント/ツールが(ゲートウェイ経由で)呼び出すAPI
- ローカル リレー サーバー (ループバック CDP): コントロール サーバーと拡張機能の間のブリッジ (デフォルトでは
http://127.0.0.1:18792) - Chrome MV3 拡張機能:
chrome.debuggerを使用してアクティブなタブに接続し、CDP メッセージをリレーにパイプします。
browser ツール表面 (適切なプロファイルの選択) を通じて、接続されたタブを制御します。
インストール/ロード (解凍された状態)
- 拡張機能を安定したローカル パスにインストールします。
- インストールされている拡張機能のディレクトリ パスを出力します。
- クロム →
chrome://extensions
- 「開発者モード」を有効にする
- 「解凍してロード」 → 上で印刷されたディレクトリを選択します
- エクステンションを固定します。
更新 (ビルドステップなし)
この拡張機能は、OpenClaw リリース (npm パッケージ) 内に静的ファイルとして同梱されています。個別の「ビルド」ステップはありません。 OpenClaw をアップグレードした後:-openclaw browser extension install を再実行して、OpenClaw 状態ディレクトリにインストールされているファイルを更新します。
- Chrome →
chrome://extensions→ 拡張機能の「再読み込み」をクリックします。
それを使用します (ゲートウェイ トークンを一度設定します)
OpenClaw には、デフォルト ポート上の拡張リレーをターゲットとするchrome という名前の組み込みブラウザ プロファイルが付属しています。
最初にアタッチする前に、拡張機能のオプションを開いて次のように設定します。
Port(デフォルト18792)Gateway token(gateway.auth.token/OPENCLAW_GATEWAY_TOKENと一致する必要があります)
- CLI:
openclaw browser --browser-profile chrome tabs - エージェント ツール:
browserとprofile="chrome"
カスタムゲートウェイポート
カスタム ゲートウェイ ポートを使用している場合、拡張リレー ポートは自動的に導出されます。 拡張リレー ポート = ゲートウェイ ポート + 3 例:gateway.port: 19001 の場合、次のようになります。
- 拡張中継ポート:
19004(ゲートウェイ + 3)
アタッチ/デタッチ (ツールバー ボタン)
- OpenClaw で制御したいタブを開きます。
- 拡張機能アイコンをクリックします。
- バッジを取り付けると、
ONと表示されます。
- バッジを取り付けると、
- もう一度クリックすると切り離されます。
どのタブで制御されますか?- 「表示されているタブ」を自動的に制御するわけではありません**
- ツールバー ボタンをクリックして 明示的にアタッチしたタブのみを制御します。
- 切り替えるには、別のタブを開き、そこにある拡張機能アイコンをクリックします。
バッジ + 一般的なエラー
ON: 添付。 OpenClaw はそのタブを駆動できます。…: ローカルリレーに接続しています。!: リレーに到達できない/認証されていません (最も一般的なのは、リレー サーバーが実行されていない、またはゲートウェイ トークンが見つからない/間違っている)。
! が表示された場合:
- ゲートウェイがローカルで実行されていることを確認します (デフォルト設定)。ゲートウェイが別の場所で実行されている場合は、このマシン上でノード ホストを実行します。
- 拡張機能のオプション ページを開きます。リレーの到達可能性とゲートウェイ トークン認証を検証します。
リモート ゲートウェイ (ノード ホストを使用)
ローカル ゲートウェイ (Chrome と同じマシン) - 通常 追加の手順はありません
ゲートウェイが Chrome と同じマシン上で実行されている場合、ゲートウェイはループバックでブラウザ制御サービスを開始します。 そしてリレーサーバーを自動起動します。拡張機能はローカルリレーと通信します。 CLI/ツール呼び出しはゲートウェイに送られます。リモート ゲートウェイ (ゲートウェイは別の場所で実行) — ノード ホストを実行
ゲートウェイが別のマシンで実行されている場合は、Chrome を実行しているマシンでノード ホストを起動します。 ゲートウェイは、ブラウザーのアクションをそのノードにプロキシします。拡張機能とリレーはブラウザ マシンに対してローカルに留まります。複数のノードが接続されている場合は、gateway.nodes.browser.node で 1 つを固定するか、gateway.nodes.browser.mode を設定します。
サンドボックス (ツールコンテナ)
エージェント セッションがサンドボックス化されている場合 (agents.defaults.sandbox.mode != "off")、browser ツールは制限される可能性があります。
- デフォルトでは、サンドボックス セッションはホスト Chrome ではなく サンドボックス ブラウザ (
target="sandbox") をターゲットとすることがよくあります。 - Chrome 拡張機能リレーの引き継ぎには、ホスト ブラウザ制御サーバーを制御する必要があります。
- 最も簡単: 非サンドボックス セッション/エージェントの拡張機能を使用します。
- または、サンドボックス セッションのホスト ブラウザー制御を許可します。
target="host" を使用して browser を呼び出します。
デバッグ: openclaw sandbox explain
リモート アクセスのヒント
- ゲートウェイとノード ホストを同じテールネット上に維持します。中継ポートを LAN または公衆インターネットに公開しないようにします。
- ノードを意図的にペアリングします。リモート制御が必要ない場合は、ブラウザのプロキシ ルーティングを無効にしてください (
gateway.nodes.browser.mode="off")。 - 実際にクロスネームスペースが必要でない限り、リレーをループバックのままにしておきます。 WSL2 または同様の分割ホスト設定の場合は、
browser.relayBindHostを0.0.0.0などの明示的なバインド アドレスに設定し、ゲートウェイ認証、ノード ペアリング、およびプライベート ネットワークを使用してアクセスの制限を維持します。
「拡張パス」の仕組み
openclaw browser extension path は、拡張ファイルを含む インストールされている ディスク上のディレクトリを出力します。CLI は意図的に node_modules パスを出力しません**。常に最初に openclaw browser extension install を実行して、拡張機能を OpenClaw 状態ディレクトリの下の安定した場所にコピーします。
そのインストール ディレクトリを移動または削除すると、有効なパスから再ロードするまで、Chrome は拡張機能を壊れているとマークします。
セキュリティへの影響 (これをお読みください)
これは強力かつ危険です。モデルに「ブラウザ上で実際に操作してもらう」のと同じように扱ってください。- 拡張機能は Chrome のデバッガー API (
chrome.debugger) を使用します。接続すると、モデルは次のことが可能になります。- そのタブをクリック/入力/移動します
- ページのコンテンツを読む
- タブのログインセッションがアクセスできるものすべてにアクセスします
- これは、専用の openclaw 管理プロファイルのように分離されていません。
- 毎日のドライバーのプロフィール/タブに添付すると、そのアカウントの状態へのアクセスが許可されます。
- 拡張機能リレーの使用には、専用の Chrome プロファイル (個人的なブラウジングとは別) を推奨します。
- ゲートウェイとすべてのノード ホストをテールネットのみにします。ゲートウェイ認証 + ノードのペアリングに依存します。
- LAN (
0.0.0.0) 経由でリレー ポートを公開しないようにし、ファネル (パブリック) を回避します。 - リレーは非拡張オリジンをブロックし、
/cdpと/extensionの両方に対してゲートウェイ トークン認証を必要とします。