WSL2上でOpenClaw Gatewayを動かしている環境から、ホストWindowsをNode Agentとして接続し、Windows側のファイルやブラウザを操作できるようにするまでの手順をまとめます。

今回の構成では、WSL2側にすでにOpenClaw Gatewayが存在している前提で、Windows側にはOpenClaw Companionを導入します。

最終的な構成は次のようになります。

Windows
│
├─ OpenClaw Companion
│  └─ Node Mode
│     ├─ system.run
│     ├─ system.which
│     └─ browser.proxy
│
└─ WSL2
   └─ OpenClaw Gateway
      └─ Agent
         ↓
      Windows Node

通常のOpenClaw AgentはWSL2上で動作しますが、Windows上のファイルやブラウザを扱いたい場合だけ、Windows Nodeへ処理を送る構成です。

今回の環境
OpenClaw CLIとCompanionの違い
1. CLI方式
2. Companion方式

今回の環境

この記事では次の構成を前提にしています。

Windows 11
└─ WSL2
   └─ OpenClaw 2026.7.x

OpenClaw GatewayはすでにWSL2側で動作しているものとします。

Windows側には、OpenClaw Companionを新たにインストールします。

OpenClaw CLIとCompanionの違い

Windows側でNodeを動かす方法には、大きく2種類あります。

CLI方式

WindowsにもOpenClaw CLIをインストールして、

openclaw node run

を実行する方法です。

GUIを使わないヘッドレス環境向けです。

Companion方式

Windows用のOpenClaw Companionをインストールし、GUIからNode Modeを有効にする方法です。

今回はこちらを使用します。

OpenClaw Companion
├─ Gateway接続
├─ Node Mode
├─ system.run
├─ Browser Proxy
└─ Windows側の各種権限管理

ファイル操作だけでなくブラウザ操作も行いたい場合は、Companion方式の方が扱いやすいです。

1. OpenClaw CompanionをWindowsへインストール

Windows側にOpenClaw Companionをインストールします。

初回セットアップでは、すでにWSL2上にGatewayが存在するため、新しいGatewayは作りません。

セットアップ画面では、

Connect to an existing gateway

または、

Advanced setup

から既存Gatewayへの接続を選択します。

新しいWSL Gatewayを自動作成する選択肢は使いません。

2. WSL2側のGateway状態を確認する

WSL2で次を実行します。

openclaw gateway status

Gatewayが正常に動作していることを確認します。

次に待受アドレスを確認します。

ss -lntp | grep 18789

最初は次のようになっている場合があります。

127.0.0.1:18789

これはGatewayがloopbackだけで待ち受けている状態です。

3. WindowsからWSL2 Gatewayへ接続できるか確認する

Windows PowerShellで、

Test-NetConnection 127.0.0.1 -Port 18789

を実行します。

次のようになれば成功です。

TcpTestSucceeded : True

最近のWSL2では、Windows側のlocalhostからWSL2内のサービスへ直接アクセスできる場合があります。

この状態なら、CompanionのGateway URLには、

ws://127.0.0.1:18789

を使用できます。

WSL2の内部IPを直接指定する必要はありません。

4. Gatewayのbindを変更する必要がある場合

Windows側からlocalhostで接続できない場合は、Gatewayのbindを変更します。

現在値を確認します。

openclaw config get gateway.bind

LAN待受に変更する場合は、

openclaw config set gateway.bind lan

とします。

続いてGatewayを再起動します。

openclaw gateway restart

確認します。

ss -lntp | grep 18789

次のようになれば、全インターフェースで待ち受けています。

0.0.0.0:18789

ただし、Windows側から、

Test-NetConnection 127.0.0.1 -Port 18789

が通るのであれば、LAN公開は必須ではありません。

セキュリティを優先するなら、最終的にはloopbackへ戻す運用も検討できます。

openclaw config set gateway.bind loopback
openclaw gateway restart

5. Gateway Tokenを生成する

OpenClaw CompanionからGatewayへ接続する際、Gateway認証にtokenを利用できます。

OpenClaw 2026.7系では、次のコマンドでGateway Tokenを生成できます。

openclaw doctor --generate-gateway-token

生成後、Gateway設定にtokenが保存されます。

現在の認証方式は、

openclaw config get gateway.auth

で確認できます。

例えば、

{
  "mode": "token",
  "token": "__OPENCLAW_REDACTED__"
}

のように表示されます。

__OPENCLAW_REDACTED__ は実トークンではなく、CLIが秘匿表示しているものです。

6. 2026.7系ではgateway auth-token –showは使えない

新しいOpenClawではGateway Tokenを表示するためのコマンドが追加されている場合がありますが、2026.7系では、

openclaw gateway auth-token --show

は利用できません。

2026.7系では、

openclaw gateway --help

を見ると、

--token <token>
Shared token required in connect.params.auth.token

という仕様になっています。

Gateway Tokenは、

gateway.auth.token

または、

OPENCLAW_GATEWAY_TOKEN

から利用されます。

7. Tokenの保存場所を確認する

まず環境変数を確認します。

printenv OPENCLAW_GATEWAY_TOKEN

値が表示されれば、それがGateway Tokenです。

表示されない場合は、OpenClawの設定ファイルを確認します。

設定ファイルの場所は、

openclaw config file

で取得できます。

トークンを確認する場合は、設定ファイルを直接扱う必要があります。

ただし、実Tokenはパスワードと同等の秘密情報なので、

ブログ
SNS
スクリーンショット
GitHub
チャット

などへ掲載しないようにします。

8. CompanionからGatewayへ接続する

Windows側でOpenClaw Companionを起動します。

Gateway URLには、

ws://127.0.0.1:18789

を指定します。

Token欄には、先ほど取得したGateway Tokenを入力します。

構成は次のようになります。

Gateway URL
ws://127.0.0.1:18789

Authentication
Gateway Token

接続状態がConnectedになればGatewayとの接続は成功です。

9. CompanionでNode Modeを有効にする

Gatewayへ接続できたら、次はWindowsをNodeとして登録します。

CompanionのSettingsを開き、

Enable Node Mode

をONにします。

今回必要になる主な機能は、

System Run
Browser Proxy

です。

画面確認も行いたい場合は、

Screen Snapshot

も有効にできます。

最初から不要な権限までONにする必要はありません。

例えば、

Camera
Microphone
Location
Screen Recording

などは、必要になってから有効にする方が安全です。

10. WSL2側でNodeのペアリングを確認する

Node Modeを有効にすると、Gateway側へペアリング要求が届きます。

WSL2で、

openclaw devices list

を実行します。

pendingになっているWindows端末が表示された場合は、

openclaw devices approve <requestId>

で承認します。

承認後、

openclaw nodes status

を実行します。

Windows Nodeが、

connected

になっていれば成功です。

11. Windows Nodeが提供する機能

CompanionのNode Modeでは、Windows側からGatewayへ各種commandが提供されます。

代表的なものは、

system.run
system.run.prepare
system.which
browser.proxy

などです。

特にWindows上のファイルを扱うために重要なのが、

system.run

です。

これを利用すると、Windows側でPowerShellやcmd.exeを実行できます。

例えば、

Get-ChildItem "$env:USERPROFILE\Desktop"

を実行すれば、WindowsのDesktopにあるファイル一覧を取得できます。

12. Windowsファイル操作の仕組み

OpenClawからWindowsファイルを操作する場合、専用のファイルAPIを使うというより、

OpenClaw Agent
↓
Gateway
↓
Windows Node
↓
system.run
↓
PowerShell

という経路になります。

つまり、Windows Node上でPowerShellを実行して、

C:\
D:\
Desktop
Documents
Downloads

などを扱います。

例えばファイル一覧なら、

Get-ChildItem "$env:USERPROFILE\Desktop"

ファイル作成なら、

New-Item "$env:USERPROFILE\Desktop\test.txt" -ItemType File

書き込みなら、

Set-Content "$env:USERPROFILE\Desktop\test.txt" "Hello OpenClaw"

といったWindows標準のPowerShellコマンドを利用できます。

13. Gateway側でNode commandを許可する

OpenClaw 2026.7系では、Node側がcommandを提供していても、Gateway側で明示的な許可が必要になる場合があります。

最低限、次のcommandを許可対象にします。

system.run
system.run.prepare
system.which
system.execApprovals.get
system.execApprovals.set

ブラウザも利用する場合は、

browser.proxy

も追加します。

設定例は次のようになります。

{
  "gateway": {
    "nodes": {
      "allowCommands": [
        "system.run",
        "system.run.prepare",
        "system.which",
        "system.execApprovals.get",
        "system.execApprovals.set",
        "browser.proxy"
      ]
    }
  }
}

設定変更後は、

openclaw gateway restart

でGatewayを再起動します。

14. Windows側でPowerShellが利用できるか確認する

Windows Nodeへ接続できたら、system.which でPowerShellを検出できます。

Node名を確認します。

openclaw nodes status

そのNode名を指定して、

openclaw nodes invoke \
  --node "<Windows Node名>" \
  --command system.which \
  --params '{"bins":["pwsh","powershell","cmd"]}'

を実行します。

PowerShellまたはPowerShell 7が検出できれば、Windows上でコマンドを実行する準備はできています。

15. Agentのexec先をWindows Nodeへ変更する

Windows Nodeを通常のexec先として利用する場合は、

openclaw config set tools.exec.host node

を設定します。

さらにNodeを固定する場合は、

openclaw config set tools.exec.node "<Windows Node名>"

とします。

最初は、

openclaw config set tools.exec.mode allowlist

にしておくのがおすすめです。

いきなり全コマンドを自由に実行可能にせず、必要なものだけ許可する構成です。

16. Windowsファイル操作をテストする

ここまで設定できたら、OpenClaw Agentへ例えば、

WindowsノードでPowerShellを使って、
デスクトップにあるファイル一覧を表示して。

と依頼します。

処理の流れは、

Agent
↓
WSL2 Gateway
↓
Windows Companion
↓
system.run
↓
PowerShell
↓
Windowsファイル

となります。

これでWSL2の /mnt/c を経由しなくても、WindowsネイティブのPowerShellとしてファイル操作できます。

17. ブラウザ操作について

Windows Companionには、

browser.proxy

というNode機能があります。

これがGateway側から認識されていれば、Windows上のブラウザ操作をNode経由で行えます。

構成は、

OpenClaw Agent
↓
WSL2 Gateway
↓
Windows Node
↓
browser.proxy
↓
Chrome / Edge

となります。

ただし、OpenClaw 2026.7系Gatewayと最新Companionを組み合わせた場合、ブラウザ関連のcapabilityが完全には認識されない場合があります。

その場合は、

ファイル操作
→ Windows Node

ブラウザ操作
→ Remote CDP

という構成に分ける方法もあります。

18. セキュリティ上の注意

Windows Nodeの system.run は非常に強力です。

実質的に、

OpenClaw
↓
Windows上でPowerShell実行

が可能になります。

そのため、最初は、

allowlist

運用を推奨します。

不要なcapabilityも有効にしない方が安全です。

例えば今回の目的なら、

System Run      ON
Browser Proxy   ON
Screen          必要ならON

Camera          OFF
Microphone      OFF
Location        OFF

程度で十分です。

19. GatewayをLAN公開しなくてもよい場合がある

Windows PowerShellで、

Test-NetConnection 127.0.0.1 -Port 18789

が成功する環境では、WindowsからWSL2 Gatewayへlocalhostで接続できます。

この場合、

ws://127.0.0.1:18789

を利用できるため、GatewayをLAN全体へ公開する必要はありません。

セキュリティ的にはこちらの方が好ましい構成です。

最終的にloopbackへ戻す場合は、

openclaw config set gateway.bind loopback
openclaw gateway restart

としてから、再度Windows側で、

Test-NetConnection 127.0.0.1 -Port 18789

が成功することを確認します。

完成構成

最終的には次のようになります。

Windows 11
│
├─ OpenClaw Companion
│  │
│  ├─ Gateway Connection
│  └─ Node Mode
│     ├─ system.run
│     ├─ system.which
│     └─ browser.proxy
│
│        ▲
│        │ WebSocket
│        │
└────────┼────────────────────
         │
WSL2     │
│        │
└─ OpenClaw Gateway
   │
   └─ Agent
      │
      ├─ exec
      │   ↓
      │ Windows Node
      │   ↓
      │ PowerShell
      │   ↓
      │ Windows Files
      │
      └─ browser
          ↓
        Windows Node
          ↓
        Chrome / Edge

通常のAI処理やGatewayはWSL2側に置いたまま、Windows固有の操作だけをNode Agentへ委譲できます。

公開記事で載せない方がよい情報

OpenClawやサーバ設定の記事を書く場合、次の情報は公開しない方が安全です。

Gateway Token
OpenAI APIキー
OAuth Token
SecretRefの実ID
Windowsのユーザー名
Linuxのユーザー名
実際のホームディレクトリパス
WSL2の実IPアドレス
ホスト名
内部DNS名
VPNやTailnetのアドレス
実行中プロセスのPID
独自変更しているポート番号
個別のNode ID
Device ID
Pairing Request ID

ブログ内では、

<Windows Node名>
<requestId>
<Gateway Token>

のように一般化して掲載するのがおすすめです。

まとめ

今回の導入手順は次の流れです。

WSL2上のOpenClaw Gatewayを確認
WindowsにOpenClaw Companionを導入
Companionから既存Gatewayへ接続
Gateway Tokenで認証
CompanionのNode Modeを有効化
WSL2側でNodeをペアリング
system.run / system.which を許可
Windows PowerShell経由でファイル操作
必要に応じて browser.proxy でブラウザ操作

これにより、

WSL2 OpenClaw
↓
Windows Companion Node
↓
Windowsファイル / ブラウザ

という構成を作れます。

WSL2上にOpenClawのメイン環境を維持しながら、Windowsネイティブの機能だけをNodeとして追加したい場合に便利な構成です。