OpenClaw 2026.9.2からWindows Companionを操作できるか検証した記録

OpenClawをWSL2上で動かし、Windows CompanionをNodeとして接続して、MattermostなどのチャットからWindows側を操作できるか検証しました。

結論から言うと、GatewayとWindows Companionの接続、およびWindows Nodeへのコマンド到達までは確認できたものの、Windows Sandbox / MXC環境内で外部実行ファイルを起動する段階で「アクセスが拒否されました」となり、今回の検証では実用レベルまで到達できませんでした。

OpenClawからWindowsを操作できれば非常に便利ですが、少なくとも今回の環境では、初期構築とトラブルシューティングにかなり時間を要しました。

そのため、いったんWindows Companion連携の検証はペンディングとしました。

この記事では、OpenClaw 2026.9.2で実際に確認した内容と、どこまで正常動作し、どこで問題が発生したのかを整理します。

検証した構成
OpenClawを2026.9.2へアップデート
Windows Companionとの接続自体は成功
GatewayはLAN公開せずloopbackを使用
Execの実行先をWindows Nodeへ設定
Windows Node側のExec Approval
Gateway側Approvalも確認
途中でCodex harnessがallowlistに止められた
Geminiへのフォールバックも確認
ログ確認が非常に重要
最初の成功例：echo
hostname.exeでは「アクセスが拒否されました」
echoは成功、exeは失敗
MXC / AppContainerが有力候補
Hyper-VとWSL2は原因なのか
Nortonなどのセキュリティソフトについて
Node名が内部IDで表示される
Control UIのoriginエラーも発生
DoctorのLegacy State Migration Warning
今回確認できた正常部分
現在の問題箇所
セキュリティ設定は元に戻す
今回ペンディングとした理由
まとめ

検証した構成

今回の構成は概ね次のとおりです。

Mattermost
    ↓
OpenClaw Agent
    ↓
OpenClaw Gateway
    ↓
WSL2
    ↓
Windows Companion
    ↓
Windows Node
    ↓
Windowsコマンド実行

OpenClaw GatewayはWSL2上で動作させ、Windows側にはOpenClaw Companionをインストールしました。

CompanionではNode Modeを有効にし、WSL2側のGatewayへ接続します。

WindowsとWSL2は同一PC上で動作しています。

OpenClawを2026.9.2へアップデート

以前はOpenClaw 2026.7系でWindows Companion連携を検証していました。

しかし、7系ではNodeのExec Approvalや実行経路に関する挙動が分かりにくい部分もあったため、OpenClawを2026.9.2へ更新して改めて検証しました。

バージョン確認は次のコマンドです。

openclaw --version

OpenClaw本体とWindows Companionの世代をできるだけ揃えた状態でテストしています。

Windows Companionとの接続自体は成功

まずWindows CompanionをGatewayへ接続しました。

Nodeの状態は次のコマンドで確認できます。

openclaw nodes status

今回の環境ではWindows Nodeについて、

paired
connected
approved

となり、GatewayからWindows Companionを正常に認識できました。

つまり、

WSL2 Gateway
        ↓
Windows Companion

という通信経路そのものには問題ありませんでした。

GatewayはLAN公開せずloopbackを使用

同一Windows PC上のWSL2とCompanionを接続するだけであれば、GatewayをLANへ公開する必要はありません。

Gatewayはloopbackへ戻しました。

openclaw config set gateway.bind loopback
openclaw gateway restart

Windows側から、

Test-NetConnection 127.0.0.1 -Port 18789

で接続可能であれば、Companionからも、

ws://127.0.0.1:18789

を利用できます。

不要にLANへGatewayを公開しない方が安全です。

Execの実行先をWindows Nodeへ設定

Windows側でコマンドを実行するため、ExecのホストをNodeに設定しました。

概念的には次の設定です。

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

検証中は実行ポリシーの切り分けのため、

openclaw config set tools.exec.mode full

も使用しました。

ただし、これはトラブルシューティング目的です。

通常運用では必要以上に権限を広げず、allowlistなどを利用する方が安全です。

Windows Node側のExec Approval

Windows Companionには、Windows上で何を実行してよいかを制御するExec Approvalがあります。

確認には次のようなコマンドを利用できます。

openclaw approvals get --node "<Windows Node名>"

今回確認できたNode側ポリシーは概ね、

security=allowlist
ask=on-miss
askFallback=deny

という状態でした。

また、テスト用として、

whoami.exe
hostname.exe

がallowlistに登録されていました。

つまり、Windows Node側ではこれらのexeを実行できるように設定されている状態です。

Gateway側Approvalも確認

OpenClaw 2026.9.2では、Execには複数のポリシー層があります。

Gateway側の状態は、

openclaw approvals get --gateway

で確認できます。

今回の切り分け時には、

security=full
ask=off

まで緩和し、Gateway側が原因で実行を止めていない状態を作りました。

また、Mattermostセッション内で、

/exec

を実行すると、そのセッションで実際に有効になっているExec設定を確認できます。

今回確認できた状態は、

host=node
effective=node
security=full
ask=off
node=<Windows Node>

でした。

つまり、

Mattermost
    ↓
OpenClaw
    ↓
Windows Node

という実行先の選択も正常でした。

途中でCodex harnessがallowlistに止められた

検証途中では、次のようなエラーも発生しました。

Codex app-server local execution is unavailable because effective tools.exec.mode=allowlist.

これはWindows Companionのエラーではありません。

OpenClaw側でCodex agent harnessを動かす際、Gateway側のExec Policyがallowlistになっていたため、Codex app-serverのローカル実行自体が停止していました。

Gateway側を確認すると、

openclaw approvals get --gateway

で実効ポリシーを確認できます。

その後、

security=full
ask=off

となったことを確認し、Codex harness側の制限は切り分けられました。

Geminiへのフォールバックも確認

検証中、OpenAIモデルが利用できないタイミングでは、

google/gemini-2.5-flash

へフォールバックしました。

ログには、

model fallback decision

などが表示されていました。

このため、Windows Nodeの問題とモデルの問題を混同しないよう注意が必要でした。

Agent run全体が失敗した場合、

Agent run failed

だけでは、

モデル呼び出し
Tool Call
Exec Approval
Windows Node
Windows Sandbox

のどこで失敗したのか分かりません。

実際の切り分けにはGatewayログが必須でした。

ログ確認が非常に重要

OpenClawのトラブルシューティングでは、

openclaw logs --follow

を開いた状態で実行テストするのが有効でした。

今回もログから、

effective tools.exec.mode=allowlist

のようなGateway側の問題を発見できました。

また、

node.invoke

まで到達している場合は、

Agent
  ↓
Gateway
  ↓
Windows Node

まで処理が進んでいると判断できます。

チャット画面に表示される、

Agent run failed

だけでは情報不足です。

最初の成功例：echo

Windows Nodeで最初に正常実行できたのは、単純なechoでした。

MattermostからWindows Nodeへ、

echo OpenClaw-MXC-Test

を実行すると、Windows Companion側でAllow / Denyの確認ポップアップが表示されました。

Allowすると、

OpenClaw-MXC-Test

が正常に返りました。

これは非常に重要な結果です。

少なくとも、

Mattermost
  ↓
Agent
  ↓
Gateway
  ↓
Windows Companion
  ↓
Approval
  ↓
Windows側実行
  ↓
結果返却

という経路自体は正常に動作していることが確認できました。

つまり、Companionとの接続そのものが壊れているわけではありません。

hostname.exeでは「アクセスが拒否されました」

一方、Windowsの実行ファイルである、

hostname.exe

を実行すると、

アクセスが拒否されました

となりました。

終了コードは、

です。

Windows Node側のallowlistにはhostname.exeが登録済みです。

Gateway側も、

security=full
ask=off

まで緩和しています。

そのため、この時点で、

Exec Approvalで拒否された

可能性はかなり低くなりました。

echoは成功、exeは失敗

今回の調査で最も重要だったのが、

echo
→ 成功

に対して、

hostname.exe
→ Access is denied

となったことです。

echoはcmd.exeの組み込みコマンドです。

一方、hostname.exeは別のWindows実行ファイルを子プロセスとして生成する必要があります。

この違いから、

Windows Companion
        ↓
Sandbox / MXC
        ↓
子プロセス生成

の部分が問題になっている可能性が高くなりました。

MXC / AppContainerが有力候補

Windows Companionでは、Windowsコマンドをそのままホスト上で無制限に実行するのではなく、Sandbox / MXC / AppContainerといった仕組みを利用します。

今回の症状は、

Sandbox自体は起動する
↓
cmd builtinは実行できる
↓
外部exeをCreateProcessしようとする
↓
Access is denied

というパターンに見えます。

そのため、

Gateway

や、

Nodeの接続

よりも、

Windows Companion側のSandbox

が現在最も疑わしい箇所です。

Hyper-VとWSL2は原因なのか

今回のOpenClaw GatewayはWSL2上で動いています。

WSL2自体もWindowsの仮想化基盤を利用するため、

「Hyper-VやWSL2が原因なのではないか」

という疑問も出ました。

現時点では、

WSL2を使っていること自体が直接原因とは考えにくい

という判断です。

理由は、echoの実行が成功しているためです。

もし、

WSL2
→ Windows Companion

の通信や仮想化構成そのものに致命的な問題があれば、echoまで成功する可能性は低くなります。

今回の経路は、

WSL2上のGateway
      ↓
Windows Companion
      ↓
Windows Sandbox / MXC

です。

Windowsコマンドを実際に生成する部分はWindows側にあります。

そのため問題の中心は、

WSL2

というより、

Windowsホスト上のMXC / AppContainer

である可能性が高いと考えています。

ただし、

Hyper-V
WSL2
VBS
Windows Defender
Windows Sandbox
AppContainer
サードパーティ製セキュリティソフト

などは同じWindowsホスト上で相互作用するため、間接的な影響まで完全には否定できません。

Nortonなどのセキュリティソフトについて

検証途中では、サードパーティ製セキュリティソフトの影響も疑いました。

トラブルシューティング目的で一時的に保護を停止して試すことはできますが、常用時に無効化するのは推奨できません。

今回については、

echoは成功
hostname.exeはAccess denied

という結果から、単純なネットワーク遮断やCompanion全体のブロックではなさそうです。

セキュリティソフトを永久に無効にするような解決策は採用しない方針としました。

Node名が内部IDで表示される

MattermostからWindows Nodeを指定して実行すると、結果には人間が設定したNode名ではなく内部IDが表示される場合がありました。

これは今回の失敗原因ではありません。

OpenClaw内部ではNodeを一意に識別するため、内部IDを利用しています。

表示上多少分かりにくいものの、内部IDで実行先が表示されても、それ自体は異常とは判断していません。

Control UIのoriginエラーも発生

検証中には、次のようなログもありました。

origin not allowed

これはWindowsブラウザからGatewayのControl UIへアクセスした際のOrigin制限によるものです。

Windows Nodeのhostname.exe実行失敗とは別問題です。

OpenClawではGatewayのControl UIに対して許可Originを設定できるため、必要な場合のみ、

gateway.controlUi.allowedOrigins

を適切に設定します。

セキュリティ上、むやみにワイルドカードで許可するより、必要なOriginだけ設定する方がよいでしょう。

DoctorのLegacy State Migration Warning

2026.9.2へアップデートした後、

Legacy state migration warnings

も表示されました。

旧Agentディレクトリがバックアップとして残されている旨の警告です。

これは今回のWindows Companion実行問題とは直接関係ありません。

アップデートによって旧状態を移行した際、以前のディレクトリを削除せず残しているために表示されます。

今回確認できた正常部分

ここまでの検証で、次の部分は正常であることを確認できました。

OpenClaw 2026.9.2起動
        ↓
Gateway起動
        ↓
Windows Companion接続
        ↓
Node pairing
        ↓
Node connected
        ↓
Node approved
        ↓
MattermostからAgent起動
        ↓
exec host=node
        ↓
Windows CompanionにApprovalポップアップ
        ↓
Allow
        ↓
echo実行
        ↓
Mattermostへ結果返却

したがって、Windows Companion連携全体が失敗しているわけではありません。

かなり深い部分まで正常に動作しています。

現在の問題箇所

現時点で問題が集中しているのは、

Windows Companion
        ↓
MXC / AppContainer
        ↓
外部Windows executable

の部分です。

特に、

echo

は成功する一方で、

hostname.exe

が、

Access is denied
exit code 1

となることから、Sandbox内での子プロセス生成が疑われます。

今後続ける場合は、

whoami.exe
PowerShell
cmd.exe
hostname.exe

などを比較し、

cmd builtinだけ成功するのか
すべての外部exeが失敗するのか
Windows UI APIを利用するexeだけ失敗するのか
MXCを利用しないhost fallbackなら動くのか

を調べる必要があります。

セキュリティ設定は元に戻す

トラブルシューティング中には、

security=full
ask=off

など、通常運用では推奨しにくい設定も利用しました。

検証が終了したら、Gateway側を必要以上に広い権限のまま放置しないことが重要です。

Windows Node側については、

security=allowlist
ask=on-miss
askFallback=deny

のような設定を維持する方が安全です。

また、

gateway.bind

も、同一PC上のCompanionからだけ利用するのであればloopbackで十分です。

今回ペンディングとした理由

OpenClawからWindowsを操作できるようになれば、

Windowsファイル操作
PowerShell実行
ブラウザ操作
GUI操作
Windowsアプリとの連携

など、非常に面白いことができる可能性があります。

一方、今回実際に検証して感じたのは、

実際にWindowsを操作できる状態へ到達するまでに確認すべきレイヤーがかなり多い

ということです。

今回だけでも、

モデル
Gateway
Agent Harness
Exec Policy
Session Exec Policy
Gateway Approval
Windows Node Approval
Companion
MXC Sandbox
AppContainer
Windows Security

といった複数レイヤーを切り分ける必要がありました。

単純に、

Companionを入れる
↓
Nodeを接続する
↓
Windowsを操作できる

というところまでは、少なくとも今回の環境では到達できませんでした。

Windows操作を日常的に利用する目的で考えると、このトラブルシューティングコストは現時点では少し大きいと感じます。

そのため今回、

OpenClawからWindows Companionを使ったWindows操作については、一度ペンディング

としました。

まとめ

今回のOpenClaw 2026.9.2とWindows Companionの検証結果をまとめると、次のようになります。

Gateway ↔ Companion接続
→ 成功

Node pairing / approval
→ 成功

Mattermost → Windows Node
→ 成功

Companion Approval popup
→ 成功

cmd builtin（echo）
→ 成功

hostname.exe
→ Access is denied

原因候補
→ Windows CompanionのMXC / AppContainer

特に、