Just another IT site ※IT系の記事は当方環境での実施内容となるため実施する場合は自己責任でお願いいたします。At Your Own Risk!! TURN BACK WHILE YOU CAN
PR

【OpenClaw】Windows Companion接続済みなのにsystem.runがタイムアウトする場合の切り分け手順

※IT系の記事は当方環境での実施内容となるため実施する場合は自己責任でお願いいたします。スクリプトはAI生成のものも多いのでコピー＆ペーストの際は文字コードに注意ください！

多分、もうWindows Companionの次のバージョンを待てって話なんだと。。。今の最新OpenClawとは無理っぽい。

OpenClaw Windows CompanionをWindows PCへインストールし、リモートのOpenClaw Gatewayとの接続までは成功したものの、

Windows Nodeで hostname.exe を実行
↓
タイムアウト

となり、Windows側のコマンド実行ができないトラブルに遭遇しました。

今回の環境では、

Node接続        正常
Pairing         正常
Approval        正常
device.info     正常
device.status   正常
system.which    応答あり
system.run      タイムアウト

というところまで切り分けることができました。

この記事では、OpenClaw Windows Companionで

接続はできているのにWindowsコマンドだけ実行できない

場合に、どこを確認すればよいかを実際の検証結果をもとにまとめます。

今回の症状

OpenClaw Windows CompanionはリモートGatewayと接続済みでした。

Nodeの状態を確認すると、

paired
connected
approved

となっており、

system.run
system.run.prepare
system.which
device.info
device.status

などのcapabilityも公開されていました。

それにもかかわらず、OpenClawから、

Windows Nodeで hostname.exe を実行して

と指示すると、

45秒
75秒

などでタイムアウトしました。

エラーの内容は概ね、

Windows Nodeから応答がなくタイムアウト
Nodeの接続または実行許可が応答待ち

というものでした。

STEP1：まずNode接続を確認する

最初にWindows Nodeが本当に接続されているか確認します。

openclaw nodes list

または、

openclaw nodes describe --node "Windows Node (...)"

を実行します。

確認したい項目は、

Status
Approval
Caps
Commands

です。

正常であれば、概ね、

Status   paired · connected
Approval approved
Caps     ... system

となります。

さらにCommandsに、

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

などが表示されていれば、Windows Companion側がSystem系capabilityを公開しています。

STEP2：device pairingのpendingを確認する

Node接続トラブルでは、まずdevice pairingの未承認を疑います。

openclaw devices list

ここにpendingがあれば、承認が必要です。

ただし今回のケースでは、

pending device pairing なし

でした。

つまり、

device pairing未承認

は原因ではありませんでした。

STEP3：Exec Approvalを確認する

Windows Node側の実行許可を確認します。

openclaw approvals get --node "Windows Node (...)"

今回の初期状態では、

security=allowlist
ask=on-miss
askFallback=deny
autoAllowSkills=off
Allowlist=0

でした。

つまり、

許可リストにないコマンド
↓
Windows側で承認を求める
↓
承認できなければdeny

という設定です。

このため最初は、

承認待ちでタイムアウトしているのでは？

と考えました。

STEP4：System toolsを確認する

Windows Companion側には、

Run system tools

に相当するスイッチがあります。

これはWindows Nodeで system.run を使用するための重要な設定です。

今回この設定を確認したところ、

System tools = ON

でした。

したがって、

System toolsがOFF

という単純な原因でもありませんでした。

STEP5：Node SandboxをOFFにして試す

次にWindows Companion側のNode Sandboxが原因かを確認しました。

SandboxがWindowsコマンド実行を制限している可能性があるため、

Node Sandbox = OFF

にして、再度 hostname.exe を試しました。

しかし結果は、

タイムアウト

のままでした。

そのため今回のケースでは、

Node Sandbox固有の制限

が主原因とは考えにくくなりました。

STEP6：system.execApprovals.getを直接呼ぼうとして失敗

途中で、

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command system.execApprovals.get

を試しました。

しかし、

node.invoke does not allow system.execApprovals.*
use exec.approvals.node.*

というエラーになりました。

つまり、Exec Approvalの確認は node.invoke から直接行うのではなく、

openclaw approvals get --node "Windows Node (...)"

を使う必要があります。

STEP7：node.invokeを直接試す

system.run の経路を直接確認するため、

node.invoke

も試しました。

最初は、

idempotencyKey が必要

というエラーになりました。

つまり、現行Gatewayでは node.invoke を直接呼ぶ場合、

idempotencyKey

が必須です。

その後修正して実行すると、

PAIRING_CHANGED
node pairing changed while invocation was active

というエラーも発生しました。

ただし、その後Nodeを確認すると、

paired
connected
approved

となっていました。

このため、恒常的なpairing未承認ではなく、呼び出し中にNodeの接続状態またはpairing generationが変化した可能性が考えられました。

STEP8：device.infoを確認

ここで、system.run 以外のNode commandが正常か確認しました。

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command device.info

これは正常に返りました。

取得できた情報には、

Windows
OSバージョン
CompanionのappVersion
locale

などが含まれていました。

つまり、

Gateway
↓
Windows Node
↓
Companion
↓
device.info

までの通信は正常です。

STEP9：device.statusも正常

続いて、

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command device.status

を実行しました。

こちらも正常に返りました。

CPU、メモリ、ディスク、バッテリー、ネットワークなどの状態が取得できました。

つまり、

Node接続そのもの

はかなり正常だと判断できます。

STEP10：system.whichを確認

次に、

Windows Companionが実行ファイルを見つけられるか

を確認するため、

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command system.which \
  --params '{"bins":["hostname.exe","whoami.exe","powershell.exe","cmd.exe"]}'

を実行しました。

最初は、

Missing bins parameter

となりました。

system.which は、

name

ではなく、

bins

を指定する必要があります。

修正後は、

ok: true

で返りました。

しかし結果は、

bins: {}

でした。

つまり、

system.which自体はNodeまで到達して正常応答

しているのに、

cmd.exe
powershell.exe
hostname.exe
whoami.exe

の場所が1件も返ってきませんでした。

この結果が重要だった

ここまでの状態を整理すると、

device.info
→ OK

device.status
→ OK

system.which
→ OK
  ただし bins={}

system.run
→ タイムアウト

です。

これは、

Node全体が壊れている

というより、

System系の実行ファイル探索またはプロセス起動経路

に問題がある可能性を示しています。

特に、Windowsなら通常、

cmd.exe
hostname.exe

などは存在するため、

bins={}

は気になる結果です。

STEP11：Windows Companionのバージョンも確認

device.info からWindows Companionのバージョンも確認できました。

今回の環境では、

Windows Companion
core v2026.7.1-4

でした。

一方、Gateway側のOpenClawは、

2026.9.x

系でした。

このため、

Gateway側
比較的新しい

Windows Companion側
2026.7.1-4

という組み合わせになっていました。

OpenClaw Windows Nodeでは、2026.7.1系で system.run 周辺の不具合報告もあるため、最終的にはCompanion側の実装問題も疑う状況になりました。

ここまでで除外できたもの

今回の検証では、少なくとも次の項目は大きな原因ではなさそうでした。

GatewayにNodeが見えていない
→ 違う

Nodeが未pairing
→ 違う

Nodeが未承認
→ 違う

System capabilityが公開されていない
→ 違う

System toolsがOFF
→ 違う

Node Sandboxが原因
→ OFFでも再現

Windows Nodeそのものが応答していない
→ device.info / device.statusは正常

現時点で最も疑っている箇所

ここまでの結果から、問題はかなり限定されました。

OpenClaw Gateway
        ↓
        OK

Node接続
        ↓
        OK

Pairing
        ↓
        OK

Approval
        ↓
        OK

device.info / status
        ↓
        OK

system.which
        ↓
        応答するがbinsが空

system.run
        ↓
        タイムアウト

したがって、現時点では、

Windows Companion側の system.run 実行経路、あるいは実行ファイル探索・プロセス起動処理に問題がある可能性が高い

と考えています。

今後試す予定の対応

ここから先は、Gateway側の設定をさらに変更するより、

Windows Companionを完全終了して再起動

Windows Companionを再インストール

より新しいWindows Companionビルドを確認

再ペアリング

system.which再確認

system.run再確認

という方向で確認する方がよさそうです。

特に、

device.info
device.status

が正常なので、ネットワークやGateway接続を何度も作り直すより、

Windows Companion自身のSystem実行部分を重点的に確認する

方が効率的だと思います。

検証用コマンド早見表

Node状態：

openclaw nodes list

詳細：

openclaw nodes describe --node "Windows Node (...)"

Device pairing：

openclaw devices list

Exec Approval：

openclaw approvals get --node "Windows Node (...)"

デバイス情報：

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command device.info

デバイス状態：

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command device.status

Windowsコマンド探索：

openclaw nodes invoke \
  --node "Windows Node (...)" \
  --command system.which \
  --params '{"bins":["hostname.exe","whoami.exe","powershell.exe","cmd.exe"]}'

トラブルシュートの流れ

今回の経験から、Windows Companionで system.run がタイムアウトする場合は、次の順番で確認すると分かりやすいです。

Nodeはconnectedか
        ↓
Approvalはapprovedか
        ↓
system.run capabilityはあるか
        ↓
System toolsはONか
        ↓
Exec Approvalはどうなっているか
        ↓
Sandbox OFFでも再現するか
        ↓
device.infoは返るか
        ↓
device.statusは返るか
        ↓
system.whichは返るか
        ↓
system.runだけ失敗するか

ここまで確認できれば、

接続の問題

なのか、

実行許可の問題

なのか、

Windows Companion内部のsystem.run問題

なのかをかなり絞り込めます。

まとめ

今回、OpenClaw Windows Companionは、

paired
connected
approved

まで正常でした。

さらに、

device.info
device.status

も正常に取得できました。

そのため、

OpenClaw GatewayとWindows Companionの通信そのものは正常

と判断できます。

一方で、

system.which
→ okだがbins={}

system.run
→ タイムアウト

という状態でした。

また、

System tools = ON
Node Sandbox = OFF

でも症状は変わりませんでした。

そのため、現時点では、

Windows Companion側の system.run 実行処理またはWindows実行ファイルの解決部分に問題がある可能性が高い

というところまで切り分けています。

まだ完全解決には至っていませんが、

Node接続設定
Pairing
Approval
System tools
Sandbox

を何度も変更する段階ではなく、

Windows Companion本体の再起動・再インストール・新しいビルドでの検証

へ進むのが次の候補です。

OpenClawからWindowsを操作したいのに system.run だけタイムアウトする場合、今回の切り分け手順が参考になると思います。

タイトルとURLをコピーしました