system.run や system.which 機能を公開するヘッドレスノードホストを実行します。
ノードホストを利用する理由
フル機能の macOS 用コンパニオンアプリをインストールすることなく、エージェントがネットワーク内の他のマシンでコマンドを実行できるようにしたい場合にノードホストを使用します。 主なユースケース:- リモートの Linux/Windows マシン(ビルドサーバー、実験用マシン、NAS など)でコマンドを実行する。
- ゲートウェイ上の実行環境はサンドボックス化しつつ、承認された操作のみを他のホストへ委任する。
- 自動化処理や CI ノード用に、軽量なヘッドレス実行ターゲットを提供する。
ブラウザプロキシ (ゼロ構成)
ノード上でbrowser.enabled が無効にされていない限り、ノードホストは自動的にブラウザプロキシをアドバタイズ(通知)します。これにより、追加の設定なしでエージェントがそのノード上でブラウザ自動化を利用できるようになります。
必要に応じて、ノード側でこの機能を無効にできます:
実行 (フォアグラウンド)
--host <host>: ゲートウェイの WebSocket ホスト (デフォルト:127.0.0.1)--port <port>: ゲートウェイの WebSocket ポート (デフォルト:18789)--tls: ゲートウェイとの接続に TLS を使用する--tls-fingerprint <sha256>: 期待される TLS 証明書のフィンガープリント (sha256)--node-id <id>: ノード ID を上書きする (ペアリングトークンがクリアされます)--display-name <name>: ノードの表示名を上書きする
ノードホストにおけるゲートウェイ認証
openclaw node run および openclaw node install は、構成ファイルや環境変数からゲートウェイの認証情報を解決します(ノード用コマンドには --token や --password フラグはありません):
- 最初に
OPENCLAW_GATEWAY_TOKEN/OPENCLAW_GATEWAY_PASSWORDがチェックされます。 - 次にローカル構成のフォールバックとして
gateway.auth.token/gateway.auth.passwordがチェックされます。 - ローカルモードにおいて
gateway.auth.*が未設定の場合、gateway.remote.token/gateway.remote.passwordもフォールバックの対象となります。 gateway.mode=remoteの場合、リモート優先順位ルールに従ってリモートクライアント用のフィールド (gateway.remote.token/gateway.remote.password) が使用されます。- レガシーな
CLAWDBOT_GATEWAY_*環境変数は、ノードホストの認証解決では無視されます。
サービス (バックグラウンド実行)
ヘッドレスノードホストをユーザーサービスとしてインストールします。--host <host>,--port <port>,--tls,--tls-fingerprint <sha256>,--node-id <id>,--display-name <name>: 上記のrunコマンドと同様。--runtime <runtime>: サービスのランタイムを指定 (nodeまたはbun)。--force: すでにインストールされている場合に再インストール・上書きする。
openclaw node run を使用してください。
サービス管理用のコマンドは、機械可読な出力のために --json フラグをサポートしています。
ペアリング (Pairing)
初回接続時に、ゲートウェイ上で保留中のデバイスペアリング要求 (role: node) が作成されます。以下のコマンドで承認してください:
~/.openclaw/node.json に保存します。
実行承認 (Exec approvals)
system.run によるコマンド実行は、ローカルの実行承認設定によって制御されます:
- 設定ファイル:
~/.openclaw/exec-approvals.json - 概念解説: 実行承認
- ゲートウェイからの編集:
openclaw approvals --node <id|name|ip>