Windows node `system.run` always times out on gateway (fixed ~30 s RPC limit) — MXC sandbox takes 27–53 s per invocation, result

Environment

• OpenClaw Gateway: 2026.7.1-2, WSL2 (Linux), bind loopback :18789
• OpenClaw Companion (Windows node): core v2026.7.1, Windows 10.0.26200 (x64), i7-14700KF
• Node capabilities: system, canvas, device, browser
• Node exec approvals: security=allowlist, ask=on-miss, askFallback=deny, autoAllowSkills=off, allowlist empty
• MXC: wxc-exec.exe v0.7.0-alpha; sandbox enabled=True, blockHostFallbackWhenMxcUnavailable=False

Steps to reproduce

1. Pair a Windows node (OpenClaw Companion) with a gateway.
2. From an agent session run any simple command via exec with host=node (e.g. echo test).
3. Approve the Windows exec-approval dialog immediately.
4. Observe: the exec tool fails with TIMEOUT: node invoke timed out.

Expected behavior
Command output is returned to the agent once approved and executed.

Actual behavior
The gateway aborts node.invoke after ~30 s (errorCode=UNAVAILABLE), while the node executes the command successfully and sends the result — 2–4 s after the gateway already timed out.

Confirmed diagnosis (measured, latest run)

12:50:52.542 node.invoke.request received by node
12:50:54.536 EXEC-APPROVALS decision=allow (user clicked within ~2 s)
12:50:54.539 MXC sandbox start (new AppContainer, containerId changes every run)
12:51:25.655 MXC result: exitCode=0, durationMs=31114 (command SUCCEEDED)
12:51:25.655 Sending invoke result: ok=True
12:51:22.563 gateway timeout: node.invoke 30014ms UNAVAILABLE ← fired 3.1 s BEFORE the result

Request→response total: 33.1 s vs gateway limit 30.0 s. Approval latency is not the issue (≈2 s). Observed MXC durations across runs: 27 s, 53 s, 27 s, 31 s — unstable, and each run creates a fresh AppContainer (containerId differs every time).

The 30 s limit is hard-coded on the gateway: passing exec timeouts of 60 s / 120 s / 150 s still results in exactly node.invoke 30014ms (the node even receives timeoutMs:150000 in params, but the gateway RPC aborts at 30 s regardless).

Suggested fixes (any of)

1. Make the gateway node.invoke RPC timeout configurable (config/env) or honor the request's timeoutMs with a sane cap.
2. Reuse/warm MXC containers across invocations to eliminate the ~27–53 s cold start.
3. When MXC cold start exceeds the RPC timeout, fall back to host execution if blockHostFallbackWhenMxcUnavailable=false (currently fallback only triggers when MXC is unavailable, not when it is merely slow).

Related but different: #1189 (SetInformationJobObject 0x80070057 — exec never starts; here exec succeeds but the result is discarded by the gateway timeout).

Start at the gateway's node.invoke RPC timeout and the Windows node's MXC execution path, using the logged 30,014 ms abort and 27–53 s invocation durations as the reproduction baseline. Trace how timeoutMs is passed and how the result is sent after the RPC aborts; done means an approved command's result is returned reliably without the fixed-limit failure, with the chosen timeout, warm-container, or fallback behavior validated.